[Newbies] 'locking' an object

Mariano Abel Coca marianoabelcoca at gmail.com
Thu Oct 2 18:13:37 UTC 2008


Ok, there are two options...

First, if the object needs to be inmutable, just doit without setters. Let
it be updated at once, with only one message which updates the instance
variables from an already valid object. This way you can ensure that the
original object will only be updated when you want to. It's an 'Application
level' inmutability.

The second option is the proxy one, with a collection of 'dangerous'
messages that will throw an exception when sended. This can be easily done
by defining only the doesNotUnderstand: method in the proxy to search for
the message in the collection and if it's found, raise the exception, if
not, resend it to the proxyed object.

-- 
Mariano.
www.egola.com.ar

On Thu, Oct 2, 2008 at 2:17 PM, Sean Allen <sean at monkeysnatchbanana.com>wrote:

> You'd have to specially code each accessor in that case to check the flag.
> Ideally I'd like to be able to step in front of every message send to
> descendent objects and
> decide whether to pass along ( read call ) or reject ( write call ).
>
> then, all the logic is in one place and the accessors don't need to know
> about what is going on.
>
> any way to do that?
>
> i'm ok with the primitive problem as i don't need real immutability. just
> 'application level' immutability...
> ideally, without special coding in every accessor method ( that would get
> tedious very quickly ).
>
>
> On Oct 2, 2008, at 12:47 PM, Marcin Tustin wrote:
>
> Surely if you have a wrapper class which only holds a reference to a single
> object that has all of the data, and that has accessors, then the wrapper
> can only use the accessors? The data object could have a flag that causes
> all of the accessors to throw an exception when it is set.
>
> Or am I missing something?
>
> On 10/2/08, Randal L. Schwartz <merlyn at stonehenge.com> wrote:
>>
>> >>>>> "Sean" == Sean Allen <sean at monkeysnatchbanana.com> writes:
>>
>> Sean> If you wanted to take a mutable object and make it immutable and be
>> able
>> Sean> to go back again to mutable, how could you do that?
>>
>> Squeak doesn't have that sort of capability.  The immutability of a few
>> classes is because the VM recognizes them specially, and not available
>> at the programmer level without modifying the VM.
>>
>> Other Smalltalk VMs are different.  I think both VisualWorks and
>> GemStone/S
>> have primitive bits on an object to be informed when a mutation might be
>> attempted.
>>
>> You can simulate that *mostly* in Squeak by using a "proxy" object that
>> intercepts all messages and looks for the dangerous ones, but that's gonna
>> be
>> a bit hard to do, and won't be aware of any new code that might call the
>> mutating primitives directly.  (*Any* method can call a primitive.)
>>
>> --
>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
>> 0095
>> <merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
>> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
>> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside
>> discussion
>> _______________________________________________
>> Beginners mailing list
>> Beginners at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>>
>
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/beginners/attachments/20081002/6b7540c8/attachment.htm


More information about the Beginners mailing list