[self-interest] Filing Out A Composite Morph?

Jan-Paul Bultmann janpaulbultmann at me.com
Thu Dec 23 12:11:24 UTC 2010


Hey,
I totally agree that one should simply save a morph as is without any textual additions.
What if we didn't care about the state the morph currently has. We simply dryfreeze it and revive it later.
I think the reason the whole filing out thing is so darn complex with annotations and creator slots e.t.c is because they didn't wan't to drag over state.
But what is wrong with that :)? I mean how cool would it be to send a document over the air not as a text file, but as a bunch of living objects. (I am ignoring the security risk for now since you can also inject malicious code with the transporter.).
The same goes for the global hierarchy, why are there creator slots and initialization values. The values in the prototypes should be initialized to the right value anyways, and I think it won't be that hard to detect cyclic object creation or multiple references (If this is not already done anyways :)).

Thoughts?

cheers Jan
On Dec 23, 2010, at 3:33 AM, Russell Allen wrote:

> 
> Josh was kind enough to share his snapshot with me, and I've been looking at this; I don't yet have a conclusion but here is my process:
> 
> First I filed out the ircChannelMorph and filed it into a new world, but it was missing all of its copy down slots (so no rawMorphs etc).  This turned out to be because the transporter thinks in slots: from its perspective the annotation for the ircChannelMorph is in the 'ircChannelMorph' slot on 'globals' (which wasn't part of the ircClient module) and not really in ircChannelMorph itself.  When that was changed, the ircChannelMorph filed out and then back it with its annotation and hence its copied down slots (rawMorph etc).
> 
> Now, although the rawMorphs copied down slot was present, it no longer had any submorphs in it.  Partly this seems to be because the transporter doesn't maintain local values for copied down slots but re-copies their value when saving and loading (so rawMorphs is initialised to a vector copy).
> 
> Removing the rawMorphs slot from the copy down list so it was just a normal slot on ircChannelMorph, and then drilling down setting creator slots and modules meant the next level of submorphs were filed out and in - but then their rawMorphs were similarly missing!
> 
> Now unless I am doing something wrong, this seems a bit of an incompatibility between the transporter, copy down slots, and morphic.
> 
> The obvious solution is to add an 'initialiseMorph' method which is called when filing in and builds the appropriate prototype structure for the morph. This is more or less what I did when I used to use Squeak's morphic.
> 
> Personally I don't like it.  When I build a lego castle and then put it away in a cupboard, it is still in one piece when I take it out later to play. I don't have to write down my castle building instructions and redo them every time.
> 
> It turns mophic into a programatic ui where we construct our morphs from text descriptions. Icky.
> 
> I'm open to suggestions and solutions, meanwhile, back to thinking...
> 
> - Russell
> 
> 
> 
> 
> 
> On 18/12/2010, at 8:05 PM, Josh Flowers wrote:
> 
>>  
>> 
>> Unfortunately that didn't work either.
>> 
>> A Morph saved using saveMorphInFile can only reference a limited 
>> set of other object types (strings, methods, morphs, collections of 
>> morphs, and 'concrete' objects) - mine references a ircServer object.  
>> Clearly there are a couple different ways I can refactor the code, just 
>> need to spend some time thinking about which one I like....
>> 
>>> That looks promising - I'll try it out this weekend. 
>>> 
>>> Thanks Jan,
>>> 
>>> Josh
>>> 
>>> On Dec 9, 2010, at 2:08 AM, Jan-Paul Bultmann wrote:
>>> 
>>>> 
>>>> 
>>>> There is a passage about this in the manual. http://docs.selflanguage.org/morphic.html
>>>> 6.4. Saving a Composite Morph
>>>> The System for filling out morphs seems pretty raw around the edges and really needs to be improved if we want to create usefull apps.
>>>> 
>>>> Hope this helps,
>>>> cheers Jan
>>>> On Dec 9, 2010, at 5:12 AM, Josh Flowers wrote:
>>>> 
>>>>> Does Self support filing out composited morphs? I composited a number of morphs to create an irc chat UI, but I'm having troubles writing it out.
>>>>> 
>>>>> I turned an instance of the morph into a prototype; added it to a module; setup the copy-down slots to Copydown parent: 'rowMorph', Copydown selector: 'copyRemoveAllMorphs'... and I think that's about it.
>>>>> 
>>>>> The module files out and in without errors, but when I try and create an instance of the prototype I get an error message about 'rawMorphs' being missing. I can fix this by manually setting the irc morph's copy-down attributes (they don't seem to copy over as part of the file-in/out process) but then the original submorphs don't exist.
>>>>> 
>>>>> Besides having trouble describing the problem - am I doing something wrong?
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20101223/7ccc3c31/attachment.html>


More information about the Self-interest mailing list