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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
