Am 02.10.2008 um 12:44 schrieb Matthew Fulmer:
On Thu, Oct 02, 2008 at 02:55:34PM -0400, Sean Allen wrote:
On Oct 2, 2008, at 1:18 PM, Bert Freudenberg wrote:
If you wanted to take a mutable object and make it immutable and be
able to go back again to mutable,
how could you do that?
What i
On Thu, Oct 02, 2008 at 02:55:34PM -0400, Sean Allen wrote:
>
> On Oct 2, 2008, at 1:18 PM, Bert Freudenberg wrote:
>
> >> If you wanted to take a mutable object and make it immutable and be
> >> able to go back again to mutable,
> >> how could you do that?
> >
> > What is your use case?
>
> u
> "Randal" == Randal L Schwartz <[EMAIL PROTECTED]> writes:
Randal> I believe #class is "NoLookup", meaning that I can't define a method
Randal> of my own to do something weird with that.
Feh. Ignore me. I have no idea what I'm talking about. :)
--
Randal L. Schwartz - Stonehenge Consulti
> "Bert" == Bert Freudenberg <[EMAIL PROTECTED]> writes:
Bert> How would that outsider get at the class of the object?
I believe #class is "NoLookup", meaning that I can't define a method of my own
to do something weird with that.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc.
On Oct 2, 2008, at 1:18 PM, Bert Freudenberg wrote:
If you wanted to take a mutable object and make it immutable and be
able to go back again to mutable,
how could you do that?
What is your use case?
use case.
system needs to track changes to itself.
one option that has come up is...
l
On Oct 2, 2008, at 1:18 PM, Bert Freudenberg wrote:
Well, it's hardly a beginner's topic, but you could make your class
use a modified compiler that protects instance variable assignment
by the check of an "immutable" flag.
This is basically how Avi's WriteBarrier works.
I'm going to hav
On Oct 2, 2008, at 2:31 PM, Marcin Tustin wrote:
On Thu, Oct 2, 2008 at 6:17 PM, Sean Allen <[EMAIL PROTECTED]
> wrote:
You'd have to specially code each accessor in that case to check the
flag.
Yes. This is unlikely to be a problem unless you have a lot of
members.
lots of members ac
Am 02.10.2008 um 11:25 schrieb Randal L. Schwartz:
"Bert" == Bert Freudenberg <[EMAIL PROTECTED]> writes:
Bert> There is no magic in #instVarAt:. It exists merely for helping
Bert> debugging.
I meant the primitive it invokes. Encapsulated magic is still magic.
So code would merely have to
On Thu, Oct 2, 2008 at 6:17 PM, Sean Allen <[EMAIL PROTECTED]>wrote:
> You'd have to specially code each accessor in that case to check the flag.
>
Yes. This is unlikely to be a problem unless you have a lot of members.
Alternatively you could adapt the code that generates your accessors to put
> "Bert" == Bert Freudenberg <[EMAIL PROTECTED]> writes:
Bert> There is no magic in #instVarAt:. It exists merely for helping
Bert> debugging.
I meant the primitive it invokes. Encapsulated magic is still magic.
>> So code would merely have to execute the equivalent of the primitives behin
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 wan
Am 02.10.2008 um 10:26 schrieb Randal L. Schwartz:
But the debugger doesn't have any special privileges, and it can
clearly
access every inst var, regardless of whether accessors exist or not,
through
the magic of #instVarAt: and friends.
There is no magic in #instVarAt:. It exists merel
> "Marcin" == Marcin Tustin <[EMAIL PROTECTED]> writes:
Marcin> Surely if you have a wrapper class which only holds a reference to a
Marcin> single object that has all of the data, and that has accessors, then
Marcin> the wrapper can only use the accessors? The data object could have a
Marcin>
Am 02.10.2008 um 10:17 schrieb Sean Allen:
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, al
Am 02.10.2008 um 08:50 schrieb Sean Allen:
If you wanted to take a mutable object and make it immutable and be
able to go back again to mutable,
how could you do that?
What is your use case?
In particular the part that has me as a smalltalk beginner stumped
is how to disallow any message
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
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
> "Sean" == Sean Allen <[EMAIL PROTECTED]> 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 recogni
If you wanted to take a mutable object and make it immutable and be
able to go back again to mutable,
how could you do that?
In particular the part that has me as a smalltalk beginner stumped is
how to disallow any messages
that would result in a state change while still allowing messages tha
19 matches
Mail list logo
