octave-maintainers
[Top][All Lists]
Advanced

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

Re: FYI: subasgn argument optimization


From: Robert T. Short
Subject: Re: FYI: subasgn argument optimization
Date: Tue, 18 Aug 2009 10:20:31 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090606 SeaMonkey/1.1.17

John W. Eaton wrote:
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



I had never thought of such things but I can think of a couple of uses for them in my own work.

I have a couple of other non-octave things that need to be done before I get back to this, but I have added this to my long and growing "to do" list. First, I will see what MATLAB does, then I will try to figure out how to go about doing it. I would really like to put this legacy OOP stuff to bed so I can get the new stuff implemented, but we do what we can.

Bob
--
Robert T. Short, Ph.D.
PhaseLocked Systems


reply via email to

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