On Saturday, August 31, 2002, at 12:36  Uhr, Jecel Assumpcao Jr wrote:

>> I am saying that I want something like (1) to be usable with objects
>> as well as methods.
>
> Yes, that is what am interested in knowing more about. If I have a 
> class
> with "a" and "b" parameters, and "c" and "d" regular instance
> variables, what should the values of "c" and "d" be for a new instance?

Before I start answering, just a short note to the status of this work: 
  it is currently part of a system built on top of an existing language 
(Objective-C, though ST would make parts easier), not a new language.  
I am groping forward very slowly, because the aim is to build something 
that is useful in the context of the system...

At present, parameters aren't aren't associated with classes as such.  
Instead parameterized objects (templates) are created from existing 
objects by adding slots.  A slot has a name and a key-value path to the 
object it replaces.  They key-value path means that the replacement can 
affect sub-structure.

I can currently get away with not copying the object because in the 
current system, all I actually do with the object that is relevant is 
output it to a graphics-stream, so the context-evaluation takes place 
on output only.  I probably will have to change that in the near 
future, though.

To avoid copying in that case, I would either need (a) proxy-objects 
that get placed in the slots or (b) a more general languge mechanism 
that adds a lookup-layer, but that probably isn't going to happen in 
Objective-C.

> The Smalltalk way would be for them to be initialized to nil, I
> suppose. Since the new object creation looks like a message send, can I
> think of it as a contructor (in the C++ sense) with code that can set
> "c" and "d" in the new instance?

I wouldn't do that, even though it may look a bit like it at first.

The thing to understand is that this isn't "new object creation".  It 
is "definition".  Object A *is* Parametrized Object B with parameters 
c=C and d=D.  Think of it as the difference between putting a literal 
object someplace vs. code that constructs the object.

For example, constructores always create an object.  This is not 
necessarily the case here.  If Parametrized Object B has parameters c 
and d, and I only give it a value for parmeter c, then I don't get a 
fully funcioning instance, I get a new parametrized object with 
parameter d.  (That's the 'currying' aspect I was refering to).

Furthermore, it is always possible to turn any object into a 
parametrized object by adding a slot to it (the slot turns an attribute 
or sub-structure into a parameter), so there is a back and forth 
between levels of abstraction (or meta-levels).  I also call this 
little engine the "AbstractionEngine".

The back-and-forth aspect also means that you can create long reference 
chains, with a parameter being introduced and bound over and over 
again.  There probably needs to be a mechanism to simplify such chains, 
but that problem is a long way off for now.

>> Well, I have a bit of a problem with a "unifying mechanism" that is
>> used neither (a) by the user nor (b) by the implementation.  If there
>> is no actual leverage, maybe the mechanism isn't actually useful?
>
> It is used by the user when dealing with the debugger.

So the debugger synthesizes a view of the system that doesn't exist 
otherwise?

>> I was just following up on Alan's comments about "Exemplars".  Not
>> sure what he has in mind there, but it does sound similar in some
>> respects.
>
> I would guess he was talking about this paper:
>
> W.R. LaLonde, D. Thomas, and J.R. Pugh.
> "An Exemplar Based Smalltalk".
> In Proceedings of the 1st Conference on Object-Oriented Programming
> Systems, Languages and Applications (OOPSLA '86), Portland, Oregon, ACM
> Sigplan Notices (21)11 , pp. 322--330, 1986.

Thanks for the reference!

> I haven't read this paper since 1987, so while I can't remember any
> significant difference between this and Mario's Smalltalk-in-Self that
> doesn't mean that there weren't any.

I'll check it out.

Regards,

Marcel


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