Re: Passing *possible* variables to a handler
Re: Passing *possible* variables to a handler
- Subject: Re: Passing *possible* variables to a handler
- From: has <email@hidden>
- Date: Thu, 18 Jul 2002 00:45:36 +0100
Michael Sullivan wrote:
>
The other day, someone wondered what would happen if a script object
>
tried to subclass itself...
Yes, we're still trying to scrub them out of the carpet...
>
My own tests indicate that the extra overhead in making a script object
>
is minimal, but the overhead involved in compiling any significant code
>
within the object can be.
Not sure what you mean by "compiling code within the object". Bigger, more
complex object will take longer to instantiate (this would make sense).
>
Now -- I thought that perhaps script objects wouldn't inherit handler
>
parameters by reference so that passing large data structures could
>
result in a copying delay
Curious as to why you think they might. I kind of forget the reasons why I
used to have all sorts of weird and wonderful misconceptions about the
language, although I'm sure they were all arrived at through some process
that made sense at the time. (Truth to tell, I'm quite sure there'll still
be a few kicking around even now...) But once you discount the various
bugs, glitches, klunkiness, syntax flaws, special cases, exceptions, etc,
it really is a simple and elegant language and genuinely easy to
understand. [1]
I find it easier to think of values as objects as independent entities
first and foremost, and then work back from there in figuring out how
various operations may (or may not) impinge on those entities as they float
around the system. Knowing that some data types are mutable and others
imutable is also a big help.
>
Michael, invisible pass by reference considered harmful
Mmmm? I'm not sure about that: the issue is with data sharing, which is an
inherent behaviour for certain data types. Yes, it's easy to misconstrue
the way in which values are passed to handlers via parameters [2], but
that's what it is: a mis-assumption based on a faulty premise arising from
an insufficient knowledge of... etc, ad infinitum. (I'd say RTFM, only I'm
not sure the manual makes it particularly clear either.) Not sure what the
real solution is... design another language perhaps (I'm sure this is far,
far easier said than done:).
has
[1] No really, it is. And I do like AS, despite its faults. I just get
frustrated at all the grime and mess that's built up on the surface, though
I'm sure the AS team are doing their damndest to clean and polish it now
that AS is being treated as a serious contender in our shiny new OS X-based
future. Just not very good at being patient...:)
[2] Yes, been there, paid the price. Still don't blame handlers though.
--
http://www.barple.connectfree.co.uk/ -- The Little Page of Beta AppleScripts
_______________________________________________
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.