Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • The Erlang language is also based around the fact that after you give a variable some value, you can't change it back. You can invoce your function again with a new calulated value for example.

    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
    • 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 [] page on the subject is pretty decent actually).

      There is actually a single assignment C dialect [], a single assignment Java dialect [] and if you dig, I bet you can find one for FORTRAN too.

      - Stevan

  • Ovid,

    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

    • 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.

      • Actually, you'd want to lock the values, too.

        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
  • The new bible for concurrency in Java (Java Concurrency in Practice []) 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.