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."
Re:Immutable objects
Stevan on 2007-05-17T15:04:27
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
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.
- StevanRe:Class::MOP::Immutable != Class::Immutable
Ovid on 2007-05-17T14:19:40
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:Class::MOP::Immutable != Class::Immutable
Stevan on 2007-05-17T15:07:01
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.
