I read the paper on perspectives. It has some interesting ideas, but from my perspective the concluding sections seem to say that it failed to solve the problems it set out to solve.
The use of perspectives to solve security was clearly not a solution as they worked through that one. The use of perspectives for creating private interfaces only worked in the absence of other perspectives, which seems to be true in the multi-user and multi-view cases as well. I would make the following changes to their approach and see if the result was an improvement:
1) Allow access to "context" provided by enclosing activations. 2) Allow fuzzy dispatch (you think you see one object, but there is a constellation of objects that cooperate to respond to the message. The parts of an object could be managed in a way similar to the layers in the paper, but would allow "perspective" to be taken from the context, or elsewhere, and would allow multiple active perspectives to influence the dispatch.
The suggestion that extending the language requires thought and experimentation I wholly agree with. Peer review of the proposed changes will also be important. The subjectivity idea has merit as a way to mange complexity. The COM idea that you must ask an identity for a perspective is similar, but would need a contextual frame of reference to match up.
On Jun 25, 2004, at 4:21 PM, Jecel Assumpcao Jr wrote:
On Friday 25 June 2004 17:12, Michael Latta wrote:
The current license basically says do what you want with it so long as we do not get blamed.
All versions that Sun has released had a similar license, though the early versions had the infamous "advertising clause" (which I don't mind at all).
The Self 1.X VMs were never released at all. I don't remember about 2.0, but at least I don't have a copy of it. And Self 4.1 was internal to Sun four about three years before being finally released under the current license.
- I am considering making the inheritance of structural slots
declarative. Rather than listing the copydowns in each child object, allowing the parent to annotate a slot as copied. The child objects would still need to be able to exclude those they replace with behavior.
This is actually how it is done in the programming environment (you set the slots in the parent as "copydown" and they show as pink in the outliner) even though saving a module as text creates some code to actually implement this imperatively.
- I am considering adding an annotation to a slot that will cause
it to be cloned when the object is cloned.
These ideas come from working with modeling where there is more declarative work. The items above would also need syntax to support textual definition of those aspects. For example 2 above could be <slot>+ to indicate aggregation. The idea is to reduce errors and reduce code to manage these aspects of a system.
Ok, so you want to control "deep copies". It wasn't clear to me what you meant above by "cloning a slot". This is a very interesting issue. When you clone a morph, you certainly want to clone its submorphs too.
Let me know what you think, or if there are good reasons to leave it in code.
It is easy to come up with interesting features that make some example or other nicer, as David Ungar always says in his talks. The problem is that language complexity grows exponentially since each new feature interacts with all previous ones.
Both issues you mentioned can be viewed as particular instances of something larger - how can you organize stuff so sometimes you see a single object and sometimes you see smaller pieces which can be shared in interesting ways?
My first suggestion would be for you to read the Us paper (a subjective version of Self): http://citeseer.ist.psu.edu/smith96simple.html
This won't solve your problems, but should help you think in a more general way about them.
The "an object is really a tree of stuff and not just the root" thing was a major complication for me in parallelizing Self in tinySelf 1 and in my current work. Beyond subjects/viewpoints, there is an interesting idea I used in a language called NeoLogo which is "roles". I won't go into details here, but at first I thought that viewpoints was a good replacement for this, but now I see that though very similar they actually complement each other.
I would like one solution to all of these problems, and which made the resulting language even simpler. Never, ever forget "the power of simplicity".
Kyle Hayes wrote:
A little off track, but, I'd like to see the following in Self:
- a drastically simplified VM so that it can be more easily
ported. All ports but the Sparc and Mac are a little flaky in my experience (sometimes a lot flaky). Having a VM that is so difficult to port makes support and expansion of the Self "marketplace" more difficult.
A proper Self implementation should be in Self.
- move more of the optimization into Self rather than hardcoded in
the VM in C++.
See 1 ;-)
I like your ideas about the language! While I like Self's simplicity a lot, it is often nice to have reasonable short cuts for very common idioms like those you've covered above.
Unless you want to use it in a scripting language style (like 3.0 and earlier), Self is a language and an environment. We can have as many shortcuts as you want in the latter without having to complicate the former. The copydown thing is a good example.
Yahoo! Groups Links