On 8/23/18 9:22 AM, Shachar Shemesh wrote:
On the other hand, look at ConnectedSocket.connect:
https://weka-io.github.io/mecca/docs/mecca/reactor/io/fd/ConnectedSocket.connect.html
Why do I need two forms? What good is that? Why is the second form a
template? Answer: Because in D, structs can't inherit, and I cannot
define an implicit cast. What I'd really want to do is to have
SockAddrIPv4 be implicitly castable to SockAddr, so that I can pass a
SockAddrIPv4 to any function that expects SockAddr.
Except what I'd _really_ like to do is for them to be the same thing.
I'd like inheritance. Except I can't do that for structs, and if I
defined SockAddr as a class, I'd mandate allocating it on the GC,
violating the whole point behind writing Mecca to begin with.
So interestingly, you are accepting the sockaddr by VALUE. Which
eliminates any possibility of using inheritance meaningfully anyway
(except that depending how you define SockAddr, it may include all the
data of the full derived address, sockaddr is quirky that way, and NOT
like true inheritance).
You CAN use inheritance, just like you would with classes, but you have
to pass by reference for it to make sense
struct SockAddr
{
int addressFamily; // forget what this really is called
...
}
struct SockAddrIPv4
{
SockAddr base;
ref SockAddr getBase() { return base; }
alias getBase this;
...
}
Now, you can pass SockAddrIPv4 into a ref SockAddr, check the address
family, and cast to the correct thing. Just like you would with classes
and inheritance. You can even define nice mechanisms for this.
e.g.:
struct SockAddr
{
...
ref T cast(T)() if (isSomeSockaddr!T)
{
assert(addressFamily == T.requiredAddressFamily);
return *cast(T*)&this;
}
}
To summarize: Weka isn't ditching D, and people aren't even particularly
angry about it. It has problems, and we've learned to live with them,
and that's that.
This sounds more like what I would have expected, so thank you for
clarifying.
The general consensus, however, is that these problems
will not be resolved (we used to file bugs in Bugzilla. We stopped doing
that because we saw nothing happens with them), and as far as the future
of the language goes, that's bad news.
Bugs do get fixed, there is just no assigned timeframe for having them
fixed. An all volunteer workforce has this issue.
It took 10 (I think) years for bug 304 to get fixed. It was a huge pain
in the ass, but it did get fixed.
I wouldn't stop filing them, definitely file them. If they are blocking
your work, complain about them loudly, every day. But not filing them
doesn't help anyone.
I'm not saying all bugs you file will be fixed, but all bugs you *don't*
file will definitely not be fixed.
-Steve
