[Vm-dev] [Pharo-project] Plan/discussion/communication around new
colin at wiresong.com
Thu Jun 14 19:43:36 UTC 2012
On Thu, Jun 14, 2012 at 12:14 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> And so, an only logical step, as to me was to do it for real:
> I proposed to add a slot for arbitrary properties per object, is
> simply a unification of the above,
> so you can state:
> - all objects *also* have at least one property slot, which can be
> used by language to store arbitrary properties per object (or at least
> one), *without* a need from object in question to have a direct
> about the nature of these properties (in contrast to instance
> variables, immutability, hash etc).
Sure. Sounds good. I'd like to see that as well.
> For me the main cost is, of course, performance. If we take our
> existing images (which have no notion
> about immutability) they will perform slower on same hardware.
Not true, actually. We're talking about adding an immutability bit to
the new object format. Existing images won't run at all on a VM that
uses the new format. Once those images are converted to the new format
they'll run faster, with or without the immutability bit. That's not
to say there's no performance impact, but come on, nobody is going to
see performance worsen.
> We can turn this cons into pros, only when we will start using
> immutability around the places..
> and here is where fun stuff begins: you cannot manage immutability
> state over more than ONE framework.
> So you will have to invent more complex schemes like mentioned
> "immutability managers" etc..
That's theoretically a problem, yes. I've never seen it actually come
up, though, and I have a hard time imagining a situation where you'd
want to manage the state of a single object with more than one
framework at a time.
More information about the Vm-dev