Somehow, my notions of relaxing on the weekend are a bit odd (though not for geeks). On Friday, I made it to Flux, a local Goth/Industrial dance night. Their new location has leather couches, a leopard-print rug and white fur covered columns. Needless to say, people were a bit surprised.
I also finished and submitted the patch for the ref ($proto) || $proto documentation issue and am pleasantly surprised to note that it was accepted and applied to bleedperl. I now have three patches in Perl. Yay me :)
I'm also about a third of the way through converting a C program to Perl. When it's done, I will have an artificial life simulator that allows a programmer to create a synthetic ecosystem using Lamarckian evolution and simple neural networks to view the interactions of "tiger", "cow", and "plant" agents in a small toroidal world. This is teaching me quite a bit about different coding styles and I've discovered that Class::Struct is very handy with such a conversion. The one thing that I would really like to change about Class::Struct (and subclassing is explicitly forbidden) is to make the methods lvalues. It would make conversion much simpler if I could do this:
$agent->location->y = 13;
And then I went hot tubbing.
Have you read the bit in perlsub that suggests lvalue methods like that are a bad idea?
A normal mutator can check the supplied argument before setting the attribute it is protecting, an lvalue subroutine never gets that chance.
Okay, it's a run-on sentence, but it seems reasonable to me, and it then gives an example. Do you disagree? I haven't done much with lvalue subroutines, so maybe there's a way around the problem.
Re:lvalue methods
Ovid on 2004-04-05T23:35:53
Wow. That perldoc sentence is as bad as some of the sentences I've been known to spit out: s/,/;/;.
I think you're right. A nice idea foiled by a poor implementation
:(
A normal mutator can check the supplied argument before setting the attribute it is protecting, an lvalue subroutine never gets that chance.
