Add Loop::getHandle

[kelunik]

Previously we advised to use Loop::get()->getHandle(), because it's a method only required by very few components, namely the filesystem libraries, which need the underlying handle to operate.

We argued that we get a smaller autocomplete list that way. I think consistency is more important.

[trowski]

I still feels like it clutters the API that application writers would need to use. Only libs should be concerned about the specific loop implementation being used.

[bwoebi]

I agree with @trowski — the autocomplete list is not important. It's about people looking at the Loop class and finding (for them) irrelevant functions.

[kelunik]

I'll close this one for now, we can always add it in a v1.1.

[kelunik]

@trowski @bwoebi We might want to add it, because otherwise filesystem has to depend on event-loop instead of event-loop-api, see #129.

[joshdifabio]

It won't if event-loop-api covers the API of both classes (bot not the SPI). I don't see any issues with that myself.

[kelunik]

We said event-loop-api should cover everything except Driver, if we make it even more fine granular, I think nobody will get what's actually covered.

[joshdifabio]

To me, the important thing is to be able to make changes which are breaking for loop implementors (e.g. add a method to Driver) without forcing clients to also change their version constraints. I.e. if you plan to implement or extend Driver then you must require event-loop, otherwise you should require event-loop-api.

I think the value is less in separating Loop/Driver and more in separating API & SPI.