[lively-kernel] [General] Redefining the Class of Instantiated Morphs, Subclassing Instantiated Morphs on the Fly

[Robert Krahn]

1. Lively supports traits as well. Traits can be applied to classes,
objects,
or traits themselves.

To try it out, open a rectangle and run

Trait('OnClickTrait', {
    onMouseDown: function() {
        show('Someone clicked me!');
    }
}).applyTo($morph('Rectangle'), {override: ['onMouseDown']});

(Traits in Lively don't replace methods in the inheritance chain. Since
#onMouseDown is already implemented in the Morph base class we need the
"override").


2. The problem is not in finding a language construct to share behavior or
do
mixin-style sideway compositions, the problem is about behavior sharing in a
distributed setting.

Or to put it differently: How to package up objects and behavior they
depend on
in a non-centralized way that is suitable to use in a high-latency network
as
the Internet and how to manage dependencies between objects and behaviors.

That's pretty abstract, I'll make it more concrete: The example above could
be
"published" by taking the Rectangle and publishing it in the PartsBin. It
will
remember that a OnClickTrait was applied to it. However, it will not
serialize
the Trait itself. If the Trait was defined in a module, this module will
become
a load dependency of the Rectangle. So the next time when you load the
Rectangle the module the Trait is in will be "required".

This is somewhat a solution of the problem you have described but it also
adds
new problems: We now have two kinds of objects/behaviors: Concrete objects
in
the PartsBin and "code" in modules. This clearly is bad:

- There exist only a thin dependency from the object to the module. When
  changing the module you might not be aware that yu break the object
behavior as
  the module is only tracked by its name not its version.

- There are now two mechanisms to define behavior/state. When should you use
  which?

This problem is currently one of the biggest challenges that we hope to
solve:
We ideally want a system that consists solely out of objects (objects don't
need to be concrete, graphical things). Dependencies between those objects
should be stated flexibly enough so that fine-granular compositions are
possible. If we would have such a system the Trait above would just be
another
PartsBin thing. When it is changed it would either push its changes to the
Reactangle (if it would still fit the rectangle's requirements) or the
rectangle could be made to pull changes of its dependencies when needed
(like a
"software update").

So far we have not yet made a lot of progress in this direction but hope to
propose solutions in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20140219/b69eed4f/attachment.html>