On Monday, September 2, 2002, at 10:25  Uhr, Jecel Assumpcao Jr wrote:

> On Saturday 31 August 2002 06:38, Marcel Weiher wrote:
>> 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).
>
> Ok, this *is* different from what I was thinking.

What were you thinking?

> The terms you are
> using remind me of "parameter based CAD" systems.

Yes, the association is an obvious one, especially since I am also 
doing graphics-related work.

>  Those (starting with
> the original Sketchpad) have paremeters and constraints between
> parameters, however.

Yes, constraints will probably be one of the mechanisms I implement, 
because they also have nice declarative properties and can be 
incrementally derived from static objects.  (A value being the "most 
restricted" constraint, which can be "loosened" into a formula).

>
>> 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".
>
> By "adding a slot to it" do you mean modifying the original object or
> creating a new ID that points to the old object and also to the slot?

More of the latter than the former, though in practice it gets a bit 
muddled.  I have "template" objects that refer to the original object 
and manage the slots.  New slots can be added to a template, so the 
original object isn't modified, but the template is.  As I said, this 
is a bit muddled.

>> 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.
>
> It should be a simple problem to flatten these chains,

Yes, flatten and prune.  Once perfectly pruned, you sort of get classes 
(I think), because the prototypical nature of the originals has been 
pruned away.

>  though as I
> indicated in my question above the exact nature of these chains isn't
> clear to me.

It can probably be thought of as being similar to a reified 
"cloning-history" of an object, except that the individual steps can 
also make an object abstract or concrete again.

Marcel