Re: Who has that property?
Re: Who has that property?
- Subject: Re: Who has that property?
- From: has <email@hidden>
- Date: Fri, 11 Nov 2005 17:50:22 +0000
Axel Luttgens wrote:
>>Anyway, here's a much simpler version of the same test:
>
>Simpler, yes, but a one-level version only.
You can try it with extra levels of library nesting if you like; the result is still the same.
>It also misses another point: above example illustrates an opposite (inversed) approach to the one that seems to be adopted by Scott.
Don't really follow your meaning, but the point of the exercise was to determine why there's apparent leakage between library namespaces in some situations. The answer being that it's not the libraries doing the leaking, but the host application.
>When I run Main into SE, I get:
>
> (error dialog) Impossible de désigner {characters 1 thru
> 88 of document "Main", "Script Editor", true, "2.0",
> application} comme string.
>
>Clearly, SE has somehow been promoted to Lib.scpt's parent.
No, lib.scpt's parent is the AppleScript component instance in whose context it exists. That component instance in turn delegates all unhandled events to SE, regardless of which script they come from.
(I'd provide an example to demonstrate, only I've not finished patching Python's OSA module and I don't really feel like doing it in C. Still, you can grok the general principles just by reading up the OSA documentation on ADC if you want.)
>>Basically you've found a loophole that exists due to the way some applet implementations use OSA to do their thing. Although it should be regarded as a bug (feel free to file a report on it), not a feature, and its deliberate use avoided.
>
>A bug, I'm not sure.
>
>This is after all consistent with the available language specification, and persists through every incarnations since System 7.
AFAIK there's nothing in the public language spec that covers this aspect of applet implementation and behaviour, which means it falls in the 'undefined behaviour' category at best. Clients of OSA are free to do pretty much whatever they want with it, including screw up their hosted scripts' day in various obscure and convoluted ways. Caveat emptor.
>But clearly, I too don't like that idea of having "libraries" (implemented as script objects) depending on parent properties (whatever that parent might be).
Aside from the unreliability of it all, it would be lousy design to link libraries like this anyway. There are perfectly reliable, non-hackish ways to do it. Like I said in an earlier post, if you don't go trying to bend AS all out of shape in the first place then it's much less likely to bite you in nasty and unpredictable ways later on.
>>[...] ([...], and I can certainly vouch for the latter.)
>
>I'm wondering why :-)
Funny. :p Because I designed, wrote, refined, tested, and used it over the course of a couple of years,, so I already KNOW it works. Anyway, I hardly need to shill: given that it's the only freely available third-party library loader out there, it's already on a shortlist of one. :p
Of course, the OP could also write his own replacement system from scratch - but designing, building and testing a decent library loader is hardly a five-minute job, which is why I don't bother to suggest it. Especially seeing as he's not had much luck on that front so far... ;) <ducks>
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden