Smalltalk - Re: [General] Redefining the Class of Instantiated Morphs, Subclassing Instantiated Morphs on the Fly

Smalltalk › Smalltalk Related › Lively Kernel

Re: [General] Redefining the Class of Instantiated Morphs, Subclassing Instantiated Morphs on the Fly

Posted by Robert Krahn-4 on Feb 20, 2014; 2:50am
URL: https://forum.world.st/Re-General-Redefining-the-Class-of-Instantiated-Morphs-Subclassing-Instantiated-Morphs-on-the-Fly-tp4744953p4745086.html

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.

_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel