in reply to Using tie to return value of anonymous sub

How is proper OOP Syntax awkward? Are you talking about awkwardness of defining the class or awkwardness of using the class? I would think that the syntax of using classes is simpler than what you have. E.g. 
Your way:

$player->{strength}

OOP way:

$player->strength

Your way:

$foo->{bar}->($baz)

OOP way:

$foo->bar($baz)

[download]
Defining simple accessor/mutator methods is very straightforward, and there are many modules in CPAN that make it even easier. Spiffy is one of the most popular these days, but there are many others.

--DrWhy

"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

Replies are listed 'Best First'.
Re^2: Using tie to return value of anonymous sub
by Anonymous Monk on Feb 17, 2006 at 08:18 UTC
    Spiffy is one of the most popular these days, but there are many others.
    Not exactly. INGY wrote it, and he creates many many modules, so puts it in many many modules.
[reply]
Re^2: Using tie to return value of anonymous sub
by dabreegster (Beadle) on Feb 18, 2006 at 16:37 UTC

    Well, both. I guess it's just a personal thing with OOP syntax. I'm in favor of using hashes both as an implementation and an API. But it's tough to do the latter in some cases.

    Mainly, the place where the OOP method really breaks down is multidimensional data structures. How is something like $player->{react_before}{poisoned} to be used? $player->react_before->{poisoned}? Something even more awkward?

    Either way, I guess the real problem is syntax and I guess the real solution is to find a scheme for real methods that I like. Until proper APIs can be created with tie and hashes, I guess I haven't a choice. Thank you.

[reply]

      Assuming player.react_before.poisoned (to use a neutral syntax since syntax is the topic) sounds like a way of setting (and getting?) an event handler, how about something like the following: 

      sub name {
   my ($self, $name) = @_;
   $self->{name} = $name if @_ >= 2;
   return $self->{name};
}


sub react_before {
   my ($self, $event, $handler) = @_;

   if (@_ >= 2) {
      $self->{event_handlers}{$event}{before} = $handler;
   }

   return $self->{event_handlers}{$event}{before};
}


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

   if (@_ >= 2) {
      if ($poisoned != $self->{poisoned}) {
         my $handler= $self->{event_handlers}{poisoned}{before};
         $poisoned = $handler->($self, 'poisoned', $val) if $handler;
      }

      if ($val != $self->{poisoned}) {
         $self->{poisoned} = $poisoned;

         my $handler = $self->{event_handlers}{poisoned}{after};
         $handler->($self, 'poisoned', $poisoned) if $handler;
      }
   }

   return $self->{poisoned};
}


$char->react_before(poisoned => \&handler);

$char->poisoned(1);

print(
   $char->name,
   ' is ',
   $char->poisoned ? 'posioned' : 'not poisoned',
   ".\n"
);

      [download]
[reply]
[d/l]
[select]
      One of the things I really like about Perl is that it leaves room for personal preference in terms of how to implement things. You can mix and match different programming paradigms as you see fit. You can go functional in domains where that makes most sense, OO where that makes sense, and so on.

      That said there are times where 'personal preference' gets in the way of writing the best code. If you (generic) are opposed to OO in all circumstances due to personal preferences you are likely to write code in a way that is one or more of more complex, more buggy, and more difficult to extend and maintain than it would be otherwise. I have a sense here that you may be going in that direction here. Seems like to me that you are going through some awful complex gyrations to avoid OO syntax, but of course you are really using OO since tie just let's you do OO while making it look like you are doing some other kind of programming. This will give you a performance hit (though I'm not sure how much the tie-ing overhead really hits performance) which can be an issue in some types of computer games (I don't know about your particular case though).

      --DrWhy

      "If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."

[reply]

In Section Seekers of Perl Wisdom