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

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday May 17, 2007
02:29 AM

Class::Immutable and Abusing ORMs

[ #33296 ]

Tomorrow I fly to Portland for about a week and a half and I'll have little to no internet connectivity during that time. Since I've just moved into my house in London, I've had little internet connectivity for the past week, so there's a wee bit of withdrawal here.

In other news, a couple of weeks ago I was reading about immutable objects (in Haskell) and while I don't know much Haskell, the idea sounded intriguing. When you create an object, its data is "frozen". Need to change a value? Clone the object with the new data. Not only would this likely prevent side-effects, it might be perfect for threaded programming. Also, the notion of whether or not two objects are the same becomes useless. If they represent the same data, they are the same object.

I see that Stevan Little has produced Class::MOP::Immutable, but I haven't looked into it much and I don't know if it would be as transparent as what I'm thinking about.

I also need to write up a brief bit about how to use ORMs safely. I'm sure it would be controversial, but I keep seeing people adopt ORMs, dump the idea of OO and use OO wrappers around what are effectively glorified, persistent structs. Yuck. I've hinted about this in The AuthenticationFairy and I see that Piers Cawley seems to approve. In a nutshell, the idea would be "create a reasonable OO system and use the ORM underneath this sytem."

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
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 [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

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