What does the following code do?

my $effect = Effect->new;
$effect->set( salary => 1.02, '*' ); # A 2% raise
$employee->apply_effect( $effect );
[download]

The exact same effect can be achieved by having all your objects inherit from a base class with

sub AUTOLOAD {
# do nothing
}
[download]

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

There are some times when you want missing fields to be ignored but you should make that explicit in your code by doing something like

$employee->salary(  $employee->salary * 1.02  );
# we don't mind if they don't have a frobnitz
eval { $employee->frobnitz(  $employee->frobnitz + 1.5  ) };
[download]

Problems with effect objects

• Cumbersome - more code means more bugs
• Slower
• Ignoring errors should not be the default

The only real use I can think of for an effect object is to use it as a callback mechanism. Various people can add effects (or even remove or reorder effects) as the object is passed around, but I still don't see a reason to make it ignore errors by default.

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:

my @employees; # Defined elsewhere as array of Employee objects
my $effect = Effect->new;
$effect->set( salary => 1.02, '*' );
$_->apply_effect( $effect ) for @employees;
[download]

Compared to:

my @employees; # Defined elsewhere as array of Employee objects
$_->salary( $_->salary() * 1.02 ) for @employees;
[download]

Now we have to cram more into the for statement, while the Effect implementation lifted some of that complexity out. And we could even get rid of a line by having our Effect constructor take what we were passing to the set() method:

my $effect = Effect->new( [ salary => 1.02, '*' ] );
[download]

Expanding this further, what about setting multiple attributes?

my @employess; # Defined elsewhere
my $effect = Effect->new(
    [ salary    => 1.02, '*' ],
    [ frobnitz  => 1.5, '+'  ],
);
$_->apply_effect( $effect ) for @employees;
[download]

Compared to:

my @employees; # Defined elsewhere
for (@employees) {
    $_->salary(    $_->salary() * 1.02 );
    $_->frobnitz(  $_->frobnitz + 1.5  );
}

# Or if you want to keep closer to the old code and 
# live with O(2n) . . . 
$_->salary(    $_->salary() * 1.02 ) for @employees;
$_->frobnitz(  $_->frobnitz + 1.5  ) for @employees;
[download]

Now the line-count complexity isn't as clear.

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]

Other than getting what operation we want to perform (which we have to do in any case), this code is barely more complex than the first case.

Key note: OOP is not about decreasing complexity. It's about keeping it manageable.

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

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

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.

I'm working on a framework for building games in Perl that uses just such a design. The framework provides a domain-specific language that is used to build a series of Perl objects (so you can use this framework, at least at a basic level, without any Perl knowledge). Effects can be created in this language just like any other item in your game.

In an RTS game, buildings could be considered units that don't move. You can shoot them, repair them, and add upgrades using whatever methods the game designer provides, just like any other unit in the game.

In our RTS example, a building wouldn't have a "speed" attribute like a normal unit (or it would have a speed of 0). You could also have a weapon that makes a unit travel at 50% of normal speed. Fire such a weapon on a building would, at the code level, apply the effect of the weapon to the building. The building would then simply ignore the effect. The player is free to keep on shooting if they want. Or the interface designer could make it difficult (need to use the force-fire feature or some such) to shoot such a weapon at a building, but that's a matter for the interface, not for the level I'm currently working at.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

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.

While I'm at it, a couple of questions. Where is this "no mutators" idea coming from? What exactly is the damage that results from having mutators?

I've read the Java world article and all it's saying is don't create public mutuators for fields that are for internal use only. Blindingly obvious advice but I can understand why it may have been needed. I imagine the sequence of events in Javaland to be

• direct field access is bad (ok so far)
• make accessor methods and change public fields to private (still ok)
• get in the habit of making all fields private (fine, just remember that some are private because you don't want direct access and some are private because you don't want any access)
• now that everything is called private, get confused and start adding accessors for all private fields (doh!)

That last step would probably be performed by newer programmers, copying without understanding, seeing that public fields are not being used at all and that private + accessor seems to be "correct".

Why do you think you need to poke a value into a memory location like you're an ASM Programmer? Because, with a mutator, that's really what you're doing. You're not telling the object to do something and trusting it to accomplish the task you've set for it. You're pushing values into its head, then executing a series of statements that run based on the values you've shoved into its head. Which means you've broken encapsulation.

No, not because you shoved values into the object's head. Because you had to know what values to shove into its head into order to make sure the series of statements you ran did what you wanted it to do.

There is always a better way to write an object than to use mutators. Except, it takes more time in the design phase and Lord&Lady know that no-one ever has time to design.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

What do mean "like an ASM programmer". I'm talking about a fuly overridable way of setting things. I am trusting the object to do it. I know you're get at ask don't tell but what better way is there to ask the object "please update your salary field to $50000" than by saying

$employee->setSalary(50000);
[download]

or

$employee->Salary = 50000;
[download]

The whole problem here comes originally from people exposing highly interrelated fields as independently manipulable things when they shouldn't and in that case mutators are wrong. The whole idea is to be able to have invariants that are always true about an object and giving access to individual fields can sometimes allow things outside the object to leave the object in a state where the invariant is no longer true. I totally appreciate that. But sometimes objects have fields that are independent of all other fields and can be twiddled by anyone without breaking an invariant. There are only 2 choices for implementing these - direct field access or mutator and in most languages direct access is bad because it cannot be overridden in the future so you use a mutator.

The "no trivial mutators" idea comes from the fact that if you wanted a struct, then you should have used a struct and left the OO baggage behind.

Java gets stuck on the fact that everything has to be an object, which means that when a struct really is the best way to do something (as it is in many simple programs), you still have to define it in terms of an object. That's an inheirent difficulty in single-paradigm languages.

We don't have that problem in Perl, but it's still good advice that if you're going to trouble yourself with OO, then you should really do OO. I'm not going to demand that you apply OO everywhere, only that if you use it, you use it correctly. Bad OO is often worse than not using it in the first place.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Why should I have to choose between struct and object? It's incredibly useful to have both and I still haven't seen an example of anything bad happening when that is done. Look, for example, at Haskell, which uses multiple dispatch, where not only structs have object behaviours but even scalars (which are equivalent to structs with a single field) have too.