Re: monthNumber (was: Create a folder with today's date...)
Re: monthNumber (was: Create a folder with today's date...)
- Subject: Re: monthNumber (was: Create a folder with today's date...)
- From: has <email@hidden>
- Date: Wed, 13 Feb 2002 02:15:46 +0000
Richard Morton wrote:
>
> [FV vs ifThen]
>
> No, no, was a fair test, one hand tied behind my back, etc. ;)
>
>
And the other on the scales perhaps? ;-P No, it sounds like it's due
>
to differences in AS versions from what Nigel has posted here since.
>
That does surprise me I must say, but I guess life would be a bit boring
>
without surprises. [...] My "hunky G4" also took a lot longer than
>
whatever you're running.
HAH! My puny orange iBook r00LZ your mighty G4! :)
[snip various routines for reading later]
>
> In the meantime, I just patch
>
> the gap for myself. (One of these days I might even come up with a
>
> version
>
> of dateLib that I'm actually happy with and release the blighter...;)
>
>
Good luck. :-} I had a go at it sometime ago & came to the conclusion
>
that AS is too slow and clunky to allow the sort of flexibility that an
>
osax can. AS can get seriously bogged down speedwise by complex
>
conditional structures.
And loops; and multiple application calls; and ...; etc. Hey, there's
always C++, y'know...;)
Anyway, on my G3/300 dateLib takes about 3ms to convert a date object into
"yy/mm/dd HH:MM:SS" format. It takes another 13ms to parse the formatting
string itself, but since you can [optionally] parse the format string
separately you might only this once (e.g. at compile-time) instead of every
time you want to convert a date. It's a power-user thing, sure, and 16ms is
probably good enough for many folk, but it's nice to have the option.
Interestingly enough, Akua Sweets also takes about 3ms to convert a date to
the same format ("%y/%m/%d %h:%i:%s"). (I haven't done a thorough
side-by-side trial but reckon I'm doing fairly well considering.:) I doubt
you'll get a much faster result using a hardcoded AS routine either.
dateLib also takes around 8ms to convert a string back into a date object,
which is a good deal slower than using 'date theString', but since you can
specify the expected format it's a lot more robust (i.e. "1/3/02 means
different things depending on whether your Date&Time CP is, say, US, UK or
Swedish; with dateLib you get to tell it "m/d/yy" so there's no confusion.)
IOW I'm really pretty pleased with its performance, but after _three_
redesigns I damn well expect to be. It has done wonders for my algorithm
design skills, however. :)
--
>
We also don't have the capacity to use optional
>
parameters when writing handlers which means that it's virtually
>
impossible to create a simple interface to something that has lots of
>
options.
This is a serious pain; I almost ran off-topic the other day into a rant
about AS's lousy implemetation of labelled parameters. My own opinion is
that the current mess should be deprecated post-haste and replaced with
something that is simpler, more sensible and which supports optional
parameters.
Until that happens though, I'd suggest taking a record as a single parameter:
on doSomething(theParams)
set theParams to theParams & {something:"default value",
somethingElse:"another default}
etc...
in those situations where you _really_ need optional params. It's not
ideal, but it does the job.
--
>
I'm sure it would be different for others, but I have no interest in
>
writing, or using, a handler that requires me to spend a minute or two
>
studying its documentation every time I want to call it. This has led
>
me to focus more on small sharp tools, which, as we've seen here, can be
>
very efficient.
Hmmmm... I'm sure I had this debate with Nigel just the other week already.
Bold, independent "frontier spirit", or just a case of the 'Not Invented
Here's? The audience decides... ;)
BTW, writing "small sharp tools" - aka small, efficient, single-purpose and
reuseable handlers - ought to be the scripter's #1 mantra. Big, powerful,
flexible suites like dateLib should be the exception (and big muddled messy
splurges a thing of the past).
Good interface design also goes a long way: how you name your handlers and
what parameters you use can make a big difference to grokability and ease
of use/reuse, both for yourself and others. But in every case you'll still
need to RTFM on occasion - unless you're the sort of L33t coder who makes
Netscape6's designers look like a role model for code reuse and just write
a new one every time.;)
It's a great subject for debate, but I need my bed so I think it'll have to
be some other time... :)
Cheers,
has
_______________________________________________
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.