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:
[hidden email] [mailto:
[hidden email]] On Behalf Of Damien Cassou
Sent: Wednesday, August 19, 2009 9:19 AM
To:
[hidden email]
Subject: Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect?
On Fri, Aug 14, 2009 at 9:19 PM, Schwab,Wilhelm K<
[hidden email]> 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
[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
