Re: hash arrays and other mysteries
Re: hash arrays and other mysteries
- Subject: Re: hash arrays and other mysteries
- From: has <email@hidden>
- Date: Sat, 20 Oct 2001 16:55:05 +0100
[Look out folks, this one's a biggie. Sorry...]
Greg Strange wrote:
>
I feel like I just gotta put my 4 ha'pennies in.
By all means, make us all the richer.:)
>
>> But who wants to write:
>
> >
>
> > property [handler name] : [handler name] of (load script "Hard
>
Disk:System
>
> > Folder:Scripts:ModFiles:[name of file]")
>
> >
>
>
>
> Not me.
>
>
>
>
Not me either. And frankly, I don't see any reason why we should until I
>
picked up my copy of Learning Cocoa and I realized that the underlying
>
structure is that everything is an object, each object receives certain
>
messages and sends certain messages to and from other objects (a system
>
which helps protect the objects from each others polymorphic and data
>
binding behaviors). Whew! (Did I get that right, Chris?) That doesn't
>
mean to say that my lament on the applemods mailing list that there isn't a
>
command like
>
>
initialize handlers from AppleMod "readIn"
>
>
is in any way ameliorated by understanding why it hasn't been like that in
>
the past. I want an include statement in AppleScript. Plain and simple
>
that would make modular scripting a boon to the entire community. I also
>
want hash arrays but I digress. There is no reason why we can't load
>
handlers with a simple include/import statement just as you can with
>
Objective-C. Won't soemone just write the damn osax that does that? I
>
would gladly pay for it.
A 3rd-party osax would be okay, as long as you weren't completely tied to
it. Which you shouldn't be since "load script" is always there as a
fallback option. It would be nicer if it came bundled as standard, however:
something this "essential" wouldn't deserve to suffer the vagaries of the
3rd-party OSAX world (from folks worried about upgrade cycles, to those who
can't get their IT depts to install 3rd-party stuff for love nor money).
Getting a real mod community going will need all the breaks it can get, and
whilst some folks will pay for an OSAX to do it, others won't, and you're
back to the non-/conflicting-standards problem again.
>
Actually, for the scripters, there is no need to worry about a standard
>
input per se. As mod writers though we shoudl be aware of what gets passed
>
to us. And, as Serge has suggested, if we always return values of the same
>
type, like say a record, then when we make changes to the mod the scripter
>
will always know what comes out and that can scale or stay the same becaus
>
ewe are merely adding more labels to the output and not changing the
>
fundamental return of the handler. It's up to the mod writers not the
>
scripters as such. It's not so much about standards at that point, it's
>
about good coding practices and scalability internally.
This makes a lot of sense. (Is this how mods in other languages also do
it?) Given that AS doesn't support optional parameters for handlers, I'd
guess that using a record for input will also be necessary. (Then you can
'catch' any missing values by concatenating with a 'default' record once
it's in.)
Although:
foo({bar1:"", bar2:""})
still doesn't look as nice (or readable) as:
foo(bar1:"", bar2:"")
but I'm not sure we'll see this happening any time soon, besides which
there's the obvious issue of backwards compatibility. So I guess it'll
probably have to be foo({}) if there's any question of new parameters being
added in future versions.
In the mod I'm currently doing:
mungeText({theText:"blah-blah", usingLists:{{"b", "f"}, {"h",
"p"}}, safeReplace: false})
mungeText({theText:"blah-blah", fromList:{"b", "h"}, toList:{"f",
"p"}, safeReplace: false})
--> "flap-flap"
where you can either use a single list containing {[from], [to]} pairs
(usingLists), or else use separate 'from' and 'to' lists. In fact, the
extra complexity in supporting alternative parameters is making me wonder
if I'm not trying to be TOO clever and should just stick with two separate
handlers instead: one of usingLists and the other for fromList & toList.
Should an 'official' mod repository be able to send back to a submitting
author and say "we really like your mod and would love to host it, but
think its input/output is much too complicated and you should split it into
two separate, easy-to-use handlers"?
The safeReplace attribute allows you to replace multiple items at once
without any risk of overwriting text that has already been replaced once.
As for future expansion, well I might decide to add a matchWholeWords
attribute as well, or perhaps I'll think of something else it could use....
so I guess for this mod I will _have_ to use a record.
But, the $64 question is: for any mod (well, at least for those that appear
on AppleMods where you've got some control) do you *insist* on records for
passing all parameters in/results out, or do you leave it up to individual
authors? 'Cos if it's the latter and they then add new parameters later,
you can't distribute the same mod using the same handler name or file name
and you soon end up with multiple iterations of the same handler stuffing
up your mods folder. But there's bound to be those who don't want to use
records to begin with; and using records does, as I've mentioned, add a
little more complexity to mods - and the scripts that use them - than is
ideal.
I do know though that I don't want to have to rewrite mods to suit me when
I get them; nor do I want to have to cut and paste them into my personal
script server just to make them accessible.
"Manually load two mods into my script? Not me; now I just Mod() And Go!"**
(**Yes, yes. <GROAAAN>. I know...)
Now for a related question: does anyone ever use labelled parameters for
their handlers? I've been tinkering with these, but am unsure if they make
don't scripts a little harder to read, in fact. Now, everybody knows just
by looking what something of form "foo(bar)" is, but personally I don't
think "foo for bar" stands out nearly so well. I like the
"identifier-parentheses" format you get with positional parameters for its
visual clarity, but do wish it also allowed for using labelled parameters
within the parens. Oh, and not to mention allowing optional parameters
too. This'd make all input much cleaner imo.
(Gosh, if we keep going like this, eventually AS would end up looking JUST
LIKE Perl/Python. Would it lose its quirky personal charm in that case?**;)
(**Note to Chris and fellow AS dudes: just pulling leg a little.<g> Even if
I am grouching about AS's occasional weaknesses I still love it even more
for its strengths.)
>
We all agree on standards all the time. And we all disagree on standards
>
all the time. It's a question of meeting a need. Frankly, I would love to
>
have the access to hundreds of handlers and script libraries like I do in
>
Perl, Python and countless other scripting languages available on the Mac
>
these days.
(Ack, help! I'm drooling again.)
Y'know, if a bunch of folks were to get together and trawl the archives of
this and other forums, I bet they could easily find enough existing code to
assemble a whole stack of ready-to-roll mods out of.
(No, I'm not volunteering either.;)
>
But it comes down to you and me, Paul, and all the other
>
scripters who want to move beyond writing their own (perhaps) inefficient
>
handler for the "entire contents of" bug. That's where we shoudl be pulling
>
together to increase AppleScript's value and robustness.
I absolutely agree on this. I'm looking back at my previous big monolithic
"achievements" and thinking that I could have done it all so much
quicker/simpler/easier if I'd had access to a broad and dirt-easy-to-use
mod library. I want to get past all that myself, and if anything that I
produce can be put into public circulation where others will use it, even
better. But none of this scraping around, having to learn for myself (from
scratch) how load script, parent properties and all the rest works, and
then figure out ways to use them efficently/reliably/scalably.
This is also probably one of the reasons why mods aren't more widely
available/used: a lot of folks just don't get deep enough into AS that they
learn the skills needed to take proper advantage of mods (and cut&paste is
such a turn-off). It's a real uncomfy jolt for novice ASers going from
writing simple procedural code to suddenly realising that the world is
actually made up of these wierd things called "objects" (it's not so long
since I did it myself).
What's needed is a standard (mostly over documentation) and an "import"
solution that make mods as easy to use as OSAXen (or even easier).
Actually, with some OSAXen unlikely ever to make it to OSX, this may be a
particularly good opportunity for mods to step into the breach.
Oh, Greg, on a semi-related point: I've been trying to use your own
"readIn" mod, but it kept throwing errors at me. Would it be useful if I
send you an alternative version I've got? (Or should I just go and boil my
head now?<g> BTW, don't worry: I think I've also managed to spot an
inefficiency in Serge's qSort handler too, so maybe he'll kill me first and
save you the trouble.;)
(Which also suggests another advantage of a good mod lib: assuming we can
all agree to play nice with one another, there's a good chance that folks
downloading any mod would sooner or later spot any flaws/inefficiencies/etc
and feed their improvements back into the system in some manner
yet-to-be-agreed-on.)
>
That and include/import statements and hash arrays.
And regular expressions.
Cheers,
has