My m*d is bigger than yours
My m*d is bigger than yours
- Subject: My m*d is bigger than yours
- From: "Serge Belleudy-d'Espinose" <email@hidden>
- Date: Wed, 12 Dec 2001 23:35:58 +0100
At 16:37 +0000 12/12/01, has wrote:
...lot and lot of things that must have taken much time :)
First of all, you don't need to send me and AppleMods since I receive AppleMods as well.
>
>Thanks for sending it to _me_,
>
>
Ah, well I thought you'd like to give it a whirl on your system first just
>
to see if that had cracked it.
Thanks. I didn't need to check, I trusted you :) Anyway it works ok.
>
In which case, folks should put the releaseDate property in as a string,
>
not a date object.
I suggested something once to Greg but it was before your strftime and you may have a better suggestion. releaseDate is written in a human-readable way, nothing more. It's totally useless for a machine unless you parse it, and parsing can break. Instead, or in addition to it, I suggest that mods supply a time stamp in the form of an integer. This time stamp could be the number of days since a special date, say 1/1/70? This way there could be a code that build the actual date by adding the property to this special date.
More. Yaams includes a button for updating existing mods but there's nothing behind. I suggest that the list returned from AppleMods - currently only the mod name and an internal number - includes this time stamp. This way it would be easy to compare this list with one built from the already downloaded mods, and automatically download only the updated ones.
>
Is there any foolproof method to write a date string that can be coerced to date object on any language system?
Not one I would know of, and as you've already guessed, I don't see how this could be possible since we are totally dependant from the user's settings, which could be anything includind custom. Yes you're right "rather than insisting on date strings being in a fixed format, it coerces them according to the system's settings"
>
(New Modmaking Rule #47: Thy mods shalt be language independent, else Big
>
Bad Serge will come over there and personally kick your arse. Hey, fancy
>
the job?;)
You should fear my mod Police :)
>
Could I maybe see a copy? I'm just about to write a date string parser for
>
my dateFormat lib (which uses "d/m/y" type notation).
Sure, but don't expect anything clever, it's totally brute force. You will find it in Yaams that I attach to this mail.
>
I think I'd disagree on the latter point. It can make a lot of sense to
>
enclose related functions in a single library, especially where these
>
functions share related sub-handlers. Otherwise you can end up with a quite
>
stupid amount of duplicated code all over the place (especially considering
>
the whole damn inheritance problem that got us here in the first place).
I won't argue to much on that with you, as IMHO it's totally dependant on what the mod does. In qSort - yes, again, sorry! this is my best flagship up to date - the sub handlers are enclosed because they wouldn't make any sense outside. More precisely, the mod is really two sections, a checking-and-coercing one which is very important but should be applied only once, and then the real meat which is made of two recursive handlers. OTOH I've written a very quick-and-dirty usrf() - which I'm not sure even _I_ will use it :) - that includes a handler for uppering the first char of a label, it could reside outside.
>
Equally, Arthur could have placed the code directly within the
>
constructor's own "script Associative...end script" and then you'd have had
>
only one top-level object, "MakeAssociative(param)", in the entire script.
>
But I think separating the two and using the parent property keeps the code
>
neater this way (else the constructor handler would very long and ugly to
>
read, and so harder to code).
Agree on that. As I said there's probably no definitive answer. If Yaams is really able to deal with multi-handler mods, we shouldn't care too much.
>
Neatness... it's a virtue; you'll make somebody a fine wife someday.;)
The stuff that piles all around my room surrounding the computer is not that neat :)
>
Look at macscript.com's closed-source mega-library that they sell
>
for good money.
Downloaded, had a quick look, trashed. Don't remember whether it included the source code or not. If it doesn't, I don't feel ok with that. Companies that sell linux distributions make money but the code is available as well - or at least _can_ be made available, which sometimes makes for a big difference :)
I really don't think the kind of code in macscript should be hidden.
>
It's an impressive number of functions, to be sure, but I've written equivalent handlers for some of those functions that are far better than theirs.
This is what I've thought either. No doubt - from anyone reasonably skilled. He's not doing justice to the newbies, but if some do pay, that's their problem...
>
I certainly wouldn't object to using closed-source mods
>
(out of interest, is YAAMS able to load the macscript library?)
does it include availableCommands and availableObjects and also modDependencies properties ? :)
>
For simple handlers, I use however many plain old params I need. For more
>
complex ones, or ones i think may expand in future, the main values are
>
still passed as normal but I'll have one param at the end which takes a
>
record (this is also useful when the values are optional and the handler
>
can supply its own defaults).
This is a clever mid-term solution.
>
>
I don't much like returning single results stuffed in records by default as
>
it's a hassle getting them back out all the time.
Agree but the following
>
If the output changes
>
from a single to multiple values at some point, I'd be more inclined to
>
allow the user to select which they want via an optional property in my
>
Settings parameter, e.g {returnAll:true}, and let the handler jig about
>
with it internally.
is once again dependant on what the mod does and is probably not always possible. OTOH, who has already used AppleMods to submit updates? not so many people.
>
(AS's labelled params suck and I refuse to touch them any more)
Another me-too. The way 'optional' labelled parameters is implemented is totally ridiculous and doesn't even compete with AS commands where some parameters are totally optional.
>
However, I'm going to do another apparent body swerve and say that a really
>
neat server _might_ be enabled to permit mods to build connections between
>
each another. OK, the 'super' mods from which functionality can be
>
inherited would have to be "certified official" AM mods.
Ahem, are we talking about the thing that the property modDependencies allows, ie let one mod specify what other mod it requires? Well, look at my compareLists handler and see that it relies on... my sort mod which name is...
I think you're talking about 'freezing' some mods so that any change won't break them - or they will have to be backward compatible. This should be the case with *any* mod, don't you think? However the idea of some kind of certification is somewhat cool, but the mod writer should volunteer first. "I testify that this mod will always work the same, please use it with trust.
>
>It doesn't bother me that a mod will tell an app, only if this mod is
>
>written so that it will work on most plateforms out-of-the-box.
>
>
There might be a bit of a contradiction going on here.;)
>
>
Mods go on AM. Everything else goes on SB. When Greg and I discussed where
>
to put hashLib, we both came to the same conclusion: it's not a mod (not
>
really). I think it makes sense, else what would you have but simply two
>
SBs?:)
So, why don't you go and suggest Greg to remove his mailOut from AM? sorry, couldn't resist. The log mod from Victor Yee also tells external apps, but it uses them more as a brick in his construction because there is no such thing as a standard - Apple blessed - scriptable text editor. SimpleText is a joke. Even Script Editor is. Apple, take care of your own stuff!!!
>
Unless the idea of YAAMS is to support, well, anything and everything
>
really.
Good question. What is Yaams ? :)
- btw it stands for Yet Another AppleMods Server.
In the unix way, I also thought of anything like *ING that would stand for *ING Is Not GetMods. BING, PING, YING, WING, make your choice please :)
>
I mean, an AM server for true mods, or a generalised server for any kind of modular file? Is there really a difference? Does anyone really care? And who really shot Kennedy anyway?
Bert did it.
>
I was reading Scott Norton's November list posts on the subject of script
>
objects: he strikes me as having a good grasp on OO design, modules and
>
servers. Have you spoken to him much?
Not directly :) As I said I re-read carefully most of the object and record
posts to try to suck every bit of info from them.
>
[And now for something completely different: OO principles!!! AHHHH!]
Ouch, so it's not over :) Great stuff, thanks. However I don't think that OOP would be relevant everywhere, procedural programming probably also has its advantages. But I agree that telling a var to use its own code on itself is cleaner.
>
[and, finally... good lordy - he's shutting up at last!!!]
>
>
>Oh, I still haven't let you d/load any version of Yaams. Would you like to?
>
>
After all the above, do you now really honestly want me to? ;)
Yes, please. Have a look at my code and laugh :)
A substantial part of it is defensive code. Lots of try and if blocks.
I'm not telling you how to use it on purpose, just try it first and please tell me to what extent it is - or is not :) - straightforward. Expect your files to move by themselves and your computer to do all sort of weird things in sequence...
Oh, there is not script template yet. Didn't have the time. Will do it.
See you - aren't we tired typing?
[demime 0.98b removed an attachment of type application/applefile which had a name of Yaams_0.87d4]
Serge
--
\\//\//\// Serge Belleudy-d'Espinose Institut Jacques Monod
// // //
http://www.ijm.jussieu.fr/ Universite Paris VII - Jussieu
//\//\//\\