Re: Default or optional arguments to handlers
Re: Default or optional arguments to handlers
- Subject: Re: Default or optional arguments to handlers
- From: has <email@hidden>
- Date: Thu, 25 Apr 2002 22:11:30 +0100
Timothy Bates wrote:
>
> 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.
(I've never used PHP: how does the module system work over there?)
As far as osax/application dictionaries are concerned, I often find them
short on information. The dictionary format is too rigid, too narrow - it
doesn't allow for individual summaries, notes, examples, etc.
I would say the way forward here is to make osaxen into packages, and have
the dictionary as a plain-text XML formatted file within that package. Cook
up a suitable DTD for this new ASDML format - something that'll give
authors the flexibility and power they need, though without overdoing it.
Finally, produce a suitable viewer - preferably as some sort system service
or plugin that anyone can access from whatever application they like, not
just Script Editor. This viewer should support outlining - let the user
collapse or expand the amount of information displayed as they see fit (if
all you need is to remind yourself of some call syntax, you probably don't
need to view the examples, notes and other extended information, but all
should be there if you need them).
IOW the advantage of AS dictionaries isn't AS dictionaries per-se, but
rather that they're very easy to find and access. Still lots of room for
improvement, however.
BTW, I wouldn't be entirely surprised if the AS team's new osax
implementation did something just like this. Go team!
--
>
There will be name space problems, but that is life.
AS keywords breed like flies, never the same two days running; global
namespaces and an awkward sense of priorities in the compiler serve to
spread the problem about. Escalating the problem might not be the best
idea...:(
--
>
Currently no one ever uses the named parameter form of handler calling
>
because it is too clumsy.
Putting it politely.:)
>
And people are loath to adopt AS handlers as
>
substitutes for osaxen, because they are not transparent
Personally I suspect this is some way down the list of reasons why folk
don't use AS libraries.
>
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
makeCoffee(sugars:1, milk:2, brewing:3 minutes, atTime:4pm, withWarning:5
minutes)
is equally robust. Both use named parameters. Real Programmers would say
they prefer the latter over the AS syntax, as it's less verbose (ie less
likely to aggravate their RSI). Don't get me wrong, I kinda like the AS way
(and I'm a pretty fast typist too), but any decision has to be balanced off
pros versus cons.
--
>
> 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.
One can sometimes have too much of a good thing... :)
>
> Besides, I really quite like the "foo(...)" syntax.
>
>
Horses for courses.
P'rhaps...
>
"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.
I think AS's pretty printing is a great feature. Though I don't think
should be a substitute for good syntax.
--
>
>BTW, how would you do optional params here?
>
>
An optional parameter is achieved simply by adding a default value
>
>
to take an item (with terms {from list:theList, at:location=1})
This is so not AppleScript, however: "=" is NEVER used for variable
assignment in AS, ONLY for comparison. So now you have a record that is not
a record, containing a variable assignment that is not a variable
assignment. I hope you can see the problem here.:)
Something else though, when trying to master the "given" keyword in
labelled params:
on foo given john:green, fred:black
I found it hellishly difficult remembering whether the next line should be:
set theString to john & fred
Or:
set theString to green & black
The answer's #2, but what I'd learnt in AS up to that point was telling me
that it was #1; ie:
set theRec to {john:green, fred:black}
set theString to john of theRec
set anotherString to fred of theRec
Cue even more swearing, and enough o' that for me.
--
>
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.
You mean that PHP supports only positional parameters in functions, yes?
I think perhaps the ability to tack extra positional params onto an
existing function is there for backwards-compatibility's sake: you can add
extra parameters to an existing function without breaking or having to
rewrite code that already uses this function. For optional arguments I
think labelled parameters would be more appropriate for the job.
--
>
> 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?
Same sort of way that [I assume] you do it for osaxen: with the appropriate
tools. But again, this would tie in with what I was saying about
osaxen-as-packages: once you've got a flexible container and some agreed
standards on the input/output stuff, what you do inside there is entirely
your own business and completely up to you.
Cheers,
has
--
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.