subjective programming

[Jecel Assumpcao Jr]

I had been thinking about subjective programming lately, and happened
to find an online version of the Us paper:

    A Simple and Unifying Approach to Subjective Objects (1996)
    Randall B. Smith, David Ungar
    http://citeseer.nj.nec.com/smith96simple.html

Us is an extension of Self for subjective programming, and the only
thing I had been able to find about it previously was this short
position paper:

    The Subjective Prototype
    Randy Smith
    http://www-staff.mcs.uts.edu.au/~cotar/proto/randy.txt

I first started considering objects with different viewpoints in terms
of the user interface. On the previous version of this mailing list (in
October 1990), I proposed that we could view objects through a set of
"lenses". This Xerox project actually implemented this:

    http://www.parc.xerox.com/istl/projects/MagicLenses/

What an object looks like depends on what lens you view it through.

Since another teacher at PUC-SP called my attention to the problem of
"roles" in object oriented programming, I tried to include these
features when I designed a Logo compatible, Self derived language in
1994. NeoLogo only allowed an object to extend one other object; a kind
of "single inheritance". But this was very dynamic, so I came up with
the idea of allowing multiple children to model the different roles for
an object. There was a very complicated operation called AS. So the
expression X AS Y would:

  - return Y if Y was a child of X
  - return Y if X was a child of Y (true! this rule was to allow AS to
work as a kind of resend)
  - return Z if Z was a clone of Y and Y was a child of X
  - return Z if Z was a clone of Y, W was a clone of X and Z was a
child of W
  - signal an error, otherwise

There was also an ASNEW that was just like this, but instead of
returning an error in the last case it created a new clone of Y that
would satisfy one of the previous two rules.

This seemed to solve the magic lenses and roles problems, so I was
surprised at Ecoop95 by a paper claiming that delegation (what I was
using could be considered that) wasn't the right tool for this job:

    Sharing Properties in a Uniform Object Space
    Heiko Kießling and Uwe Krüger
http://link.springer.de/link/service/series/0558/bibs/0952/09520424.htm

Their system seems similar to the Beta language in many ways, but they
allow a single object to have several views. An advantage over my idea
was that objects didn't change identity when you changed views.

The Us language has this advantage as well. And the view is defined as
a part of the sending context which is by default inherited by the
receiving context. This means that many objects change when you change
views (AS in NeoLogo encoded the view in the object identity and so
only the receiver was affected - all other objects looked the same as
before. NeoLogo also had the nasty "rubber band" semantics described
in the Us paper).

While the paper introduces a new syntax for changing views, we could
use the existing Self parser and bytecodes by doing something like

       [ some expressions ]  ><  newView

The examples of how it could replace meta-objects for reflection and
how they could be used for versions and multi-user objects were
particularly interesting for me. With some additional semantics (if you
could have copy-on-write views) you could even use them for
transactions: if you throw away a transactionLayer and let the garbage
collection have it, it is an abort; but if you explicitly merge it with
another view then that is a commit.

Of course, multiple graphical views are interesting too and the reason
I was thinking about all this. I wanted to do a graphical version of my
CMOS simulator but needed a schematic view, a layout view, a component
view, a simulated schematics view, a simulated layout view and so on.
My design was to create a copyAs: method which would copy "split
objects" as indicated by view objects (special dictionaries).

I have no idea of how to implement this efficiently, but was wondering
if the people in this list (specially Randy and Dave) think it is a
worthwhile idea.

-- Jecel