SocketAddress>>printOn: - a (potentially serious) defect?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SocketAddress>>printOn: - a (potentially serious) defect?

Schwab,Wilhelm K
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SocketAddress>>printOn: - a (potentially serious) defect?

Stéphane Ducasse
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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: SocketAddress>>printOn: - a (potentially serious) defect?

Schwab,Wilhelm K
 
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: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse
Sent: Friday, August 14, 2009 5:43 PM
To: [hidden email]
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
> [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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SocketAddress>>printOn: - a (potentially serious) defect?

Damien Cassou
In reply to this post by Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: SocketAddress>>printOn: - a (potentially serious) defect?

Schwab,Wilhelm K
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
Reply | Threaded
Open this post in threaded view
|

Re: SocketAddress>>printOn: - a (potentially serious) defect?

Damien Cassou
On Wed, Aug 19, 2009 at 4:52 PM, Schwab,Wilhelm K<[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: SocketAddress>>printOn: - a (potentially serious) defect?

Schwab,Wilhelm K
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: [hidden email] [mailto:[hidden email]] On Behalf Of Damien Cassou
Sent: Thursday, August 20, 2009 2:47 AM
To: [hidden email]
Subject: Re: [Pharo-project] SocketAddress>>printOn: - a (potentially serious) defect?

On Wed, Aug 19, 2009 at 4:52 PM, Schwab,Wilhelm K<[hidden email]> 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
[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