NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Immutable objects (Score:1)
They do that because it avoids problems with side-efects and action at a distance.
I've been learning Erlang and I must say, I like it a lot, and I hope that the concurrency model of Perl6 will borrow some stuff from them.
life is short
Re: (Score:1)
Variables in Erlang are "Single Assignment", but this is not only for avoiding of side-effects but also because by never allowing the mutation of a variable the compiler can make lots of assumptions off of which it can make lots of optimizations (the wikipedia [wikipedia.org] page on the subject is pretty decent actually).
There is actually a single assignment C dialect [sac-home.org], a single assignment Java dialect [wikipedia.org] and if you dig, I bet you can find one for FORTRAN too.
- Stevan
Class::MOP::Immutable != Class::Immutable (Score:1)
Class::MOP::Immutable is specifically made to be used with Class::MOP::Class instances. It takes those and makes them immutable, meaning your (meta)class cannot be changed. It will not work for random classes (thought some of it's internals could be re-used to build a Class::Immutable).
Class::Immutable could be as simple as calling Hash::Util::lock_keys on the instance (assuming its a HASH based instance of course). Of course some nice class-building sugar would be good too.
- Stevan
Re: (Score:2)
Actually, you'd want to lock the values, too. Mainly, it would simply be a matter of writing a class with only accessors and no mutators. Then you'd just add a clone method which allows data values to be replaced.
Re: (Score:1)
Good point :)
This would actually be quite easy to implement within the Moose/Class::MOP frameworks, if I get the tuits I might give it a whirl.
- Stevan...and threading (Score:2)
The new bible for concurrency in Java (Java Concurrency in Practice [amazon.com]) talks a good bit about the benefits of immutable objects and threading. No mutation == threadsafe objects == happy developers.
On a sidenote, JCIP is probably one of the best technical books I've ever read. If nothing else it'll scare the crap out of you that so many systems in the world use awful concurrency techniques. But that's true of nearly everything -- the older I get the more I'm amazed that our world functions at all.