So now we have a Perl that doesn't give you compile time checking and doesn't give you run time checking either!

That's why you have a test suite.

* Cumbersome - more code means more bugs

See above. Also, consider adding this attribute to many employees:

Cool, I can stop doing use strict now too because my test suite will catch my typos :-) I can buy the argument that weak typing and good testing can be better than strong typing (but only in those languages where strong typing is broken and forces you to do all manner of things to work around it or just switch it off - Java, C, C++) but that doesn't mean testing should replace all other error detection mechanisms.

The (il)logical conclusion of "testing is all you need" is that you should just write your tests and let your computer generate code at random until finally you get code that passes your tests.

OK, back to the examples. Firstly I'm not defending

$_->salary(    $_->salary() * 1.02 );
[download]

as the ideal way of doing things. I'm one of the people in this thread arguing for Lvalue accessor methods, so the accessor examples should really be

$_->salary *= 1.02 for @employees;
[download]

and

for (@employees) {
    $_->salary *= 1.02;
    $_->frobnitz += 1.5;
}
[download]

both of which are more readable and shorter than either of the other techniques.

Did I also mention that it's much easier for effects to dynamically change what operation they do? What if the user wants to add to a salary instead of applying a multiplier?

my $do_operation; # Defined elsewhere, possibly from user input
my $by_ammount; # Also from user
my @employees; # Also defined elsewhere
my $op = 
    $do_operation eq 'add'   ? '+' :
    $do_operation eq 'mult'  ? '*' : 
    # And so on
;
my $effect = Effect->new( [ salary => $by_ammount, $op ] );
$_->apply_effect( $effect ) for @employees;
[download]

What you're doing here is essentially creating a mini-language for operator application. Because Perl doesn't have a decent macro system (like lisp's) you then have to make people write code in an alreasy parsed form. There are several other ways to do this. Take a look at Tangram for a vary cool system that uses overloading and allows people to write their SQL clauses in Perl. For now, I'll provide two other ways to accomplish what you want, through functional programming or just using Perl itself

my $do_operation; # Defined elsewhere, possibly from user input
my $by_ammount; # Also from user
my @employees; # Also defined elsewhere
my $op = 
    $do_operation eq 'add'   ? sub {$_[0] += $_[1]} :
    $do_operation eq 'mult'  ? '*' : sub {$_[0] *= $_[1]}
    # And so on
;
&$op($_->salary) for @employees;
[download]

my $do_operation; # Defined elsewhere, possibly from user input
my $by_ammount; # Also from user
my @employees; # Also defined elsewhere
my $op = 
    $do_operation eq 'add'   ? '+' :
    $do_operation eq 'mult'  ? '*' : 
    # And so on
;
eval "\$_->salary $op= \$by_amount" for @employees;
[download]

If Perl had proper macros (like lisp) then this would be much nicer.

* Slower

Then why are you using Perl objects at all? And your proposed solution is an AUTOLOAD everywhere, which is one of the last places checked when a method is called. That'll be even slower.

I was just pointing it out. The AUTOLOAD method is not slower by the way. It's much faster to find the AUTOLOAD method (which is then cached) and do 1 multiplication and 2 method calls than it is to jump into your effect object and do all the processing that is required to call the method, apply the relevant operation, and call the method again to store the result. That said, I'm not sure which would be faster between overridable lvalue accessors and effect objects.

Finally, I absolutely was not proposing empty AUTOLOAD methods as a solution to anything, I was just remarking that they can provide exactly the same problems as effect objects with a lot less hassle.

* Ignoring errors should not be the default

I don't consider it an error. Classes that don't have the given attribute ignore it. Those that do will use it. It's very polymorphic.

It's maximally polymorphic, any operation can be applied to any object whether it makes sense or not. Or maybe it's monomorpic because as far as callers can tell, there's only 1 type of object. For conistency one should also apply this principle to action methods too. So when I do

$reactor->insert_cooling_rods;
$reactor->shut_down_liquid_cooling;
[download]

And if I was passed a reactor that doesn't have cooling rods then I should just continue on anyway. This does not seem very wise.

If you want it to be an error, there's nothing stopping you from defining an exception to be thrown when your object encounters an Effect attribute it doesn't use.

This is completely wrong. Now the object designer has to anticipate all of the infinte set of incorrect things that people might try to do with his object and explicitly make each one an error. Previously he only had to define the very small set of correct things people can do and anything outside that set was automatically and error.

Even worse, whether it's an error or not is now entirely in the hands of the called object when actually the caller is is the one that knows if it was OK to skip a certain field. The called object does not know (and shouldn't care) about the context and so is not in a position to be the final judge of what's an error.

It really seems to me that in your game, buildings should just ignore the speed message. But even if your RTS engine is a special case where all sorts of things should ignore all sorts of messages then maybe you're right to do what you're doing but that's still not an argument as to why software in general should do it too.