octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: subasgn argument optimization


From: John W. Eaton
Subject: Re: FYI: subasgn argument optimization
Date: Tue, 18 Aug 2009 13:03:02 -0400

On 17-Aug-2009, Jaroslav Hajek wrote:

| On Fri, Aug 14, 2009 at 5:39 PM, John W. Eaton<address@hidden> wrote:
| > On 13-Aug-2009, Jaroslav Hajek wrote:
| >
| > | PS. This patch rebases octave_class on top of octave_struct.
| >
| > It seems that would be a good thing.  I can no longer remember why
| > I didn't do it originally.  I don't think I would have avoided
| > inheritance unless I had a reason, but then maybe I didn't realize how
| > similar classes were to structs.
| >
| 
| Maybe you had a reason; anyway, my implementation spanned a lot more
| problems with inheritance than it was worth, so I reverted the
| rebasing:
| http://hg.savannah.gnu.org/hgweb/octave/rev/8e5009334661
| and I just injected code from ov-struct.cc to optimize out a useless
| copy on nested assignment on fields:
| obj.x(1) = 1; // does copy x in 3.2.x if x is an object.
| 
| Of course, the injection is what I wanted to avoid by using
| inheritance, but right now I think it should be done without altering
| octave_struct or not done at all.
| Your implementation handles multidimensional objects, or inheritance,
| but not both (actually, even constructing such things fails):
| 
| @foo/foo.m
| function f = foo ()
|   a = struct ("x", {1 2 3 4});
|   f = class (a, "foo");
| end
| 
| @bar/bar.m
| function b = bar ()
|   a = struct ("y", {1 2 3 4});
|   b = class (a, "bar", foo());
| end
| 
| octave:1> a = foo
| octave:2> b = bar
| error: invalid structure assignment
| error: called from:
| error:   /home/hajek/devel/octave/patches/@bar/bar.m at line 3, column 5
| 
| the basic problem is (besides missing code support in the nested part
| of octave_class::subsasgn) that you can't store a single object inside
| a field of multidimensional Octave_map - all fields must be the same
| size.
| 
| Maybe a possible solution would be to not store parent objects as
| regular fields, but separately; you'd need to hack the field lookup
| for that and probably also plain () indexing and indexed assignment.
| But then I still wonder what obj.parent_class_name is supposed to do
| if obj is multidimensional (normally, you should get a cs-list).
| Apparently the old OOP model is documented only poorly from Matlab,
| and I don't have Matlab, so I should probably resist further playing
| with this part to avoid breaking something.

I wonder how important it is to have multidimensional objects?  Are
they really used in practice?  If so, what code uses them?

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]