Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-11-15 Thread David Mertens
Hello everyone, Let me make sure I get this right. Two or more PDLs are being operated on to produce a result, but nowhere are the two consulted for a desired output type or initialization. This has been tracked down to a loss of context somewhere in the chain of function calls. There are two prob

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-11-02 Thread Ingo Schmid
currently, I ran into this issue as well. It would help a lot if initialize would receive information on what it triggered, i.e. the call stack. The call of sin($x) should give in initialize @_ =($class, &operation, @arguments) . Is this doable? I think it is mostly code in PP.pm but I don't under

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-26 Thread Chris Marshall
Another possible wart in the PDL operator overloading is that the overloaded functions are done as &PDL::operation and not 'operation' strings which could be resolved and a method or overridden in the subclass. I don't know if that is relevant to the OO implementation using "has a" in place of "i

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-26 Thread Diab Jerius
Looks interesting, but not well maintained; neither of the two issues reported had a reply. On Tue, Oct 25, 2016 at 1:55 PM, Chris Marshall wrote: > You might take a look at > http://search.cpan.org/~dconway/Class-Multimethods-1.70/ which does a > perl-level implementation of multimethods. Doe

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-26 Thread Diab Jerius
Overloading is definitely an issue. but the assumptions made by initialize() shouldn't be overlooked. I'll expand the text in PDL::Objects to discuss them. On Tue, Oct 25, 2016 at 10:30 AM, Chris Marshall wrote: > On re-reading, I think the problem we're really discussing here is > the operator o

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-25 Thread Chris Marshall
You might take a look at http://search.cpan.org/~dconway/Class-Multimethods-1.70/ which does a perl-level implementation of multimethods. Does this resolve these overload issues? (For what it is worth, the C Object System, COS, support multimethod resolution and so using it for PDL::NextGen might

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-25 Thread Chris Marshall
On re-reading, I think the problem we're really discussing here is the operator overloading and the difficulty seems to be because the overload resolution doesn't handle selection between two classes. It is this that "forces" the result to be PDL or MyPDL. I'm not sure a real solution is possible

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-25 Thread Ingo Schmid
Diab, from my - very limited - experience with inheriting PDL (PDL::IO::Nifti), I end using the native piddle ($myvar->{PDL}) for everything than the most basic operations; I've wrapped that into a method. Is this an acceptable work around for your use case? The left-hand side will always have to

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-24 Thread Chris Marshall
Thanks for the additional clarification for context---what a mess! >From your example, it seems that the current PDL approach for OO via "has-a" doesn't work but my question is what method would work? Is there an example of an OO language or framework that can be shown to work for this type of pr

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-24 Thread Diab Jerius
On Mon, Oct 24, 2016 at 12:43 PM, Diab Jerius wrote: > initialize() currently must assume that object construction can be > done without any arguments to the constructor. That's inappropriate > in some instances (as described above). And once more, to clarify... initialize() is not passed any c

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-24 Thread Diab Jerius
On Mon, Oct 24, 2016 at 12:43 PM, Diab Jerius wrote: > initialize() currently must assume that object construction can be > done without any arguments to the constructor. I shouldn't have used the word "currently", as that implies there's a way of changing its behavior, and I don't have any good

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-24 Thread Diab Jerius
On Sat, Oct 22, 2016 at 2:57 PM, Chris Marshall wrote: > Hi Diab- > > I haven't done much with subclassing from PDL but > I have noted some warts as in PDL::Complex. > > For the PDL::NextGen work I would like to have an > approach that is interoperable with Moo[se] and > possibly other OO framewor

Re: [Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-22 Thread Chris Marshall
Hi Diab- I haven't done much with subclassing from PDL but I have noted some warts as in PDL::Complex. For the PDL::NextGen work I would like to have an approach that is interoperable with Moo[se] and possibly other OO frameworks. One thought was to make PDL-ness a Role rather than a class as th

[Pdl-devel] Subclassing PDL made easier with PDLx::DetachedObject

2016-10-21 Thread Diab Jerius
I've been having lots of fun lately creating complex classes which inherit from PDL. Unfortunately, when PDL creates objects on the fly, e.g. when it needs to store the result of an operation: $mpdl = MyPDL->new; $npdl = $mpdl + 1; # $npdl will be of class MyPDL it can't pass along any addit