On Tuesday, August 27, 2002, at 08:53  Uhr, Jecel Assumpcao Jr wrote:

> On Tuesday 27 August 2002 05:45, Marcel Weiher wrote:
>> Sorry, but I also find "invoke with arguments" easier to *think*
>> about than "make a copy, modify the copy, do something with the
>> copy", essentially because it is declarative.  In fact, I currently
>> see/use it the other way around:  making a copy and munging that is a
>> (hidden) implementation of a parametrized object.
>
> We will have to agree to disagree, then :-)

Sure.

> I see making a copy as changing the semantics.

Not if it can be hidden, just like you hide *not* making the copy.  I 
wonde why you see one as changing semantics, and its inverse as not 
changing the semantics.

>  Without a copy, two
> different invocations of a method would share temporary variables and
> arguments.

Oh, please!  Every C function, Pascal procedure/function, Smalltalk 
method, etc. manages to do this without making a copy of the method, 
simply by externalizing the mutable state.

>  With a copy, each one has a separate state.

You don't need a copy for that, just a proper lookup algorithm.

> Of course, the declarative "invoke with arguments" will almost 
> certainly
> have implicitly in its semantics some form of copying.

No, it is creating a new method context, and leaving the method alone.  
Nothing is being copied.

>  I am just  stating explicitly that this is what is happening.

Well, then you are explicitly wrong about this ;-)

>
>> This is pretty much where I think self went off in the wrong
>> direction, unifying too many different (if related) ideas with
>> low-level/imperative/time-dependent mechanisms and then having to
>> untangle the mess again, with great difficulty.
>
> Who has to untangle the mess? The user or the implementor?

Both.

> If only the  latter, then I don't see the problem.

Since it's both, I do see a problem.  Maybe I can make you see it as 
well, but I probably can't explain it well enough...

>
>> Yes, you can get away with tossing things like classes (and method
>> invocation), but while an interesting intellectual exercise, you
>> aren't actually helping your users, IMHO.
>
> It is great fun to grab some object on the screen and then patch it
> until it is a new thing. Fun is important and helps users.

Yes.  I am fully behind the importance of interactive object 
construction, but I am convinced it doesn't go far enough.  In fact, I 
want to make it even better than it is.

>>> That is the story we tell (but don't actually implement ;-) in
>>> Self: contexts (called activation objects) are created by cloning
>>> methods and then changing them.
>>
>> Once again, that seems like backwards to me:  turning a simple
>> invocation into something conceptually more complex (time-dependent
>> etc.), then optimizing that away again.
>>
>> Why not present the simple model to the user?
>
> Because I think this is the simple model.

Simple from an implementation point of view (all handled via one 
mechanism).  But I disagree that this is simple for the user.  Before I 
give my reasoning, let me first reiterate that I agree that 
constructing objects (once) is simple for users, the question is where 
to go from there.  Let me also try to clarify what I mean by "simple":  
reducing the cognitive load for a given construct as much as possible.

With copying and modifications, you have to remember and be aware of 
the history of an object to know what it is like now.  This makes the 
whole thing more complex.  Once again, I believe there is a reason we 
*write* method invocation (procedure calls) as:

(1)	result := someObject  method: arg1 more:arg2.

and not:

(2)	method := MethodProtype copy.
	method setArg1: arg1.
	method setArg2: arg2.
	method invoke.

This seems 'obviously' more complex to me.

However, we do use object instance this way (2).  As far as I can see, 
self says that (2) is really the unifying mechanism, but provides both 
syntax and implementation-optimizations to use (1) where 
possible/necessary.

My current approach is to say that (1) is the unifying mechanismmm and 
potentially use (2) internally where necessary (though I'd rather it 
were not necessary).  Objects, which can be constructed with all the 
fun of self-style, can be turned into parametrized objects (which have 
some class-like characteristics) by turning some of their instance 
variables into parameters.  They are then incomplete, and know that 
they're incomplete.  The user also knows that and exactly how they are 
incomplete.  To be used, a parametrized object must be provided with a 
context that provides the bindings for the parameters.


>  Compare this with the model
> presented in the Blue Book (which can also be seen in the Interpreter
> class in Squeak).

Ahh, but this really is an implementation...

>  You will probably tell me that the "normal"
> Smalltalker doesn't have to learn about stack pointers, method headers,
> context objects, etc. Then I will say that the normal Selfish
> programmer doesn't have to know that activation objects are obtained
> from cloning method objects!

...whereas you've said that cloning is the "model" you present, and 
that the implementation doesn't actually do this.

Anyway, this is all too low-level for me anyhow, and method invocation 
is not really what I am talking about.  It is making dealing with 
objects more like method-invocation (or function evaluation, procedure 
call) rather than vice versa, making method invocations more like 
munging objects.

> There are several level of models. Let us make sure we are comparing
> comparable ones.

Definitely.  I am talking about user-level models.

Marcel

-- 
Marcel Weiher				Metaobject Software Technologies
marcel at metaobject.com		www.metaobject.com
Metaprogramming for the Graphic Arts.   HOM, IDEAs, MetaAd etc.