[Omake] allowing for lazy extends?

[Aleksey Nogin]

On 26.01.2007 03:09, Erick Tryzelaar wrote:

> This is vaguely related to the following bugs 582 and 583, but for 
> 0.9.8. Do you think it would be possible to allow lazy extensions of 
> objects? I'm not sure how objects are currently implemented, but if it 
> is the classic "if a field doesn't exist in the current object, check 
> the parent", 

It's stronger than that - extends eagerly brings in all the fields of 
the parent (overwriting all the fields the object might already have):

% X. =
X>        X. =
X>           x = foo
X>           .
.
- : class Object
        x = "foo" : Sequence
        [...]
% Y. =
Y>        Y. =
Y>           x = bar
Y>           extends $(X)
Y>           .
.
- : class Object
        x = "foo" : Sequence
        [...]

> Without it, I run into all sorts of issues because "extends" forces 
> evaluation, even if it's a lazy variable. So I have to do all sorts of 
> hacks in order to avoid extending things until the last possible moment.

Note that you can implement lazy extension yourself:

lazy_extend(name) =
    private.Obj = $(getvar $(name))
    private.vars[] =
    private.skip[] =
       $'$class'
       object-length
       object-mem
       object-add
       object-find
       object-map
       object-foreach

    lazy_update(var, val) =
       if $(not $(mem $(var), $(private.skip)))
          private.vars[] += $(var)
          this = $(obj-add $(this), $(var), $`(obj-find $(getvar 
$,(name)), $,(var)))
          export
       export

    obj-map($(private.Obj), $(lazy_update))

    export $(private.vars)

X. =
    x = 1

Y. =
    lazy_extend(X)
    y = 2

println($"$(Y.x) - $(Y.y)") # Prints 1 - 2

X. =
    x = 2

println($"$(Y.x) - $(Y.y)") # Prints 2 - 2

Aleksey

P.S. On one hand, I would prefer not to make any significant semantic 
changes in 0.9.8 - finishing the work on scalable variable scoping and 
reuniting the two branches has priority.

On the other hand, we do need to take a systematic look at how the 
laziness is implemented and probably come up with a more flexible and 
consistent approach - see the discussion at 
http://bugzilla.metaprl.org/show_bug.cgi?id=628