dynamic state?

Hi Igor, I was interested by your suggestion in this message:

  http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/022526.html

I thought it sounded neat because it would seem to bring "dynamic
state" to objects.  Objects wouldn't have to rely on instVars defined
in classes to extend state, all while providing logical solutions to
some of the issues like immutability and 12-bit identity-hashes..  Is
it a good idea?

On 3/23/2010 9:49 AM, Chris Muller wrote:
> Hi Igor, I was interested by your suggestion in this message:
>
>    http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/022526.html
>
> I thought it sounded neat because it would seem to bring "dynamic
> state" to objects.  Objects wouldn't have to rely on instVars defined
> in classes to extend state, all while providing logical solutions to
> some of the issues like immutability and 12-bit identity-hashes..  Is
> it a good idea?

It's an interesting thought, but I'll make a few observations: First,
the usage with traits seems odd. For traits you have an explicit
composition step already, the step can compute required state and add
that to the class in question. So the original motivation is a bit off.

Secondly, I think that because traits don't need 'em, the slots should
be like any other indexed slots, and should have a global meaning (such
as slot 1 is identity hash). Of course, then you can just go one
additional step and say that one such slot is the class slot. That gives
us two known slots that we'd like to have in any object (class and
hash), I'd add a third one: a generic dictionary of properties so that
you don't need to add external registries to hold onto associations
between instances and properties and the associated GC issues (ephemerons).

And of course, if you don't have high performance requirements, you
could use just a single bit to indicate that the object has additional
properties and use the properties dictionary to store all additional state.

In short, I kind of like the idea for designing a fairly compact but
extensible object format. It would mean some major restructuring of the
object format but it's worth thinking through it to find out what other
issues this could help with even if implemented differently.

Cheers,
   - Andreas

On 23 March 2010 19:16, Andreas Raab <[hidden email]> wrote: About traits, it was just an example, how new object format could be
used in combination with them.
If you going to add state to traits explicitly, then you will need to
change the trait definition format (to include used ivars etc),
as well as design schemes to handle name conflicts. =>> more complexity.

But named slots don't require from traits to change anything in that
way. Traits will still stay to be a simple
set of methods without any additional formal specs/rules.

> Secondly, I think that because traits don't need 'em, the slots should be
> like any other indexed slots, and should have a global meaning (such as slot
> 1 is identity hash). Of course, then you can just go one additional step and
> say that one such slot is the class slot. That gives us two known slots that
> we'd like to have in any object (class and hash), I'd add a third one: a
> generic dictionary of properties so that you don't need to add external
> registries to hold onto associations between instances and properties and
> the associated GC issues (ephemerons).
>
Yes. In general , this is a way to attach additional state to any
object (or to subset) in system.
Btw, identity hash is one of the cases, where you want to support this
property globally,
but don't need to make it mandatory, because for objects which not
used in hash-based collections,
this property is redundant.
So, initially , a generic object could be created without identity
hash slot, which is then added
dynamically, once identity hash requested.
But some objects could pre-allocate slots upon creation. For instance
- Symbols could be initially created with identity hash slot,
with value set to the hash of its string value.

> And of course, if you don't have high performance requirements, you could
> use just a single bit to indicate that the object has additional properties
> and use the properties dictionary to store all additional state.
>
if by 'properties dictionary' you mean storing it in an extra object -
then it is different to what i proposed.
In format , which i proposing, a dictionary of key/value pairs is held
within an object (it is not accessible as a separate object from
outside).
This is similar to Self or JavaScript object formats, where object is
a set of named slots.

> In short, I kind of like the idea for designing a fairly compact but
> extensible object format. It would mean some major restructuring of the
> object format but it's worth thinking through it to find out what other
> issues this could help with even if implemented differently.
>
> Cheers,
>  - Andreas


--
Best regards,
Igor Stasenko AKA sig.

Ah, I should have mentioned that I was interested in Igor's idea from
completely _outside_ the context of Traits and his original message
purpose.  I know nothing about Traits have no interest in learning
them.  I was only wondering whether his idea was useful as a
general-purpose change for Squeak..


On Tue, Mar 23, 2010 at 12:16 PM, Andreas Raab <[hidden email]> wrote:

On 23 March 2010 22:43, Chris Muller <[hidden email]> wrote:
> Ah, I should have mentioned that I was interested in Igor's idea from
> completely _outside_ the context of Traits and his original message
> purpose.  I know nothing about Traits have no interest in learning
> them.  I was only wondering whether his idea was useful as a
> general-purpose change for Squeak..
>

Yes. In particular, i'm also mentioned Magma, which could benefit from
this format
- you could add a named 'magmaOId' slot to any object of interest, by
simply implementing:
Object>>magmaOId
  ^ self slotAt: #magmaOId ifAbsentPut: (MagmaOidGenerator newId)

(and #slotAt:ifAbsentPut: is a primitive, supported by VM).

So, you don't have to maintain a separate dictionary of 'object->id',
having a multiple thousands of elements,
and because of small identityHash (12 bits) values size, is one of the
bottlenecks, making it slow.



--
Best regards,
Igor Stasenko AKA sig.

On 3/23/2010 10:56 AM, Igor Stasenko wrote:
> On 23 March 2010 19:16, Andreas Raab<[hidden email]>  wrote:
>> It's an interesting thought, but I'll make a few observations: First, the
>> usage with traits seems odd. For traits you have an explicit composition
>> step already, the step can compute required state and add that to the class
>> in question. So the original motivation is a bit off.
>>
> About traits, it was just an example, how new object format could be
> used in combination with them.

Right, except that it makes little sense since traits are static
compositions as far as the objects are concerned. Consequently anything
you could dynamically could be done statically during the composition
step. But anyways, this isn't about traits.

>> And of course, if you don't have high performance requirements, you could
>> use just a single bit to indicate that the object has additional properties
>> and use the properties dictionary to store all additional state.
>>
> if by 'properties dictionary' you mean storing it in an extra object -
> then it is different to what i proposed.

Yes, and yes. My point is that in a *lot* of situations you can achieve
the desired effect with a single extra bit in the object header if
you're willing to pay the price in performance. Given that most uses
aren't going to be performance critical, that seems like a more
reasonable step for incremental improvement than rewriting the entire
object model :-)

> This is similar to Self or JavaScript object formats, where object is
> a set of named slots.

Or to Python which has both named variables and __slots__
(http://docs.python.org/reference/datamodel.html).

Cheers,
   - Andreas