Re: Default or optional arguments to handlers
Re: Default or optional arguments to handlers
- Subject: Re: Default or optional arguments to handlers
- From: Timothy Bates <email@hidden>
- Date: Wed, 24 Apr 2002 11:11:36 +1000
On 23/4/02 10:18 PM, "has" <email@hidden> wrote:
>
Timothy Bates wrote:
>
>
> 4. Libraries enhancements
>
> a Scripting Additions becomes a generic library access folder
>
> b.1 No distinction between Osax and AppleScript libraries
>
>
Only ~2 more weeks till we find out what the new 'osax' architecture is
>
going to be. I'd be delighted if it covered these points (as it should,
>
imho).
This would mean a way of exposing the handlers and props of a library
(script object) under the "open dictionary" command. That would be
fantastic. One of the reasons that usrs find AS easier than, say, php, is
because we often can say "it is in Acme", pop open Acme's dictioanry, and
quickly find the syntax we are looking for.
>
> b.2 Ability to define names for Applescript handlers
>
I like your other points, but not sure about that one. I'm unsure what the
>
potential for keyword collisions and other disasters might be once you let
>
the grand mass of ASers in on that particular act as well.
There will be name space problems, but that is life. The name space is also
strongly minimised if the handler name space is local to the handler, i.e.,
don't compile "from list" in a global context, but just in the context of
the local handlers parameter names. This can be done by recognising the
handler name and setting up a name-space based on that.
Currently no one ever uses the named parameter form of handler calling
because it is too clumsy. And people are loath to adopt AS handlers as
substitutes for osaxen, because they are not transparent
makeCoffee(1,2,3,4,5)
Is more error prone than
make my cup with 1 sugar 2 milk brewing for 3 minutes starting at 4pm and
warning me by 5 minutes
>
Quick Aside:
>
>
I have a bit of a love/hate thing about application kewords as it is; never
>
sure if they're a boon or a curse, and think they're probably over-used as
>
it is.
Gotta havem.
>
Besides, I really quite like the "foo(...)" syntax. It's clean, simple, and
>
easy to write and remember. The parens also make for a good visual cue - I
>
find it's much easier to spot "foo(x, y)" within code than "foo for x from
>
y", for example.
Horses for courses.
"initialise(myname, myJob)" is fine, but other handlers where the parameters
are more confusable really reward the multi naming. Good syntax
highlighting makes this obvious.
>
BTW, how would you do optional params here?
In the example
to take an item (with terms {from list:theList, at:location})
--do stuff
End
An optional parameter is achieved simply by adding a default value
to take an item (with terms {from list:theList, at:location=1})
Also, this form of optional parameter is even better than phps, as in php
you can only leave out parameters to the right of those you include, in the
named call, you can leave out anything.
take an item from {1,2,3}
-->{2,3}
>
I think if it was specifically for the purpose of dressing up mods to
>
appear osax-like then some sort of additional wrapper that goes around a
>
normal library would be the best solution - you'd likely need something
>
like this anyway to support osax-style dictionaries.
Now that idea I like a lot! How do you maintain the wrapper?
tim
_______________________________________________
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.