Real (trivial) mixins

[Jeremy Tregunna-2]

On 17-Apr-09, at 3:13 AM, spir wrote:

> Le Thu, 16 Apr 2009 15:47:46 -0700,
> Steve Dekorte <steve@...> s'exprima ainsi:
>
>> 2. the model doesn't unify namespaces and objects
>
> This I don't understand.

I think what Steve is trying to say is that, when you create a new  
namespace, it should be empty -- that is, have no slots in it that  
could pollute your use of them. If your objects when you create them  
have stuff inside them from their parent (that is, copying 1-level  
deep slots to itself) you have polluted your namespace, yielding it  
potentially useless for namespacing purposes.

> Denis


Regards,

Jeremy Tregunna
jeremy.tregunna@...

[Steve Dekorte]

On 2009-04-17, at 12:13 AM, spir wrote:
>> 2. the model doesn't unify namespaces and objects
> This I don't understand.

For example in Io, namespaces aren't special - they are just an  
extension of the object's parent chain. In a system where one copies  
all slots in the lookup chain into a new instance, you would either  
have to copy the entire namespace (probably not a good idea) or have  
some line of demarcation.

[spir]

Le Fri, 17 Apr 2009 13:47:45 -0700,
Steve Dekorte <steve@...> s'exprima ainsi:

>
> On 2009-04-17, at 12:13 AM, spir wrote:
> >> 2. the model doesn't unify namespaces and objects
> > This I don't understand.
>
> For example in Io, namespaces aren't special - they are just an  
> extension of the object's parent chain. In a system where one copies  
> all slots in the lookup chain into a new instance, you would either  
> have to copy the entire namespace (probably not a good idea) or have  
> some line of demarcation.
>

This let me think hard!

-0- It's nice to have a new object as a clean, empty namespace.

-1- A sensible "line of demarcation" could be between builtin/language-provided slots and custom slots set by user code (or inherited from custom proto itself user-defined)? does this make sense? (See also below point 5)

-2- But from the programmer pov the fact that slots / slot-names / slot-dict are carried by the object or its proto(s) is or should be transparent (except for performance, or if ever the proto(s) change(s)). Or do I overlook an obvious point? A slot lookup chain is a background, implementation, choice. Or, for a reflexive language, it becomes a meta-feature.

-3- This is particuliarly true for "meta-informative" slots such as type or slotNames, precisely ;-)

-4- How to make the difference between such meta things (often provided by the language) and the object's "real" data/methods (usually provided by the user code), such as for instance a Color proto's R,G,B and toCMY slots?

-5- This gets worse complicated for me when considering that an object is often, at the language level, a dict/mapping with a unique id. But can also be, a the application level, a kind of dict (or even, when the language supports it, an object of type Dict) simply used to store named data. How then does Io differenciate both level? Meaning for instance avoid to iterate over slots that belong to the object-side of the dict, not to its storing-utility-side?

Io> Point := point clone
==>  Point_0x9dcc440:
  type             = "Point"
Io> point := point clone
==>  Object_0x9dd2f48:
Io> point x := 1 ; point y := 2
==> 2
Io> point type
==> Point
Io> point slotValues foreach(v, (v .. " ") print)
1 2 ==> 2

Why/how not 'Point' here? How is the slot called 'type' excluded from iteration through point's slots? Is it simply because it is not really carried by point? Then having inherited slot names/references carried by the object really introduces a big mess!

Denis
------
la vita e estrany

[spir]

Le Mon, 20 Apr 2009 11:33:17 +0200,
spir <denis.spir@...> s'exprima ainsi:

> Io> Point := point clone
> ==>  Point_0x9dcc440:  
>   type             = "Point"
> Io> point := point clone
> ==>  Object_0x9dd2f48:

Sorry, copy/paste error here. Read:

> Io> Point := object clone
> ==>  Point_0x9dcc440:  
>   type             = "Point"
> Io> point := Point clone
> ==>  Object_0x9dd2f48:

Denis
------
la vita e estrany

[Jeremy Tregunna-2]

On 20-Apr-09, at 5:33 AM, spir wrote:

> Le Fri, 17 Apr 2009 13:47:45 -0700,
> Steve Dekorte <steve@...> s'exprima ainsi:
>
>>
>> On 2009-04-17, at 12:13 AM, spir wrote:
>>>> 2. the model doesn't unify namespaces and objects
>>> This I don't understand.
>>
>> For example in Io, namespaces aren't special - they are just an
>> extension of the object's parent chain. In a system where one copies
>> all slots in the lookup chain into a new instance, you would either
>> have to copy the entire namespace (probably not a good idea) or have
>> some line of demarcation.
>>
>
> -5- This gets worse complicated for me when considering that an  
> object is often, at the language level, a dict/mapping with a unique  
> id. But can also be, a the application level, a kind of dict (or  
> even, when the language supports it, an object of type Dict) simply  
> used to store named data. How then does Io differenciate both level?  
> Meaning for instance avoid to iterate over slots that belong to the  
> object-side of the dict, not to its storing-utility-side?
>
> Io> Point := point clone
> ==>  Point_0x9dcc440:
>  type             = "Point"
> Io> point := point clone
> ==>  Object_0x9dd2f48:
> Io> point x := 1 ; point y := 2
> ==> 2
> Io> point type
> ==> Point
> Io> point slotValues foreach(v, (v .. " ") print)
> 1 2 ==> 2
>
> Why/how not 'Point' here? How is the slot called 'type' excluded  
> from iteration through point's slots? Is it simply because it is not  
> really carried by point? Then having inherited slot names/references  
> carried by the object really introduces a big mess!

Actually, the type slot is created on any slot assignment whose slot  
name begins with an upper case character only. That is, Point := ...  
will create a Point slot, with a type slot named "Point". however,  
point := ... since it does not begin with an upper case character,  
will not contain a type slot. So if you do: point type println; you'll  
note it prints Object, but if you do a Point type println; it prints  
Point. Even in your example both Point and point are Points, what you  
want is a is-a test. point is-a Point, even though point's type is  
Object (a generic type that is given to all objects created within  
Io). And I say "generic" very loosely as all objects in Io are of one  
type: Object. You can just override the string value if you so desire.  
However, testing to the type slot is generally frowned upon, it's  
mostly there for pretty printing.

My suggestion, if you need to compare objects in such a way as you'd  
normally compare types, use the: isKindOf(SomeProto) message, it's  
generally more accepted.

Regards,

Jeremy Tregunna
jeremy.tregunna@...