Sig, An OO layer on top of procedural software does not have to be tied to the limitations of the procedural software, and in general should not be. You make refactoring of Socket sound like it can only be done by a complete slash and burn, when in fact it could be as simple as exposing behavior where it makes sense. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 7:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/31 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Sig,
Furthering a bad design practice does not illustrate an attempts to promote safe use of resources. Â If you knew that adding the behavior was a bad idea, why did you suggest it?
because, as to me, what you are proposing is equivalent to it. In smalltalk you can enforce the correct usage of provided functionality only by means of provided behavior.
Server behavior: consider listening on ports and accepting connections. Â True, that is BSD socket behavior, but you are trying to have it both ways. Â You cannot complain about superset behavior that I might introduce and then later say that the current design is ok because it uses the same shotgun wedding approach as BSD (aka a superset interface).
we have what we have. :) If you'd were writing own library for network communication which directly speaks with hardware (like in SqueakNOS), then you are free to do it differently. But Socket implementation depends on underlaying socket library, adopted by wide range of OSes working with wide range of hardware. It is good that we having something in common and don't need to invent or implement it from scratch. And despite how good or bad it is, it allows us to write portable software, including smalltalk, unless you refactor Socket class :)
Taking your approach, nothing in Squeak would ever get fixed. Â In fact, "well, YOU can always do such and such in YOUR image" was the usual argument used to block change in Squeak. Â Something to think about.
if there will be fix or extension in original socket library, only then we should consider synchronizing Socket class with it.
And yes, replacing the entire network system has crossed my mind. Â IPv4 and 6 are currently mixed into a big ball of mud (no offense to those working hard to add it, but it's not at all factored, and should be). Â I will hopefully soon be in a position to get network connections running across platforms, and I suspect that the errors reported some months ago will turn out to be due to the new sockets. Â Finally, we should have access to SSL sockets via OpenSSL. Â That might just drop in along side of the current socket system, but there might be room for a better solution, perhaps as an extension of Nile.
as long as you are using same library (sockets), i see not much reasons why we would need to drastically refactor the stuff. Because, with whatever code will wrap it, you end up using same system calls which expecting same argument types & returning same results. So, instead of 'better wrapper', we should expose these calls to language, as close as possible to original and this is the main role of Socket class. Then anyone is free to use them as he likes to. This is what i meant by talking about 'own subclass' and this is why i think that Socket class is bad place for refactory. My point is, that if you writing own library/classes, which having virtually no dependencies from other frameworks, then you are free to do it in any way you like to. But if your goal is to expose the functionality of existing library (such as sockets), then instead, you should be very pedantic and do it as much as close to original, despite how good or bad it is. Then you are opening doors to people who already used this library before, but in another environment/language. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project