Delay for: 60 seconds vs. Delay forSeconds: 60.

Never mind...I just realized that you weren't talking about units in general, but just about the Delay protocol.  But, I do think putting a generalized units framework in the base squeak to encourage adoption would be a good idea.

- Stephen 

<rant>

Yes, Squeak loves creating protocol explosion by duplicating the protocol of one class all over the place to where it "might be useful". This makes it more difficult to write portable or consistent code, makes namespace collisions more likely, and means you have to wade through way more protocol on each class looking for what you want.

There are many, many things that might happen over a particular duration. Let's take the JQuery support in Seaside as an example. There are dozens of effects, all of which can run over a certain number of milliseconds. Should we add #hide, #slideUp, #slideDown, #toggle, #fadeIn, etc. to Duration? Just because something *uses* Durations, does not mean its protocol should be duplicated on Duration.

Also, what happens if another, better implementation of a Delay-like class comes along. Now we'd want *that* to be used by Duration>>wait, but it has slightly different behaviour, so now we'd have to add #wait2 or #waitNew or something. It's a mess.

Writing "5 seconds asDelay wait" is neither arduous nor unclear.

To be honest, even #asDelay is slightly (though less) suspect to me unless you are implementing it for polymorphism across multiple classes. I realize #asDelay already exists (with only one implementation!), so it's probably not worth talking about in this case, but "(Delay for: 5 seconds) wait" just isn't that bad.

And while I'm ranting around this area, I just noticed Time>>asDuration and DateAndTime>>asDuration. What the heck is up with those? The logical duration of both those classes is zero (as already implemented by #duration). If you're going to implement #asDuration for polymorphism (and why would you, honestly, given that they have a duration of zero?), why wouldn't you implement them to call #duration? It makes no sense for a time of 1:33pm to have a duration of 13 hours and 33 minutes. Several internal methods want to know the duration between midnight and the specified time; fine, so add a private method #durationFromMidnight or something. I'm guessing we thought it was cute to be able to do "3 days + (Time hour: 13 minute: 33 second: 0)" but as a result "(Delay for: Time noon) wait" would wait for 12 hours. It makes no sense (except possibly if it is exactly midnight when you run that).

Please, let's try to keep classes' protocols directly related to their responsibilities.
</rant>

Julian