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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

timfelgentreff
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Robert Krahn-4
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
Loading...