Re: immutibility

Hi Randal, 

>>>>> "Chris" == Chris Cunnington <[hidden email]> writes:

Chris> I'm going to disagree with you pretty hard about this.

I'm hoping your entire post is tongue in cheek.

Immutability solves a number of problems.  Just because you aren't
currently experiencing those problems doesn't mean others aren't.

The most important part is "how can I have an object that's guaranteed not to
change without being notified?", which is useful in *any* place where local
objects need to represent remote state.  Right now, that's being solved in
Squeak by having a second shadow copy of the object *every time*.  That's
expensive.  Take a look at how Magritte works.  Take a look at how Magma
works.  Take a look at how GLORP works.  I'm sure you don't see anything
tedious in *those*!

With immutable objects, you pay the price of a shadow copy only when
the thing actually changes!  Far better.

Seriously, I hope you're being naive (or a misplaced funny) rather than
serious. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <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

On 17.03.2010, at 17:12, Chris Cunnington wrote:
Uh oh. What did Randal do to deserve this retaliation? ;)

He's proposing a feature. A useful one in my mind. It's general enough to not be only useful for databases, but for multi-media apps too.

And even if it *was* only for databases it wouldn't hurt to support it in Squeak. It takes nothing away from the fun.

Also, I hope that we will be able to share at least the VM with all the Squeak-based projects. So far that has worked fine. So if there was a project that would like to see this feature in the VM I would support it for that reason alone, even if Squeak Trunk does not use it. In fact there are such features already.

- Bert -

I've been thinking about immutability in Squeak too! And hell yeah
it's bigger than databases.

 - makes concurrency painless
 - improves testability
 - allows certain compiler optimizations that aren't possible when
there's mutable state
 - makes certain things formally provable that aren't when there's mutable state

I think these are all great reasons to experiment with. I'd like to
assert though: immutability should be introduced in a way that's
optional, and doesn't introduce any new syntax.

I'd like to ask an object #isMutable and be able to do certain things
differently if it answers false. Mutable objects are ones that have
state that can change.

Randal: FWIW, I think the Newspeak guys are playing with this stuff.

On Wednesday, March 17, 2010, Stephen Pair <[hidden email]> wrote:
--
Casey Ransberger

This is where I start to get confused.  If "immutable" is a global
attribute of each object, wouldn't there need to tend to need to be
only one universal user of the bit at a time?  Otherwise, the database
might be setting the bit on an object for it's purposes, but for which
the [your other favorite framework] in having its own purposes for the
bit, might not want it set at that time...?

I am of course, wondering about my own context.  In thinking about the
purposes of an ODBMS, one of the chief beneciary's of this type of
change, it could help Magma immensely.  But then Magma would have to
impose on the user/application that, "the immutable bit belongs to
Magma, don't use it or mess with it, ok?  I need it..."  But the
feature is not there today, so at least legacy applications would
enjoy the performance boost..




On Wed, Mar 17, 2010 at 1:26 PM, Casey Ransberger
<[hidden email]> wrote:

On 18 March 2010 03:35, Chris Muller <[hidden email]> wrote:
> This is where I start to get confused.  If "immutable" is a global
> attribute of each object, wouldn't there need to tend to need to be
> only one universal user of the bit at a time?  Otherwise, the database
> might be setting the bit on an object for it's purposes, but for which
> the [your other favorite framework] in having its own purposes for the
> bit, might not want it set at that time...?
>
Good point. Really, what you would do, if you having two frameworks,
sharing same object,
and both want to use (set/reset) immutable bit for own purposes?
This creates a conflict.



--
Best regards,
Igor Stasenko AKA sig.

On Mar 17, 2010, at 8:45 PM, Igor Stasenko wrote:

Yes it does, so you need to make a decision about which of the two frameworks you will use, or you need to look at using them in such a way that they don't interfere with each other. Consider the two most likely candidates for use of immutability (in my experience): compiler and database proxy.
 - With immutability, the compiler can share literals (strings, arrays, etc).
 - With immutability, a database framework can recognize modifications to objects copied from a remote system.

