Damien, Stef, How far should we go to clean it? A good start would be to simply remove the lookups from #printOn:, but my idea of a real fix is to move SocketAddress to be a subclass of Object so both the name and number can be independently (even lazily) resolved (not during #printOn: though). The move would mean that a socket address would no longer be a byte array. Dolphin copes with that by #asParameter which allows objects to customize how they appear to the outside world. If Pharo has a similar concept, the change would be easy; otherwise, some surrounding code would have to change to access the address' "number" aspect vs. simply operating on the address itself.
With a small push in the right direction (re #asParameter or equivalent), I think I see what to do and will tackle it if you want me to do so. Bill -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: Wednesday, August 19, 2009 9:19 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect? On Fri, Aug 14, 2009 at 9:19 PM, Schwab,Wilhelm K<bsch...@anest.ufl.edu> wrote: > SocketAddress>>printOn: looks like it does some questionable things, but I am > fuzzy on what exactly is happening and what should be done about it. My > thought would be that the address should have name and number aspects, that > resolving would do the respective lookups, and that inspecting should not > attempt the lookups. Do you agree? How broken is the implementation? > > I cant' say that I am thrilled about addresses being inherited from ByteArray > - I suppose it can happily be the address and have an iv for the name, but > what if one knows the name and later wants to resolve the number? This > sounds like a job for a subclass of Object with named variables. Anybody > agree or disagree? I saw some problems which appeared while printing a socket address on Windows (primitive has failed). So, cleaning that would be cool, thank you. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
