Stef, Let's see, we have a method that includes writes to the transcript along side of obfuscated (in the name of speed) access to instance variables of a stream that is used as little more than a glorified value holder for an integer position. FWIW, I don't think that an HTTP client should inherit from socket; there is a lot of errant use of inheritance in Squeak. We have bigger battles to fight, but over time, these things should be refactored. Today I discovered that SocketStream defaults to using timeouts and suppressing errors. Hopefully I have corrected those two problems for my code. I trust your judgement. Is any of the above helpful? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Thursday, November 05, 2009 3:40 PM To: Pharo Development Subject: [Pharo-project] feedback on HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading I would really like to get some feddback on that issue http://code.google.com/p/pharo/issues/detail?id=1152 Issue 1152: HTTPSocket>>#getResponseUpTo: and HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project