Kamil Kukura <kamk at volny.cz> wrote:
> Oh, I once tried to get rid of OldSocket and adapt the rest to work with 
> Socket. I went to some point where it was done but after all that I was 
> pretty frustrated as I started to recognize all the mess.
> One example for all. If you look into Network-Protocols category you 
> will find quite nice hierarchy such as
> 
>     ProtocolClient -> TelnetProtocolClient -> SMTPClient
> 
> Even though TelnetProtocolClient stands for something rather telnet-like 
> (it's not implementing RFC854), I was very happy with that. So leading 
> conclusion was to have HTTPClient subclassed from TelnetProtocolClient 
> (which can be renamed without harmful consequences). But suddenly, you 
> will find that some $&*(#@*($^ introduced HTTPClient totally out of this 
> concept. Now solve the dilema:


This *Client stuff you are looking at, is a classic example of an
interesting idea that was not followed through.  It's a half-completed
refactoring.  

We used to consistently have SMTPSocket, HTTPSocket, etc., all
subclasses of Socket.  Yes, *consistently*.  Then the *Client stuff got
introduced, but without fully updating the major Internet applications on
SqueakMap.  There was a long period where Scamper and Celeste did not
work, and until today, we still have the inconsistencies you describe. 
For some reason, this "cleanup" project ended up making quite a big
mess!


My take: if you want to embark on a cleanup expedition, be prepared to
do it all the way.  Write updates for all the major packages using the
functionality, deal with a transition period where both old and new
names work, and eventually be a good sport and actually get rid of the
old names as planned.  It's a *bad* thing to submit a renaming changeset
and do nothing else.  It adds bugs, and I'd rather have things work than
have things be named in the best way.

Personally, major cleanups are usually way too much effort.  I find it much
better to save cleaning for when I am working on that part of the system
for some other reason.  I am expecting to break stuff anyway, so I may
as well try to tidy things up a little while I am there.  If I'm not
working on the code, though, then why bother cleaning it?  Working,
debugged, time-proven code is extremely valuable!


> - leave it as it is and just keep that mess arround. Of course, pray 
> someone won't write IMAPClient or XYZClient derived from Object and 
> pissing all this concept.

Yes, leave it alone.  Why is it so bad if this concept gets destroyed? 
IMHO, I am not convinced it will really work, anyway: I am not sure that
line-orientedness is a good enough reason to use up your one chance for
a superclass.  But it doesn't matter what I think, because Smalltalk
lets us evolve our concepts over time.  We don't *have* to stick with
any particular approach if it is not working.  People can make Client's
that are a subclass of the telnet protocol class, and they can make
Client's that aren't.  They can even change their mind later.



> Yes, and I see there are unresolved problems with handling errors in 
> socket communication but I feel it's maybe something simply unsolvable 
> within current design. Any other development environment is better in 
> this and other issues. No wonder, that even though I can amaze people 
> with rotating windows, I simply can't rely on it as development 
> platform. It is really a shame.

People successfully rely on Squeak as a development platform.  Your
theory is differing from practice.  

Lex