Smalltalk › Smalltalk Related › Lively Kernel

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

timfelgentreff

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

The lively devs have struggled with various attempts to solve this
problem. There were attempts at merging/updating morphs from their
originals, and at one time, we had an editor that could edit multiple
morphs at a time (see
http://blog.bithug.org/uni/12FelgentreffTessenowThamsenObjectGroups.pdf
for an explanation). Right now, a workaround is to select the morphs
(dragging to select) and then inspect the selections. It has a property
(selectedMorphs, IIRC) and you can run a script (for
example "addScript" ;) ) on each of them.

There were other attempts at fixing this, Jens probably knows more.
From: Sean P. DeNigris
Sent: 19/02/2014 19:41
To: [hidden email]
Subject: Re: [lively-kernel] [General] Redefining the Class of
Instantiated Morphs, Subclassing Instantiated Morphs on the Fly
Philip Weaver wrote
> A significant distinction appears to exist in Lively between writing
> classes in the ide and interacting with objects using the inspector... I
> wish I could click on an instantiated morph and select either "New
> subclass" (even "Change class")

Bump... this is an important topic. How does one generalize from visually
created prototypes. For instance, you create a morph, then make copies, but
realize that all the copies should have an additional property or script;
how does one avoid adding it individually to each individual morph?

-----
Cheers,
Sean
--
View this message in context:
http://forum.world.st/General-Redefining-the-Class-of-Instantiated-Morphs-Subclassing-Instantiated-Morphs-on-the-Fly-tp3033887p4744932.html
Sent from the Lively Kernel mailing list archive at Nabble.com.
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
_______________________________________________
lively-kernel mailing list
[hidden email]
http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel

Sean P. DeNigris

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

Administrator

Tim Felgentreff-2 wrote

The lively devs have struggled with various attempts to solve this
problem

In Self, one can share behavior among copies quite easily by defining a new parent before making the copies of the morph. By default, a Morph has "traits Morph" as its parent. What you do is make a new object to be the parent and inject between your morph and "traits Morph" (it is your morph's parent and "traits Morph" is its parent). Then you add shared behavior to the shared (between copies of your morph, but not all morphs) parent.

I don't know much about js, but could one be able to inject a new prototype between the morph and the Morph class and add (or be able to promote) behavior to it?

Cheers,
Sean

Sean P. DeNigris

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

Administrator

Sean P. DeNigris wrote

In Self, one can share behavior among copies quite easily by defining a new parent before making the copies of the morph

See http://handbook.selflanguage.org/4.5/morphic.html for an example. Search for "(| parent* = traits morph |)" for the creation of the new parent.

Cheers,
Sean

Robert Krahn-4

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

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