A package wich needs to add a value to MessageMap

Hi all,

 I had to port a package to Dolphin 6 wich in it's installation adds a
value to MessageMap. In dolphin 5 it has no problem but in D6
MessageMap isImmutable so it throws an exception.

 Any suggestions?

  By the way... how the immutable objects work in D6? it already
support immutability for any object? Can I make an arbitrary instance
to be immutable? or can I then change it to be mutable again?

  regards,

Sebastián

Sebastián,

>   By the way... how the immutable objects work in D6? it already
> support immutability for any object? Can I make an arbitrary instance
> to be immutable? or can I then change it to be mutable again?

Yes, you can change it.  See Object>>isImmutable: and Object>>whileMutableDo:

The comment in #isMutable: is incorrect, mutability applies to all of an
object's slots, not just indexed slots.  (I.e. it applies to instvars too).

    -- chris

Excellent ! I think we can take advantage from that feature making it
rise a specific exception so one can capture it for certain prupouses
(like object write detection).

Anybody has done some kind of write barrier in dolphin yet?

regards,

Sebastián

Sebastián,

> Anybody has done some kind of write barrier in dolphin yet?

I'm not sure, but I don't /think/ the current implementation provides enough
information to be able to do that in a general way.  There doesn't seem to be a
way of trapping the exception and then retrying the operation after, say,
marking the object dirty.  There also doesn't seem to be any infomation
provided in the exception about which slot was (not) written to, or what value
was (not) written.

For instance, I can't see how to use it to implement something like Micheal
Lucas-Smith's "Omnibase Tracker":
http://www.cincomsmalltalk.com/userblogs/mls/blogView?entry=3310603000

I.e it seems to provide write /protection/ (which is good), but not to be a
mechanism from which a genaeral write /barrier/ can be constructed.  But maybe
I'm missing something...

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:44197b0c$0$1167$[hidden email]...
Not in the exception, but you can override #errorInstVarAt:put: and
#errorAt:put:, (or just replace the standard implementations in Object as a
workaround). We could look at making the standard exception that is raised
more useful in future (i.e. adding a specific resumable exception class for
this with slots to hold all the necessary info). To be honest, though, the
use of an exception for this purpose will have a high overhead and you'd be
better off (from a performance perspective) hacking it into the error
handling methods if possible.

Immutability was added very late in the development cycle, primarily to
support protection against modification of literals in compiled methods
(motivated by a nasty bug in the new literal resources that we would have
spotted immediately had we had immutable literals). Not much consideration
was given to providing a mechanism for a general write barrier, except to
ensure that the VM provides the information needed. For primitives such as
those behind #at:put: and #instVarAt:put:, etc, the mechanism is simply to
fail the primitive, and then detect the condition in the generic error
handling methods that are invoked by the primitive backup code. For
attempted modification of instance variables, the VM specifically sends a
#errorInstVarAt:put: message telling you which slot was being written and
the value.

I think the basic mechanism is there, but you may have to modify two system
methods to achieve it for all objects. I can't be sure it will work, though,
as it hasn't been tested with that purpose in mind. Any feedback would, as
always, be welcome.

Regards

Blair

Crhis, Blair,

   soon I'll be porting some code I have for solving the need of
control the change in objects in D5.1. So I certainly will be trying to
change the actual implementation to one that take advantage of
immutability.

  Best regards,

Sebastián Sastre