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:
[hidden email] [mailto:
[hidden email]] 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=1152Issue 1152: HTTPSocket>>#getResponseUpTo: and
HTTPSocket>>#getResponseUpTo:ignoring: are ugly and misleading
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