For the most part, these two uses will not conflict. The potential conflict would be where a compiler literal is passed to the database framework and written to a remote store. By default (say) the database framework would mark the object immutable and if a modification was attempted it would log it as 'dirty' (needing to be written in the next commit) and then change it to be mutable. This would corrupt the compiler usage.

The solution is to have the database framework notice on its first write that the object is immutable and keep it in its cache with a 'immutable' flag so that it would not accept an attempt to modify it.

The general rule is that one can only make mutable something that one has earlier made immutable. With that, the risk of conflicts is much reduced.

In any case, the potential for a conflict is not a reason to deny the feature. One simply has to use it carefully and with knowledge of what the frameworks expect.

James

>Jesse has some crazy idea about object memory? I say great. Fulmer
>wants to bring Cobalt to the Trunk? I say that's what we're all
>about. VPRI has some craziness called Ometa? Bring it on.

Hmm...I don't see why Randal's "crazy idea" about immutability
couldn't be equally meritorious toward "what we're all about".


>Databases are for peasants.

Wow, someone's Wheaties went soggy. :-)
Typing as an apparent peasant, when one finds the need to soil one's
leggings by interacting with a database, Randal's suggestion would
nicely reduce code noise with some Smalltalk innovation flair thrown
in.


>We are unique and occupy a unique position. Let's embrace that. Stop
>trying to turn us into shadows of Gemstone, Cimcom, or other
>merchants of tedium. If Kent Beck isn't happy with Squeak, I don't
>see it as our job to cater.

I did not interpret Randal's suggestion as Gemstone/Cincom-envy. He
merely offered a usage case with implementation references. Given the
"coolness" quotient you seem to seek I'd say there's plenty to
consider with respect to semantic cleanliness for concurrence
situations (in addition to resource efficiencies that become possible
compared to a "only mutables need apply" world).


>There is nothing else on earth like us and what we do.
>Squeak is a never ending game of capture the flag.

I'll admit it, I am mostly a lurker so my cred points are very thin.
However, I am a Smalltalk enthusiast and found the reaction to
Randal's suggestion overly dismissive.

--
----------------------------------------------------------------------
Anthony Anton        3800 243rd Place SE          Phone:  425-313-1024
                      Issaquah, WA 98029           Cell:   425-444-3084
Concept Systems      [hidden email]     FAX:    425-313-1024

On 18 March 2010 07:26, James Foster <[hidden email]> wrote: Immutability is not the only way how one can address the immutability
of literals.
Take a symbols, for instance: an implementation inherently maintains a
set of symbols and makes sure they are not mutable and unique.
This means, that we could do the same for any other kinds of literals:
arrays, strings, characters, and share them without the need of
introducing an immutable bit.

> For the most part, these two uses will not conflict. The potential conflict would be where a compiler literal is passed to the database framework and written to a remote store. By default (say) the database framework would mark the object immutable and if a modification was attempted it would log it as 'dirty' (needing to be written in the next commit) and then change it to be mutable. This would corrupt the compiler usage.
>
> The solution is to have the database framework notice on its first write that the object is immutable and keep it in its cache with a 'immutable' flag so that it would not accept an attempt to modify it.
>
do you mean, like this:

object beImmutable.
database commit: [ object ].
object beMutable.
object setFoo: bar.
object beImmutable.
database commit: [ object ].

the above is an example when object, recorded as an immutable one,
then mutated outside a DB transaction. So db can't capture the attempt
to modify it.
What GemStone doing to handle this?

Another thing, i think, is how to allow nesting:

object beImmutable.
[
  [ object setFoo: bar ]
   on: AttemptToModifyImmutable do: [:ex |  framework1 handleException: ex. ]
]
    on: AttemptToModifyImmutable do: [:ex | framework2 handleException: ex. ]

in this way, if framework1 were one who set immutable bit, it should
handle it and continue as normally.
but, if framework1 seen this object before as an immutable , then it
should pass the exception to outer layer, who may handle it -
framework2.
But then it could be problematical to have changes made by framework2
be seen by framework1.

> The general rule is that one can only make mutable something that one has earlier made immutable. With that, the risk of conflicts is much reduced.
>

> In any case, the potential for a conflict is not a reason to deny the feature. One simply has to use it carefully and with knowledge of what the frameworks expect.
>

I'd say that while immutability is helping to make databases more
fast, it actually has a much wider usability.
All that OODBs need is to track the objects which were modified during
transaction.
Immutability is not the only way how to achieve that.

> James
>

--
Best regards,
Igor Stasenko AKA sig.

On 18.03.2010, at 06:26, James Foster wrote:
IMHO there should be no way to reset the immutable flag. You can implement "soft" immutability in the image, but "hard" VM-level immutability needs to be permanent, no fiddling possible. Once set, the object stays immutable. Only a copy of an immutable object will be mutable again.

- Bert -

On 2010-03-18, at 5:39 AM, Bert Freudenberg wrote:

> HO there should be no way to reset the immutable flag. You can implement "soft" immutability in the image, but "hard" VM-level immutability needs to be permanent, no fiddling possible. Once set, the object stays immutable. Only a copy of an immutable object will be mutable again.

This would be good for some use cases - literals, for example, but not so good for others. One of the common uses of "immutability" is not so much to *prevent* mutation, as to control it: databases, concurrency etc. Do you have another feature in mind for these cases, or some overriding interest in immutable immutability that you want to pursue?

Colin

On Mar 17, 2010, at 11:28 PM, Igor Stasenko wrote:

> the above is an example when object, recorded as an immutable one,
> then mutated outside a DB transaction. So db can't capture the attempt
> to modify it. What GemStone doing to handle this?

Actually, GemStone traps object modification at the byte-code level in the VM so does not rely on immutability to be informed of a modification.

James

On 18.03.2010, at 15:51, Colin Putney wrote:
>
>
> On 2010-03-18, at 5:39 AM, Bert Freudenberg wrote:
>
>> HO there should be no way to reset the immutable flag. You can implement "soft" immutability in the image, but "hard" VM-level immutability needs to be permanent, no fiddling possible. Once set, the object stays immutable. Only a copy of an immutable object will be mutable again.
>
> This would be good for some use cases - literals, for example, but not so good for others. One of the common uses of "immutability" is not so much to *prevent* mutation, as to control it: databases, concurrency etc. Do you have another feature in mind for these cases, or some overriding interest in immutable immutability that you want to pursue?
>
> Colin


Seems to me like two separate issues - one being informed of modifications, and one preventing modifications. Immutability to me means the latter. The former is more like a write barrier.

With true immutables you can start developing in a mixed object/functional style, which would allow interesting optimizations, e.g. for concurrency, memoization etc.

- Bert -

On 3/18/10, Bert Freudenberg <[hidden email]> wrote:

>  With true immutables you can start developing in a mixed object/functional style, which would allow interesting optimizations, e.g. for concurrency, memoization etc.

I've developed in a mixed object/functional style for years, and I
think a lot of other people do, too.   You don't need language support
for this, though I expect it would be helpful.  It makes concurrency
and distributed programming easier, and is important when you are
dealing with databases.  Eric Evans calls this "Value Object" in his
book "Domain Driven Design".

-Ralph Johnson

On 18.03.2010, at 16:30, Ralph Johnson wrote:
Right, the style is possible without VM support in your own subsystem. But being able to *guarantee* immutability would allow to generalize this beyond your own special-purpose code. And possibly it would enable further VM-level optimizations.

- Bert -

On 18 March 2010 17:23, Bert Freudenberg <[hidden email]> wrote: Right! And for OODBs first is sufficient.

> With true immutables you can start developing in a mixed object/functional style, which would allow interesting optimizations, e.g. for concurrency, memoization etc.
>
I don't sharing your optimism, based on immutability.
You can't run away from the fact that computing is the way of
transforming data from one form into another.
So, somewhere, either in language or at VM level, you have to mutate
the state of data, otherwise you can't do much.

> - Bert -
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 18.03.2010, at 16:45, Igor Stasenko wrote:
Free advice of the day: don't ever get near a convention of functional programmers ;)

- Bert -

>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:

Bert> Free advice of the day: don't ever get near a convention of functional
Bert> programmers ;)

But you'll baffle them by mutating in place. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <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