<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Josh,</div><div><br></div><div>Thanks a lot for this and for writing up on the wiki!</div><div><br></div><div>My initial response:</div><div><br></div><div>- Traits</div><div><br></div><div>I find your response interesting because it's the opposite to mine. I found traits to be nicely concrete - shared parts, so not complete in themselves, but concrete shared parts. In contrast, I found copy-down delegation like in io to be less concrete - the difference between the delegating object and the delegatee wasn't so clear cut. Objects didn't feel so separate.<br><br>I don't find myself thinking of traits as abstract - incomplete, yes, but not abstract.<br><br>The issue of what a trait expects from an object it is embedded in is clearly tricky. One solution is io-style delegation (which isn't hard to do in Self if we want it), another would be to add the slots needed to the trait but mark them as being the responsibility of children (ie make the environment help us)<br><br>As a side comment, what I don't quite feel comfortable with traits is the multiple-level deep nesting of them in parts of the system. I much prefer objects with a flatter heirarchy of traits. </div><div><br></div><div>- Lobby</div><div><br></div><div>Hah. I've never had a problem with the word 'lobby'. If we're talking words, what I don't like so much is using the terms 'parent' and 'child' for the delegator/delegatee relationship. In my mind it's got the primacy of the relationship backwards.</div><div><br></div><div>I get the impression from your critique that you expect the lobby (and other namespaces?) to act more like containers, where you can drag and drop (named?) objects. Would this view lead to a 'known' object having its own name, rather than being an unnamed object given known identity by the key of the slot of canonical object that references it?</div><div><br></div><div>- Transporter</div><div><br></div><div>Did you get any further than the snapshot you sent me? If so, I'd love to see if there are any incremental changes to the transporter code that could help. It is a problem if it is difficult to file out modules containing hand build morphs.</div><div><br></div><div>I agree that we need an object sharing mechanism which works more fluently with disparate teams/individuals who aren't sharing the same source tree; but the compromises in the transporter code are carefully considered, so we need to be thoughtful in our actions.</div><div><br></div><div>Russell</div><br><div><div>On 10/01/2011, at 5:35 PM, Josh Flowers wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div style="background-color: rgb(255, 255, 255); position: static; z-index: auto; ">
<span style="display:none"> </span>
<div id="ygrp-text"><p>As I write up the notes about programming the IRC channel morph <br>
it's clear there isn't much left: I hooked up all the morphs, rearranged <br>
some code, and then spent three days finding the relevant formulas <br>
and incantations to file out my code. I'll still work to get those notes <br>
typed up, but I'm also putting together this e-mail to talk about the <br>
parts of Self I didn't like - mainly because I don't think there's any <br>
chance they'll generate conversation on the wiki.<br>
<br>
So on to the criticism....<br>
<br>
Traits:<br>
Thought I liked traits, but learned that I don't. When I first came <br>
across them they seemed like a natural part of the environment, but <br>
in practice they don't seem to fit.<br>
<br>
Self's a concrete environment but traits become very abstract <br>
objects. When looking at the code you'll often find them referencing <br>
slots that don't exist on the trait itself, even if you go chasing up the <br>
parent slots. Doesn't take me long to realize that the trait object <br>
assumes it's children define the slot, but it still doesn't feel right.<br>
<br>
The lobby:<br>
Pettily, I don't like the name. As a user of the system I don't think of it <br>
as the place where objects enter the world (and if I did I'd still <br>
probably not like 'lobby'), but as a place where the blue prints for <br>
objects are kept. If anything the already-used term 'factory' seems <br>
like a better name.<br>
<br>
But that's just semantics - what really strikes me about the lobby is <br>
that it feels like it should be a virtually-physical place. Much like the <br>
actual morph Factory, there should be a way for me to simply drag <br>
an outliner into the lobby, and then name it (and then drag them out <br>
again when needed).<br>
<br>
The Transporter:<br>
We've gone over this one to some degree so I won't go into detail, <br>
but it also lacks the tangible feel of Self. To back up the point a bit, I <br>
don't believe the IRC channel morph I created has ever successfully <br>
been filed out/into a clean snapshot. The transporter may be a good <br>
tool for a lot of things, but it also feels like there needs to be an <br>
easier way to share objects.<br>
<br>
I also don't like the same-named movies, but I don't think that's<br>
influencing me.<br>
<br>
Just points for conversation (if any of us have the time),<br>
<br>
Josh<br>
</p>
</div>
</div>
<!-- end group email -->
</blockquote></div><br></body></html>