Generic Selectors? #207

Closed
ifesdjeen opened this Issue Nov 7, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@ifesdjeen
Member

ifesdjeen commented Nov 7, 2013

Do you think it'd make sense to make Selectors generic?

Right now selectors are not really type-safe, and there're a lot of type checks in most of them. Making it generic will avoid type casts, and even potentially improve performance.

@jbrisbin

This comment has been minimized.

Show comment Hide comment
@jbrisbin

jbrisbin Nov 7, 2013

I actually started out with them type-safe but moved away from that because of the casting and compiler warning suppression I had to do throughout the code that uses them. I also wanted to match on Object rather than restrict the types that the Selector responds to. I don't think we want to restrict the possible types we can match against in the interface.

Most Selector implementations descend from ObjectSelector, which is type safe. That's the approach I took to try and get both type safety and the fundamental flexibility of an Object signature on the interface.

But if there's a way to make it faster, I'm of course all ears (or, in this case, eyes :).

jbrisbin commented Nov 7, 2013

I actually started out with them type-safe but moved away from that because of the casting and compiler warning suppression I had to do throughout the code that uses them. I also wanted to match on Object rather than restrict the types that the Selector responds to. I don't think we want to restrict the possible types we can match against in the interface.

Most Selector implementations descend from ObjectSelector, which is type safe. That's the approach I took to try and get both type safety and the fundamental flexibility of an Object signature on the interface.

But if there's a way to make it faster, I'm of course all ears (or, in this case, eyes :).

@ifesdjeen

This comment has been minimized.

Show comment Hide comment
@ifesdjeen

ifesdjeen Nov 7, 2013

Member

Even now, in classes derived from Object Selector, it's necessary to do a cast for the object that matches (#matches method still accepts Object). Avoiding cast there could spare some time.

I'm not saying that anything should be restricted. If someone really has to dispatch on so many objects that it's impossible to create enough selectors for it, he can still implement Selector<Object>. But generally, Selector<T> where match accepts T would solve the problem an help avoiding casts, therefore improving performance in most general cases such as String & Regexp.

Member

ifesdjeen commented Nov 7, 2013

Even now, in classes derived from Object Selector, it's necessary to do a cast for the object that matches (#matches method still accepts Object). Avoiding cast there could spare some time.

I'm not saying that anything should be restricted. If someone really has to dispatch on so many objects that it's impossible to create enough selectors for it, he can still implement Selector<Object>. But generally, Selector<T> where match accepts T would solve the problem an help avoiding casts, therefore improving performance in most general cases such as String & Regexp.

@ifesdjeen

This comment has been minimized.

Show comment Hide comment
@ifesdjeen

ifesdjeen Nov 7, 2013

Member

Just composed a pull request #209, maybe that explains what I had in mind a bit better.

Member

ifesdjeen commented Nov 7, 2013

Just composed a pull request #209, maybe that explains what I had in mind a bit better.

@ifesdjeen

This comment has been minimized.

Show comment Hide comment
@ifesdjeen

ifesdjeen Aug 15, 2015

Member

This is so far adressed in reactor-extensions/reactor-pipe

Member

ifesdjeen commented Aug 15, 2015

This is so far adressed in reactor-extensions/reactor-pipe

@ifesdjeen ifesdjeen closed this Aug 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment