A thin wrapper to the linux epoll api.

https://github.com/adilbaig/Epoll-D2

Adil:

> https://github.com/adilbaig/Epoll-D2

> ev.events = EPOLL_EVENTS.IN | EPOLL_EVENTS.HUP |    
> EPOLL_EVENTS.ERR;

In D enums are kind of (but not really) strongly typed, so 
writing them all in UPPERCASE is often a bad practice. So 
something more similar to this seems nicer:

ev.events = EpollEvents.in | EpollEvents.hupxxxxx | 
EpollEvents.error;


> epoll.add(int file_descriptor, ev);

Is this correct D syntax?

Bye,
bearophile

On Sat, Sep 8, 2012 at 2:49 PM, bearophile <bearophileHUGS@lycos.com> wrote:

> Adil:
>
>  https://github.com/adilbaig/**Epoll-D2<https://github.com/adilbaig/Epoll-D2>
>>
>
>  ev.events = EPOLL_EVENTS.IN | EPOLL_EVENTS.HUP |    EPOLL_EVENTS.ERR;
>>
>
> In D enums are kind of (but not really) strongly typed,


"are kind of (but not really) strongly typed" - I didnt know that. How?


> so writing them all in UPPERCASE is often a bad practice. So something
> more similar to this seems nicer:
>
> ev.events = EpollEvents.in | EpollEvents.hupxxxxx | EpollEvents.error;
>
>
I'm trying to keep the learning curve to a minimum so some one using this
library doesn't need to "double lookup" what it means. The original epoll
#defines are EPOLL* (ex: EPOLLIN, EPOLLHUP, EPOLLONESHOT ..), hence the
naming scheme EPOLL_EVENTS.* . But i do take your point. I'm thinking
Events.* ; Events.IN, Events.HUP etc. Succinct and fairly obvious. Looks
good?


>
>  epoll.add(int file_descriptor, ev);
>>
>
> Is this correct D syntax?
>
> I slipped into pseudo-code there. epoll works with file descriptors
(including its own), not just sockets, hence i didn't write
"epoll.add(listener_socket.handle(), ev)"


> Bye,
> bearophile
>

Adil Baig:

> "are kind of (but not really) strongly typed" - I didnt know 
> that. How?

D allows code like:

enum Foo { V1 = 10 }
void main() {
    assert(Foo.V1 == 10);
}


But C++11 enums are strongly typed, and similar code is a 
compilation error:

enum class Foo { V1 = 10 };
int main() {
    int b = Foo::V1 == 10;
}


Maybe Walter thinks that in similar cases forcing the usage of 
cast(int) introduces some risks that are not worth, so he has 
designed enums half-strongly typed. D contains several other 
equally mysterious design decisions :-)

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=3999


> I'm thinking
> Events.* ; Events.IN, Events.HUP etc. Succinct and fairly 
> obvious. Looks good?

What about Events.in, Events.hup, etc? :-)

Bye,
bearophile

> What about Events.in,

"in" is a keyword... sorry.

Bye,
bearophile