std.socket classes

[rikki cattermole via Digitalmars-d-learn]

On 09/04/2017 4:19 PM, Jonathan Marler wrote:
> On Sunday, 9 April 2017 at 15:04:29 UTC, rikki cattermole wrote:
>> On 09/04/2017 3:56 PM, Jonathan Marler wrote:
>>> On Sunday, 9 April 2017 at 14:49:14 UTC, rikki cattermole wrote:
>>>> Don't think too hard, times have changed since std.socket was written.
>>>> It certainly isn't designed for high performance hence e.g. libasync.
>>>
>>> What an odd response... You don't think I should ask questions about why
>>> decisions were made?  If I took that approach how would I learn?  And if
>>> you discourage other people from asking questions by telling them they
>>> are "thinking too hard" what kind of effect does that have on the
>>> community?
>>>
>>> As for "high performance", my questions have less to do with performance
>>> than they do with an API that makes sense and doesn't feel "kludgy".
>>
>> Oh sorry, I had a brain derp and thought at the end there you had that
>> you thought about it and it didn't make sense. Hence the slightly
>> weirder response.
>
> Ah ok.  That response was surprising to me coming from you (based on
> what I've read from you in the past) but I see it was a misunderstanding.
>
>>
>> What I meant is that, for common use cases it works well enough and it
>> does use reasonably sound API even if a bit cludgy.
>>
>> When asking about classes, one of the big things is the vtable. They
>> are slow (compared to final classes and structs). This is the main
>> reason people want to switch over to structs instead of classes.
>> However if you take a look at the more performance aware libraries
>> like libasync you will see classes used extensively still.
>>
>> Here is my suggestion, its a little harder to toy with ideas without
>> real code to show for it. All our more existing API's are mostly class
>> based for high performance sockets, timers ext. So, would you like to
>> have a go and explore this area since we are playing it a bit too safe
>> for your liking?
>
> What I've found myself having to do is use the lower level platform
> specific APIs that use socket_t and sockaddr, but then I get platform
> dependencies and can't access alot of the library because it requires
> the higher level Socket and Address objects.  I would be willing to
> explore this area, but before I do work in an area I research what's
> already been done.  Hence why I'm asking the questions about why it was
> done this way in the first place.  For all I know there are very good
> reasons it was done this way that I just don't know about.

I personally disagree with the designs used in libasync[0] and 
vibe-core(vibe.d's replacement/new core implementation). Very class 
heavy and not enough emphasis on the event loop. But as you can see with 
my lib SPEW[2] even I don't get away from classes (in fact I go all in).

Keep in mind only a handful of people really try to toy with this area. 
So you may very well come up with a completely different strategy 
that'll blow our minds without too much work. Existing implementations 
all have there trade offs, you simply may choose a completely different 
set and that is exciting.

[0] https://github.com/etcimon/libasync
[1] https://github.com/vibe-d/vibe-core
[2] https://github.com/Devisualization/spew