Re: hash arrays and other mysteries
Re: hash arrays and other mysteries
- Subject: Re: hash arrays and other mysteries
- From: Paul Skinner <email@hidden>
- Date: Fri, 19 Oct 2001 23:35:02 -0400
on 10/19/01 3:38 PM, AppleScripter wrote in response to my post...
>
> Don't give in! I have found the Perl mods to be my greatest temptation. But I
>
> don't like writing Perl. I just decided to make my own mods for AppleScript.
>
> maybe I'll let em run free once I feel they're ready. Maybe on Applemods
>
> Applemods does have a great concept in creating a space for this type of
>
> effort. I think that the freeform nature of most scripter's coding and lack
>
> of any call-return standard is going to limit it's usefulness though. If you
>
> have to open the handler and read it to understand what it wants and what it
>
> will give you back, then it won't grow properly. I don't know about what
>
> others do, but when I get a handler from someone, I open it, 'fix' the
>
> variables to my style, read through the code trying to compile it in my head;
>
> and the take the whole thing apart and rebuild it. Now I can't take that new
>
> code and feed it back into the system. All of the scripts that anyone has
>
> written that call that handler will break if they DL my new and improved
>
> version. Re-coding every script that uses asciiSort() because someone's new
>
> faster code wants different input or returns a record instead of a list ain't
>
> gonna happen.
>
>
Okay this is weird. Do you pick apart CGI.pm in Perl?
No way!
>
If you do, you're nuts. If you don't, then why would you in AppleScript?
I wouldn't. I said that I do that with *handlers* that I receive. But
someone picked CGI.pm apart, That's why I don't need to. Perl modules are
tweaked to the Nth degree. I couldn't begin to better them. Now if I could
you bet I would. I even do major repairs on my PowerBook myself. If I can
take it apart and put it back together and it still works then I will take
it apart again.
That's me though. Most people will use AppleScript modules
out-of-the-box.
>
The whole idea of mods is that you don't have to do that.
No, the whole idea of modules is that someone already did that.
>
Check out the docs at CPAN, that kind of documentation and use is just what we
>
should be providing with the mods (and soon we will).
That's great. But what a task! Check out
http://www.cpan.org/modules/00modlist.long.html#Part1-Modules:C
YOW!
>
You don't have to pull apart a Perl module to figure out what it wants. Just
>
use them and be done with it. (I get to this point in a minute). If everyone
>
is waiting for handlers to be given to them so they can be rewritten again and
>
again, then what's the point in sharing anything in the first place other
>
than, "Yes I can do x because I wrote a handler to do it. You can too. Go
>
code."
Regardless of the quality of the original code, the power of open source
modules will lie in the interrogation and modification of countless
scripters who want to make them better. If they just get written once and
frozen then they will doubtless be less than optimal. Look at the evolution
of code on this list. When would you say 'Stop. That script is good
enough.'?
>
> Now if there was a way to get everyone to agree on 'standard' input and
>
> output for handlers, we might even get the idea of mods for AppleScript off
>
> the ground.
>
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.
When I said scripters I meant us all. I sense that you mean module end
users.
While I can see a certain cleanliness to specifying an input and output
type as standard, I personally don't think that it's best. Easily available
documentation within each handler would allow much more freedom.
I have refined my handlerInfo idea further since I spoke with you last
about it. For everyone else; I use a handler template that provides a method
for getting this data...
thisHandlerName(missing value)
-->{handlerName:"theNameOfThisHandler",
handlerExample:"handlerName({paramater:parameter})",
handlerDescription:"theDescriptionOfThisHandler.",
handlerRequiredParameters:"{requiredParameter:valueClass}",
handlerOptionalParameters:"{optionalParameter:valueClass}",
handlerOutput:"ThisHandlerWillReturnThisValue:valueClass",
handlerVersion:"1.0dev", handlerCreationDate:"Tuesday, August 7, 2001
12:00:00 AM", handlerModificationDate:"Sunday, August 19, 2001 10:28:30 PM",
handlerAuthors:{{name:"Paul Skinner", email:"email@hidden"}},
handlerVersionHistory:{{"1.0dev-Development version"}}}
Hmm looks like I've forgotten dependencies. Probably some other things too,
Maybe I'll peruse the instructions at CPAN again : )
>
It's not so much about standards at that point, it's about good coding
>
practices and scalability internally.
>
>
> BAHAHahahah! Well, I TRIED to say 'standard' with a straight face. We all
>
> know that it isn't likely that everyone will use any standard even if some
>
> people could agree on what that should be.
>
>
>
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. 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.
Amen Brother!
>
That and include/import statements and hash arrays.
>
>
Greg Strange
--
Paul Skinner