On Tue, Apr 23, 2013 at 6:59 PM, Rob Vesse <[email protected]>
wrote:
I've noticed in some of the optimization work I've been doing
lately there is a somewhat inconsistent pattern around the
visibility of constructors on the various Op implementations.
Some have public constructors while some require static methods to
be used to create them
Is there a particular reason for this and could we move to
supporting both modes universally across all Op implementations or
would this create issues?
Shouldn't be a problem. I take it you are referring to the join-family
of Ops. Inconsistent naming as well - OpSequence.create vs
OpFilter.filter -- that's history. The OpFilter.filter style works
better with import static.
Some of the factory-ish methods do do some additional work other than
call the constructors and return an Op, not the specific type itself
because of that.
OpSequence.create(Op,Op) does null reduction and collapses OpSequence
arguments. It makes it convenient when looping producing an OpSequence's
OpJoin.create used to so join identity reduction but that's the separate
createReduce now.
Downside is that most Ops use constructors so it's not a small change.
The style I'd suggest is name-specific so you can write function call
style when used with import static. Even a single OpFactory with
.filter, .join, .sequence statics.
On 24/04/13 20:40, Claude Warren wrote:
I've noticed this in the past. I think that we should move to the
factory/builder pattern with static methods used to create the Ops. I
think there are a couple of constructors that won't work otherwise,
but I am not certain.
Which did you have in mind? I've have thought that a constructor can be
replaced.
Andy
