Sean Kelly wrote:
> Looks much nicer than the current std.socket. A few random comments from
> a quick scan of the code:
>
> Socket.send/receive should use ubyte[], not void[] for the data.
Regardless if it is correct or wrong I think there is a reason it is void[]
(I am sure you are aware of this but just in case you are not ;)). All
arrays implicitly convert to void[]
(http://www.digitalmars.com/d/2.0/arrays.html - Implicit conversions) and
the array length is automatically modified such that it is a byte count (for
example assigning a dstring "hello" to void[] sets void[]'s length to 20
while dstring is 5), this lets you send data to send/receive without having
to cast it. I've inferred that to mean void[] is expected for buffers of
bytes and ubyte[]/byte[] as arrays of bytes.
>
> I'd like some way to avoid new objects being created during any low-level
> socket operation I expect to do regularly. For example,
> socket.receiveFrom creates a new Address instance every time it's called.
> Perhaps I could have the option to supply an Address object to be
> overwritten instead?
>
> That Address.name() returns a sockaddr* is kind of weird. I'd expect it
> to return a string? I know that the sockaddr is generally called a "name"
> in API parlance, but it seems a bit weird in this context.
>
> Why is InternetHost an instantiable object? It has data fields that
> aren't initialized by any ctor, but only by calls where a hostent* is
> passed? And all for access to API calls which no one is supposed to use
> anyway? Please just make this go away :-)
>
> There are a number of bool parameters that should really be
> EnumName.yes/no.
>
> The current approach that appears to be required for connecting to a
> remote host kind of stinks:
>
> Socket sock = null;
> foreach(info, getAddressInfo("www.digitalmars.com")) {
> try {
> sock = new Socket(info); // will throw if can't create a
> socket based on info sock.connect(info.address);
> break;
> } catch (Exception e) {
> sock = null;
> }
> }
> if (sock is null)
> // unable to connect via any available method!
>
> As an aside… From your comments, I gather that you're not terribly happy
> with certain design requirements imposed by the existing std.socket. Why
> not create an entirely new API in std.socket2 and not worry about it?
> Would your design change enough to warrant doing this?
