immutability and become (Was: Re: [squeak-dev] immutability)
Locked
immutability and become (Was: Re: [squeak-dev] immutability)
 
|
Yes, i am against adding immutability bit in VM.
But if we going that way, then please explain me how VM will respect immutability and #become: or #becomeForward: at the same time. The problem is following: suppose your object (a) is referencing object (b). now you doing: a beImmutable. and then b becomeForward: c. which leads to replacement of reference to (b) by reference to (c) in an object (a), which is immutable. You could say, lets ignore this. Then, apparently , expect to see a hacky code, which as a workaround of immutability, using #become.. -- Best regards, Igor Stasenko AKA sig. |
Re: immutability and become (Was: Re: [squeak-dev] immutability)
|
|
As well, as i could simply do:
object isMutable ifFalse: [ object becomeForward: object clone ]. And so, #become becomes a universal tool to defeat an immutability. On 18 March 2010 06:00, Igor Stasenko <[hidden email]> wrote: > Yes, i am against adding immutability bit in VM. > > But if we going that way, then please explain me how VM will respect > immutability and #become: or #becomeForward: > at the same time. > > The problem is following: > suppose your object (a) is referencing object (b). > > now you doing: > a beImmutable. > > and then > > b becomeForward: c. > > which leads to replacement of reference to (b) by reference to (c) > in an object (a), which is immutable. > > You could say, lets ignore this. > Then, apparently , expect to see a hacky code, which as a workaround > of immutability, using #become.. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. |
Re: immutability and become (Was: Re: [squeak-dev] immutability)
|
|
I would have assumed that an immutable object cannot become anything else. Neither any other object, nor another immutable object. If you can change the state of an object in any way, either by changing it's state directly or by ex-changing it with another object, I would not consider it 'immutable'.
SmallInteger seems to be an immutable object, although probably more a constraint than a design decision. Have fun, Markus ----- Original Message ---- > As well, as i could simply do: object isMutable ifFalse: [ object > becomeForward: object clone ]. And so, #become becomes a universal tool > to defeat an immutability. On 18 March 2010 06:00, Igor Stasenko < > ymailto="mailto:[hidden email]" > href="mailto:[hidden email]">[hidden email]> wrote: > Yes, > i am against adding immutability bit in VM. > > But if we going that > way, then please explain me how VM will respect > immutability and > #become: or #becomeForward: > at the same time. > > The > problem is following: > suppose your object (a) is referencing object > (b). > > now you doing: > a beImmutable. > > and > then > > b becomeForward: c. > > which leads to > replacement of reference to (b) by reference to (c) > in an object (a), > which is immutable. > > You could say, lets ignore this. > > Then, apparently , expect to see a hacky code, which as a workaround > of > immutability, using #become.. > > -- > Best regards, > > Igor Stasenko AKA sig. > -- Best regards, Igor > Stasenko AKA sig. __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. |
Re: immutability and become (Was: Re: [squeak-dev] immutability)
|
|
On 18 March 2010 06:51, Markus Lampert <[hidden email]> wrote:
> I would have assumed that an immutable object cannot become anything else. Neither any other object, nor another immutable object. If you can change the state of an object in any way, either by changing it's state directly or by ex-changing it with another object, I would not consider it 'immutable'. > Good. This makes it more consistent , except that ex-changing with another object notion. So, you saying that i can do: array := Array with: foo beImmutable. array at: 1 put: nil. but can't do: array := Array with: foo beImmutable. foo becomeForward: nil. Why? > SmallInteger seems to be an immutable object, although probably more a constraint than a design decision. > I would consider SmallIntegers to be a naturally immutable objects. Same as nil, true, false. But there's another kind of objects which is naturally mutable: ... thisContext beImmutable. ... once you do this, you can't advance the computation, because you can't change a context state. Stepping to a next instruction altering the state of context, while immutability bit says that you can't do that. > Have fun, > Markus > > > > ----- Original Message ---- >> As well, as i could simply do: > > object isMutable ifFalse: [ object >> becomeForward: object clone ]. > > And so, #become becomes a universal tool >> to defeat an immutability. > > On 18 March 2010 06:00, Igor Stasenko < >> ymailto="mailto:[hidden email]" >> href="mailto:[hidden email]">[hidden email]> wrote: >> Yes, >> i am against adding immutability bit in VM. >> >> But if we going that >> way, then please explain me how VM will respect >> immutability and >> #become: or #becomeForward: >> at the same time. >> >> The >> problem is following: >> suppose your object (a) is referencing object >> (b). >> >> now you doing: >> a beImmutable. >> >> and >> then >> >> b becomeForward: c. >> >> which leads to >> replacement of reference to (b) by reference to (c) >> in an object (a), >> which is immutable. >> >> You could say, lets ignore this. >> >> Then, apparently , expect to see a hacky code, which as a workaround >> of >> immutability, using #become.. >> >> -- >> Best regards, >> >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor >> Stasenko AKA sig. > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > -- Best regards, Igor Stasenko AKA sig. |
Re: immutability and become (Was: Re: [squeak-dev] immutability)
|
|
On 18.03.2010, at 06:37, Igor Stasenko wrote:
> > On 18 March 2010 06:51, Markus Lampert <[hidden email]> wrote: >> I would have assumed that an immutable object cannot become anything else. Neither any other object, nor another immutable object. If you can change the state of an object in any way, either by changing it's state directly or by ex-changing it with another object, I would not consider it 'immutable'. Right - if the state of the object is changeable by any means, it's not immutable. But if you make it immutable, "becomes" of the objects it references would fail. If your object is mutable but refers to immutable objects, they can still be changed by become. This is not changing the immutable objects, only the objects referring to them. > Good. This makes it more consistent , except that ex-changing with > another object notion. > > So, you saying that i can do: > > array := Array with: foo beImmutable. > array at: 1 put: nil. > > but can't do: > > array := Array with: foo beImmutable. > foo becomeForward: nil. No, both of these would work. What you can't do is storing *into* an immutable object. #beImmutable needs to be recursive. An immutable object cannot contain a reference to an immutable object. Then you just disallow any stores into the immutable object, including becomes: immutable := (Array with: 'hi') beImmutable. regular := Array with: 'hi' beImmutable. immutable first become: 'lo'. "fails" regular first become: 'lo'. "succeeds" - Bert - |
Re: immutability and become (Was: Re: [squeak-dev] immutability)
|
|
On 18 March 2010 14:32, Bert Freudenberg <[hidden email]> wrote:
> On 18.03.2010, at 06:37, Igor Stasenko wrote: >> >> On 18 March 2010 06:51, Markus Lampert <[hidden email]> wrote: >>> I would have assumed that an immutable object cannot become anything else. Neither any other object, nor another immutable object. If you can change the state of an object in any way, either by changing it's state directly or by ex-changing it with another object, I would not consider it 'immutable'. > > Right - if the state of the object is changeable by any means, it's not immutable. But if you make it immutable, "becomes" of the objects it references would fail. If your object is mutable but refers to immutable objects, they can still be changed by become. This is not changing the immutable objects, only the objects referring to them. > >> Good. This makes it more consistent , except that ex-changing with >> another object notion. >> >> So, you saying that i can do: >> >> array := Array with: foo beImmutable. >> array at: 1 put: nil. >> >> but can't do: >> >> array := Array with: foo beImmutable. >> foo becomeForward: nil. > > No, both of these would work. What you can't do is storing *into* an immutable object. > > #beImmutable needs to be recursive. An immutable object cannot contain a reference to an immutable object. > > Then you just disallow any stores into the immutable object, including becomes: > > immutable := (Array with: 'hi') beImmutable. > regular := Array with: 'hi' beImmutable. > > immutable first become: 'lo'. "fails" > regular first become: 'lo'. "succeeds" > Ok. But are you sure about recursion? There's a lot of data structures which will be impossible to use with such immutability propagation. For instance, i want to make a single tree node to be immutable. But once i do that for any node, it will make a whole tree immutable, since node refers to its parent node. Even more, what if one of objects keeps a reference to a class? Once recursive immutability reaches this object, it will turn about everything in your system into an immutable objects. > - Bert - -- Best regards, Igor Stasenko AKA sig. |
Re: immutability and become (Was: Re: [squeak-dev] immutability)
|
|
In reply to this post by Bert Freudenberg
On Thu, Mar 18, 2010 at 5:32 AM, Bert Freudenberg <[hidden email]> wrote:
THis is Gilad's desire for Newspeak. It cam be implemented at the image level by traversing the object graph and setting immutability for each reachable object (excluding the references to classes form instances of course). Again the same VM support can serve. Much better maintainng the visited set in Smalltalk than in a VM primitive that does the same thing blindly. i.e. at the mage level it is much easier to manage the fact that it is an error to attempt to make certain objects immutable (e.g. thisContext).
I think also that "An immutable object cannot contain a reference to an immutable object." is an ideal, not an absolute. Consider some immutable object that maintains a memo cache of some time-and-space-consuming computations. We might want to void entries n the cache to keep its total space consumption down. While the object functions as an immutable one the memo cache is mutable state but doesn't render the object mutable because it is only a cache of results of some computation, not essential state in the object.
best Eliot
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |