[squeak-dev] About String vs Symbols
Locked
12
12
Re: [squeak-dev] Immutability (was Re: About String vs Symbols)
 
|
2008/7/30 Eliot Miranda <[hidden email]>:
> > > On Wed, Jul 30, 2008 at 2:16 AM, Igor Stasenko <[hidden email]> wrote: >> >> 2008/7/30 Colin Putney <[hidden email]>: >> > >> > On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote: >> > >> >> BTW, immutability involves primitive error codes and I will be >> >> introducing >> >> primitive error codes, because the performance hit is essentially zero >> >> and >> >> there is no backward compatibility issue (strange but true :) ). >> > >> > I'm all for general immutability support in the VM. >> > >> > I suspect, though, that this isn't what Stéphane was driving at. >> > Immutable >> > strings is kind of a language-level thing, and could be done without VM >> > support. One way would be to factor out a MutableString class and keep >> > it >> > distinct from regular strings. Going further, we could just remove the >> > mutation protocol and require all string creation to be either >> > stream-based >> > or functional (ie, producing new strings rather than mutating existing >> > ones). >> > >> > Once strings are immutable, interning them is a useful space >> > optimization, >> > and that *would* make symbols redundant. >> > >> > Clearly there are huge compatibility issues here, but it's a reasonable >> > thing to consider if building a system from scratch. >> > >> > Colin >> > >> >> +1 >> i think we can live without immutable support from VM. >> Arrays and Strings can be subclassed with disabled mutation methods. >> And then compiler could use these classes for literals. >> Except from compiler support, where else we need immutability? >> Do we need a generic immutability , which would allow to flag any >> object from being changed? >> This is useful feature, but i doubt that alone, it could improve code >> quality or solve security issues so easily. > > No one is saying its a magic bullet. But it is an important element in code > quality and security. > For one advantage, take a careful look at GemStone implementations in > contexts where there is per-object immutability and where there isn't. > GemStone's run-time is much simpler when there is per-object immutability > support. > I'm curious why you're so against this. Do realise the modifications to the > VM are pretty small and well-contained, and the performance overhead very > small. Also realise that VW and VA do very well with it. > > putting a write barrier on objects and then handle objects mutation to track their changes during transaction. I never worked with GemStone, but have some experience with Magma, and its using a 'hacky' way by changing an object's class to put a write barrier on objects. So, it is possible to do the same without immutable bit. And also, it is more precise , because there can be many reasons why you get a NoModificationError (it can be a simple programming error) , while if you catching it with write barrier - you definitely know that it is what you expected and can deal with it properly. And if system allows marking object back to be mutable? Then how you could really tell that particular object is never modified during its lifetime? I think it should be sealed by behavior, by preventing any methods, which can modify an instance, to appear in class. So, the only real thing which can guarantee that given object remain unchanged during its lifetime is a class. An immutability bit is much worse thing comparing to this. And second, its against the spirit of smalltalk. Smalltalk is one of the languages, where it tries to implement all things through behavior, not through using different VM/language magic intrinsics. It is not a problem, what VM having or not having an immutablity bit, its a problem, that current kernel classes and/or collections designed without looking at possible use cases where user wants to prevent object from being changed during its lifetime. So, maybe we should think how to refactor these classes instead of including one more magic thing? -- Best regards, Igor Stasenko AKA sig. |
[squeak-dev] Re: Immutability (was Re: About String vs Symbols)
|
|
On Thu, 31 Jul 2008 21:28:03 +0200, Igor Stasenko wrote:
... > I think it should be sealed by behavior, by preventing any methods, > which can modify an instance, to appear in class. This is no con for the other proposals, but pro for the best that I've ever seen :) Go Smalltalk, go ! :) /Klaus > So, the only real > thing which can guarantee that given object remain unchanged during > its lifetime is a class. An immutability bit is much worse thing > comparing to this. > > And second, its against the spirit of smalltalk. Smalltalk is one of > the languages, where it tries to implement all things through > behavior, not through using different VM/language magic intrinsics. > It is not a problem, what VM having or not having an immutablity bit, > its a problem, that current kernel classes and/or collections designed > without looking at possible use cases where user wants to prevent > object from being changed during its lifetime. > So, maybe we should think how to refactor these classes instead of > including one more magic thing? > |
Re: [squeak-dev] Immutability (was Re: About String vs Symbols)
|
|
In reply to this post by Colin Putney
On Jul 30, 2008, at 9:06 AM, Colin Putney wrote: > > On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote: > >> BTW, immutability involves primitive error codes and I will be >> introducing primitive error codes, because the performance hit is >> essentially zero and there is no backward compatibility issue >> (strange but true :) ). > > I'm all for general immutability support in the VM. > > I suspect, though, that this isn't what Stéphane was driving at. > Immutable strings is kind of a language-level thing, and could be > done without VM support. One way would be to factor out a > MutableString class and keep it distinct from regular strings. Going > further, we could just remove the mutation protocol and require all > string creation to be either stream-based or functional (ie, > producing new strings rather than mutating existing ones). for example. > > > Once strings are immutable, interning them is a useful space > optimization, and that *would* make symbols redundant. > > Clearly there are huge compatibility issues here, but it's a > reasonable thing to consider if building a system from scratch. > > Colin > |
Re: [squeak-dev] Immutability (was Re: About String vs Symbols)
|
|
On Fri, Aug 1, 2008 at 5:13 PM, stephane ducasse
<[hidden email]> wrote: > > On Jul 30, 2008, at 9:06 AM, Colin Putney wrote: > >> >> On 29-Jul-08, at 1:24 PM, Eliot Miranda wrote: >> >>> BTW, immutability involves primitive error codes and I will be >>> introducing primitive error codes, because the performance hit is >>> essentially zero and there is no backward compatibility issue (strange but >>> true :) ). >> >> I'm all for general immutability support in the VM. >> >> I suspect, though, that this isn't what Stéphane was driving at. Immutable >> strings is kind of a language-level thing, and could be done without VM >> support. One way would be to factor out a MutableString class and keep it >> distinct from regular strings. Going further, we could just remove the >> mutation protocol and require all string creation to be either stream-based >> or functional (ie, producing new strings rather than mutating existing >> ones). > > for example. >> >> >> Once strings are immutable, interning them is a useful space optimization, >> and that *would* make symbols redundant. >> >> Clearly there are huge compatibility issues here, but it's a reasonable >> thing to consider if building a system from scratch. >> >> Colin It was already pointed out that interning *all* strings is *not* going to save space. What is wrong with having symbols and strings? I find symbols to be one of the great insights of Smalltalk [1] and Java's string handling to be one of its worst features. [1] The great thing about it is instead of making some meaningless number, and then a macro that replaces your readable string with that number (as one must do in C, etc) you just use your meaningful string as a symbol and it can be the same cost as a meaningless number (since the native code need only look at the underlying address) |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |