Great post! ( comments below )  Your work sounds very interesting- mind if
I post this to the DirectInteraction VWiki that I'm hosting?


Henrik Gedenryd wrote:
> 
> Ok, I tried hard but I couldn't restrain myself any longer.

It worked!


> My stuff doesn't run right now since I'm rewriting the foundation with my
> aspect weaver (see my discussion with Marcel a couple of weeks ago). To
> summarize what I've found:

The curse of active development...


> - Roles/perspectives (as I am implementing them) are functionally equivalent
> to AOP aspects, even though they may be conceptualized differently. (so in
> the following, role = perspective = aspect, albeit I use them variously to
> stress different points). When I realized this equivalence a month ago I
> started on the Smalltalk aspect weaver, which now works well enough for use
> in my implementation of other things.
> 
> - An aspect is a non-instantiable "slice" of an object, with potentially
> both state and process: In Smalltalk, it can have both variables and
> methods. (Ie. it responds to a certain protocol.)

( a random thought- I wonder if a relationship to active object models,
such as those that can be created with ActTalk, might exist or be worth
establishing ).


> - You may compose perspectives/aspects out of others, hierarchically. Thus a
> full entity/object is made by merging multiple perspectives/aspects into
> one.
> 
> - This composition mechanism supersedes inheritance.
> 
> - As I described in the ealier mails, the perspectives yield the most
> powerful inheritance/aspect combination mechanism that is theoretically
> possible--since it has full Turing equivalence. It could eg. easily weave
> the BitBlts for various byte orders and pixel formats that Andreas described
> yesterday, while optimizing away unnecessary operations automatically if
> done right. Currently it eg. replaces do: enumerations for single value
> collections with "aBlock value: element", and eliminates/evaluates the block
> for the given element too, if possible.
> 
> - A role is equivalent to (a better version of) SOP subjects, allowing
> access to only a subset of the aspects of the full entity/object.
> 
> - Hence, you get Capabilities (hello Lex!) for free by handing out
> references to such roles, thus restricting the access protocol to the
> object.
> 
> - For this reason, the general encapsulation of objects is removed in favor
> of the capability functionality. In other words, encapsulation is late-bound
> by the capabilities.

I've been trying to do something similar to this in my user interface work-
objects make claims about the interfaces they support ( or the roles that they
claim ), and the interaction with those objects is based on those claims...
so in a way, I partially achieve one of my goals which is that I don't want
additional code in the objects which is there solely to support the user
interface- the code is already there to support a different model of programming
anyway.  That helps in figuring out what services to show the user, and how to
negotiate things like drag and drop interactions where the validity and result
of an interaction is dependent upon the object being offered to the target.

It might also be very useful in contextual role situations ( or perhaps in
capability approaches ) where an object might aquire additional roles while
in the context of another object- the best example I can think of right now
would be something like the contextual extension ( perhaps even modification )
of an object's behavior as it moves from one conceptual environment to another,
such as might happen as an object migrates from one image to another, or in having
references to the same object appear in separate environments within the same image-
this is already an issue in Oasis, where it is possible to construct different
models of the Smalltalk environment and to have objects be referenced across
environmental boundaries.  In those cases, one of the Deep questions is what
should the appropriate behavior of the object be- that of it's native home,
or that of the environment in which a message was sent?  I lean to the second,
but I think it is also the hardest to accomplish.



> Take Morphs as an example of Aspect decomposition (a simplified version of
> existing basic Morph classes):
> 
> any Morph has the aspects {Shape. Surface. Composition. Drawing.
> Interaction} + some others with peripheral stuff.
> 
>   RectangleMorph << {RectangleShape. 2DSurface. MorphComposition. 2DDrawing.
> MorphInteraction}
>   EllipseMorph << {EllipseShape. etc.}
>   etc.
> 
> Shape has the instvars 'bounds fullBounds'; cf. method categories
> 'geometry', 'position', 'rotate/scale/flex'. This is the shape/geometry
> aspect of the morph (ie. its form), cf. classes like Rectangle, Point, Path,
> etc.
> 
> Surface aspect concerns color, surface texture etc. has the instvars 'color
> (fillStyle)' . 1D surface has OutlineSurface aspect, 2D surface has
> OutlineSurface + PlaneSurface. 3D also possible.
> 
> Composition handles morph/submorph composition tree, has the instvars 'owner
> submorphs'; cf. method categories for adding/removing submorphs, accessing &
> enumerating them etc., + copying.
> 
> Drawing implements drawOn: etc. It obviously needs to use stuff from Shape &
> Surface aspects and so on (eg. circle shape & color fill). This is where
> weaving comes in. Since EllipseShape ~~ RectangleShape, the woven drawOn:s
> become different, and so on.
> 
> Interaction handles events, drag'n'drop, menus, halo, etc. (Currently in
> HandMorph)

That's pretty much what I had in mind for the way things should fall out.
If this worked well, then we'd be set for the next step, which I think
of as being Pattern-oriented development ( but probably not in the sense
that the word "Patterns" is commonly used today ).   There are lots of things
that are done over and over again, and these could be found, categorized, named,
and parameterized so that their instantiations perhaps would provide the material
you use in your weaver.



> Les Tyrrell wrote:
> 
> > I think that this is possible in Squeak or VisualWorks because
> > about the only vm requirement for method lookup is that the method
> > dictionary be found in a particular slot of an object's "class".
> > Beyond that, there is almost no requirement that the "class" be
> > a, uh, "Class".  So, it could be a Role instead.
> 
> It is quite possible. My aspects disguise themselves as classes, which gets
> them into the Browser, sort of, and so on. (Have you ever written a class
> that "inherits" from its class variables?) Currently, the aspect weaver
> mostly doesn't store woven methods, instead it patches #sourceCodeAt: so
> that when you click on a selector in the browser, it weaves together the
> method source on the fly from the included aspects! (This was actually the
> easiest way. And parsing the contributing sources takes much more time than
> weaving the result. But one rarely notices a delay.)

I am curious about what you are weaving here- why would you need to weave
a single method from multiple aspects- wouldn't the methods be atomic
within an aspect? ( or am I stating this correctly ? )




> > I'm sure that there would be other problems with this- but then,
> > the notion is that as far as I the programmer know, I am composing
> > the class out of Roles.
> 
> You bet there are problems ;) Method lookup was a very minor issue actually.
> The MOP is not very easy to adapt, but the Browser is really hairy too in my
> experience. Everything is *very* hardwired for classes and the current
> inheritance/late-binding scheme. Regular overriding is just not possible.
> What are really properties of objects/classes are now hardwired into
> Browser, ClassOrganization, ChangeSets, etc., and so inheritance/overriding
> for aspect semantics doesn't really work without a *lot* of ugly hacks, aka
> od hac solutions--it's not really OOP any longer.

YUP!  Hence the need for a different user interface to the programming model!



> Of course this is just a symptom of the limits of the present inheritance
> scheme ;) -- Class, Metaclass, ClassBuilder, ClassOrganization and the whole
> Browser should really be different perspectives on each object! If they
> were, things could be done right.

My feelings exactly- too many "virtual" objects in the existing programming
model, things that should have been made into real objects with real classes.
I think that would have made it easier to throw the old model away by adapting
existing tools to a different model.



> And the browser as a perspective is of course where the dynamic browsing
> stuff comes in. The work I've just described comes from making every aspect
> of an object (no pun intended) in the language be hands-on manipulable
> *automatically*. This is done by giving every object multiple built in
> perspectives: The "regular object role" is just one perspective among
> others, the "computational entity" perspective; then there's the "working
> material" perspective (to stress that it is not just a visual appearance/UI,
> but has full direct manipulation capacity), cf. a "Morph" perspective.
> 
> This perspective (with different views/sub-perspectives on objects'
> contents) then replaces both browser and inspector. The things I have done
> or considered are similar to many of the things you suggest:
> 
> > ... I've been trying to come up with a way of interacting as
> > directly as possible with objects, while also having each object provide as
> > many views of itself as possible. ... without requiring
> > the object to have lots of code in it to support the generation of those
> > views.  Ideally, none. I want to interact with all objects, not just the
> > ones that have special purpose user interface thingies built for them.
> 
> Exactly what I am after.
> 
> > I've tried several times to build this sort of thing, and have made
> > some progress on some of my goals.  However, for me it has been a
> > pretty tough problem.  But I really believe that if I had this sort
> > of interaction framework that it would really be something.
> 
> My scheme is not as complex (I'd say unrealistic) as it may seem here, since
> I get a lot of leverage from a few constructs. For example, what I call
> "parts" are subobjects contained by an object, cf. instance variables/slots,
> but they at the same time have the functionalities of perspectives, roles,
> aspects, and subjects (and capabilities). And aspects subsume inheritance,
> and so on.

That's an important point- it would do no good to do this if the resulting
system appears to be incomprehensible, or based on concepts that mere mortals
cannot be reasonably expected to understand.  The resulting model of programming
must provide real benefit, and cannot be percieved as being more complex-
ideally, it should appear to be an entirely reasonable way of doing things.
So far, I don't know of any reason why the approach you reccomend should
neccessarily fail at this.


> My aim was however never to make this backward compatible with Smalltalk.
> The spoilsport part of this is that Smalltalk as we know it is fundamentally
> unsuitable for doing it--it would indeed be extremely hard to do these
> things within the boundaries of plain Smalltalk. The current
> Class/MetaClass/Browser/ClassBuilder/ClassOrganization stuff is already
> pushing the status quo to its limits IMO (as is Morphic).

Oasis allows you to build any MOP you want, within the limitations of
the existing VM.  The Class/Metaclass relationships can be completely
redone in almost any manner- the VM requirements are that the behavior of
an object is defined by another object ( which could be the same object-
Metaclass is an existing example in many dialects ), that the behavioral
object has the method dictionary in a particular slot, and a "superclass"
reference in another, and that inheritance must be terminated with a
reference to "The One True Nil". ( might be others, but I think that's
the gist of it ).

> Perspectives/roles/aspects would be a minimal prerequisite, and this of
> course violates the existing Smalltalk inheritance/composition system and
> semantics pretty wildly. Of course Alan has encouraged us to ride the blue
> areoplane with the future of Squeak, but I wonder if SqC really means it ;)
> 
> So, this is a question for SqC (I am asking you in public as Dan wanted!):
> How far are you prepared to go in breaking with the existing Smalltalk "pink
> plane" language to get on the blue plane? This would at a minimum yield
> parts of the system implemented in semantics other than Smalltalk's current
> one.
> 
> Henrik
> 
> (c) 2000 Henrik Gedenryd. All rights reserved.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  Ack! It's come to this already?

What are the IP issues here? How might I release code ( or ideas ) in a manner
in which my ideas ( code or whatever ) are protected in a reasonable manner,
while allowing the greatest possible use of those ideas?  I am only concerned
about my work being patented/copyrighted/whatever by someone other than myself,
and then having them turn on me by claiming my work as their own.  Would stamping
a copyright such as Henrik's be sufficient ( assuming I use my own name of course ) ?

This is not a hypothetical situation- there are several things I want to release!
For instance, Oasis could be ported to Squeak without too much effort, but for
now it lives in VisualWorks.

-les

 (c) 2000 Leslie Tyrrell. All rights reserved.