Re: handler failure [oops! correction]
Re: handler failure [oops! correction]
- Subject: Re: handler failure [oops! correction]
- From: Mike Fischer <email@hidden>
- Date: Fri, 15 Nov 2002 08:26:55 +0100
Hello has,
Am Donnerstag, 14.11.02 um 17:28 Uhr schrieb has:
Here is an exploit of this "feature" which demonstrates that it might
actually be useful:
[snip code]
My problem's not with the ability to assign handlers to different
slots,
but that the behaviour is buggy. It's important to be clear on the
distinction, lest the thread go all wonky and off-track.
Hmm, maybe I misunderstood. I do apologize for adding to the clutter
but your challenge to discover the mechanism of what is going on
sounded to me as if a bit of humorous exploitation would do no harm.
Re. your example, you can easily get the functionality you want with
more
conventional techniques - eg:
Of course! I was trying (and failing) to be so obvious in misusing this
"feature" that I expected everyone to notice the humor. My mistake!
Please note the quotes around the word "feature". I'll try to be even
more obvious in the future.
Now if somone can tell me the trick of addressing properties by index
the GetMonthName handler could be even more elegant...
<cough>Incredibly Hackish</cough> If you want an ordered structure, use
one.
Indeed! I fully agree.
The whole point of an unordered structure is that position is
irrelevant. [1]
Although I wonder how you arrived at the conclusion that the properties
of a context represent an unordered structure? While I agree that named
property/value pairs are comparable to an AS record structure in many
respects that doesn't say anything about ordering. Indeed the whole
point of this discussion seems to be that there is a hidden ordering
inherent in this structure however undocumented it may be.
(And please don't tell me I could use an array. That'd be beside the
point.)
Not at all. Use the right structure for the right job.
Again I agree! It would never cross my mind to actually use an obscure
undocumented behaviour instead of a simpler documented language feature
for anything but making a humorous investigation.
My point was that the obscure behaviour of AS you described might have
some use. That is if it is actually a supported behaviour in the sense
that we can rely on it staying around with newer versions of AS.
It does kind of remind me of obscure pointer arithmetic in C though
;-)
Urk. Reason enough to shoot the idea in the back of the head and bury
it in
an unmarked grave, post-haste.
My sentiments exacly which was why I mentioned it. Unless it is
officially documented and sanctioned in which case there might be rare
circumstances where it might prove useful. The same goes for C pointer
arithmetic IMHO. I would advise anyone using it to find alternative
solutions first and at the very least to heavily document its use. Any
tool has its proper application.
Now I wonder if this is actually a feature of AS that we can rely on
or
something of an implementation dependent side effect?
Not sure which behaviour you're referring to...
- That a handler object can change context, and adopt the new context
as
its own? That's a characteristic of the language, but one that's
undocumented and buggy.
How can a characteristic of the language be undocumented? Or the other
way around: how can an undocumented behaviour be a characteristic of
the language?
Until/unless those issues are remedied, use a
documented and reliable alternative instead.
- Or accessing a script object's slots by index?
<clik-klatch><BAMMM!!!>
Now, where's the damn shovel...
:-) Actually both. As for the bugs you mentioned I think I missed what
you mean by that.
Are you calling an undocumented behaviour a bug?
Or are you complaining that an undocumented behaviour doesn't work
consistently?
[1] Note: what an object does in _private_ is its own business. If it
uses
slot positions internally to boost performance, that's up to it. What's
important is that nobody else should know - or need to know - anything
about this.
I have been using object oriented languages and frameworks for 15
years. So there's no need to explain the basics. This practical
experience also taught me that more often than not it helps to
understand the internal workings despite this going against the
theoretical aspects of OOP. Your interest in our current subject
suggests that we are of one mind here.
Back to the subject: Am I correct in assuming that you would expect the
following script to produce an error instead of a value result?
Something along the lines of "Error: can't find property _a in
context!"?
----------------------------------------
script a
property _a : 1
on _h()
return _a
end _h
end script
script b
property _b : 2
property _h : missing value
end script
set b's _h to a's _h
b's _h()
-->2
----------------------------------------
Unless this behaviour was documented I would agree that it should
produce an error.
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.