[Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect?
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? Bill
In general I favor subtyping versus subclassing. Now I do not know the exact advantage for address to be a subclass of bytestring. Stef On Aug 14, 2009, at 9:19 PM, Schwab,Wilhelm K 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?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It was probably an expedient decision for FFT purposes. Dolphin defines a #asParameter on the corresponding class that answers the address/byte array aspect. -----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: Friday, August 14, 2009 5:43 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect? In general I favor subtyping versus subclassing. Now I do not know the exact advantage for address to be a subclass of bytestring. Stef On Aug 14, 2009, at 9:19 PM, Schwab,Wilhelm K 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?
Bill
_______________________________________________ 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
On Fri, Aug 14, 2009 at 9:19 PM, Schwab,Wilhelm K<bschwab@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
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-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@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<bschwab@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
On Wed, Aug 19, 2009 at 4:52 PM, Schwab,Wilhelm K<bschwab@anest.ufl.edu> wrote:
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.
Please try and report. 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
Damien,
From you and Stef, I can accept that. It would be nice if somebody could help with any expertise related to FFI and how objects get passed to external functions (e.g. Pharo analog to #asParameter). From there, I think I see it.
Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Cassou Sent: Thursday, August 20, 2009 2:47 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect? On Wed, Aug 19, 2009 at 4:52 PM, Schwab,Wilhelm K<bschwab@anest.ufl.edu> wrote:
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.
Please try and report. 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
participants (3)
-
Damien Cassou -
Schwab,Wilhelm K -
Stéphane Ducasse