On Fri, Jan 8, 2010 at 8:22 AM, Levente Uzonyi <leves at elte.hu> wrote:

> On Fri, 8 Jan 2010, K. K. Subramaniam wrote:
>
>  On Friday 08 January 2010 09:03:19 pm Levente Uzonyi wrote:
>>
>>> An #asDelay send doesn't make much difference IMO, and it just works:
>>> 60 seconds asDelay wait.
>>> Though #wait can be added to Duration as self asDelay wait.
>>>
>> All senders of asDelay use it for wait, so why spread it all over?
>>
>
> #asDelay is more general, since it can convert a Duration to a Delay. You
> can store the delay an send #wait later to it. And it's compatible across
> forks and versions.
>
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100108/930c236e/attachment.htm