<div class="gmail_quote">On Fri, Jan 8, 2010 at 8:22 AM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, 8 Jan 2010, K. K. Subramaniam wrote:<br>
<br>
</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Friday 08 January 2010 09:03:19 pm Levente Uzonyi wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
An #asDelay send doesn't make much difference IMO, and it just works:<br>
60 seconds asDelay wait.<br>
Though #wait can be added to Duration as self asDelay wait.<br>
</blockquote>
All senders of asDelay use it for wait, so why spread it all over?<br>
</blockquote>
<br></div></div>
#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.<br>
<br></blockquote><div><rant> <br></div><div>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.<br>
<br>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.<br>
<br>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.<br>
<br>Writing "5 seconds asDelay wait" is neither arduous nor unclear.<br><br>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.<br>
<br>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).<br>
<br>Please, let's try to keep classes' protocols directly related to their responsibilities.<br></rant><br><br>Julian<br></div></div>