Re: FYI: subasgn argument optimization

[Jaroslav Hajek]

On Tue, Aug 18, 2009 at 7:03 PM, John W. Eaton<address@hidden> 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
>

Scarcely at best, no doubt. Most often, you probably just have
multidimensional fields. And it should be emphasized that
multidimensional objects will work per se, just not together with
inheritance.


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz