in reply to Re^12: Assignable Subroutines
in thread Assignable Subroutines

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.

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.

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

Replies are listed 'Best First'.
Re^14: Assignable Subroutines
by fergal (Chaplain) on Jan 27, 2005 at 19:28 UTC
    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.

[reply]
[d/l]
[select]

      For now, I'll provide two other ways to accomplish what you want, through functional programming or just using Perl itself . . .

      Both examples require more functionality in the code higher up. It's not OO due to insufficient encapsulation.

      Again, if you don't want to use OO, that's fine, as there are plenty of places where OO is inappropriate. But if you are going to use it, do it right.

      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.

      No, you don't:

      package Employee;

. . . 

sub apply_effect 
{
    my ($self, $effects) = @_;

    # $effects->list returns a list of objects containing 
    # the singular effects
    foreach my $effect ( $effects->list ) {
        my $attribute = $effect->attribute;
        throw_exception() unless exists $self->{$attribute};

        # Rest of code
    }
}

      [download]

      Essentially a "deny by default" strategy. Now your test suite just needs to throw a few effects that are known to have attributes it's not going to use, check that exceptions were thrown, and you're set.

      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.

      The important point is that it's going to depend on the application. I was making a general framework, and in certain games it's going to make sense to ignore, while others might want to throw an error. It's none of my businesses to impose that on the game designer. Further, this strategy may be useful outside games, and I'd rather have a general framework that is easily modified rather than writing from scratch.

      I can see the argument for using (improved) lvalue subs for internal use (as dragonchild mentioned higher up the thread). But rarely/never outside the class.

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

[reply]
[d/l]
        Both examples require more functionality in the code higher up. It's not OO due to insufficient encapsulation.
        I don't understand what you mean by "higher up". The code is almost identical to yours, just written directly in Perl, rather than some new and cumbersome operator application language.

        I also don't understand what you mean about "insufficient encapsulation". Why is that? If you mean that I shouldn't be calling $_->salary directly than you are arguing circularly as this whole discussion is about whether that's OK or not. If you don't mean that, please tell me what I should have encapsulated but didn't.

        As for the "deny by default" strategy, I get it free with Perl already, why do I need to write all that code to get it back again? Plus, allow by default is really easy to implement in "normal" Perl too so it's not like it was urgently in need of simplification. Also, it's a pain now to ignore some but not others and it's still under the control of the called object, not the caller. This may suit a framework (where things kind of become inside-out) but it's not the general case.

[reply]

In Section Meditations