Could use the visitor pattern and have the visitor implement the logic.

On Sun, May 22, 2011 at 4:07 AM, Ted Dunning <[email protected]> wrote:

> This is an instance of the classic double dispatch problem.
>
> There are no really good answers in single dispatch languages like Java.
>  My
> own opinion is that there aren't a lot of good answers in multi-dispatch
> languages either.
>
> For now, I think that access to the private data trumps other
> considerations.
>
> On Fri, May 20, 2011 at 9:53 PM, Jake Mannix <[email protected]>
> wrote:
>
> > Hmmm... standard OO practice would be "keep the logic specific to the
> > impl with the impl".  Also: this could get really ugly, due to proper
> > encapsulation
> > we currently have, if not impossible: do to DenseDense things most fast,
> > you
> > would need access to the (rightfully) private double[].
> >
> > I'm not sure what would be gained...
> >
> >  -jake
> >
> > On Fri, May 20, 2011 at 9:31 PM, Lance Norskog <[email protected]>
> wrote:
> >
> > > Working through Vector/Matrix classes I found a lot of things that
> > > could be tightened.
> > >
> > > -Would it be worthwhile to change the Vector and Matrix structures so
> > > that things like "sparse against dense" and popped in a central place?
> > > For example, Vector would have a few methods, and there would be a new
> > > "VectorOps" class. The latter implements "sparse v.s. dense" using the
> > > classes of input vectors.
> > >
> > > For example, DenseVector currently has "if the other is DenseVector,
> > > here is the fast path" code bits. Under this redo, there is a
> > > DenseDense operator. Vector.multiply(vector, vector)  is a static
> > > method that pulls the classes of the inputs, and finds the DenseDense
> > > version.
> > >
> > > Yes, it would be an invasive patch.
> > >
> > > Lance Norskog
> > > [email protected]
> > >
> >
>



-- 
Yee Yang Li Hector
http://hectorgon.blogspot.com/ (tech + travel)
http://hectorgon.com (book reviews)

Reply via email to