in reply to Re: Prevent direct acces to object's attributes
in thread Prevent direct acces to object's attributes

At least in respect towards interoperability, Moose-based objects are less problematic than inside-out objects.
That statement surprises me. Classes implemented as inside out object do not enforce any restrictions on classes that inherit from them, and they can inherit from any class, regardless of how it's implemented.
  • Comment on Re^2: Prevent direct acces to object's attributes

Replies are listed 'Best First'.
Re^3: Prevent direct acces to object's attributes
by Corion (Patriarch) on Sep 07, 2009 at 18:25 UTC

    Yeah - on second thought the distinction isn't as grave as I made it out to be. In fact, I have used that transparent property of inside-out objects myself to "attach" data to foreign objects that didn't like their data structure modified.

    If an object already is an inside-out object, you have no choice but to continue down that road. The same holds true for Moose-based (hash) objects.

    And in the reverse, if you have a hash-based object, you can glue inside-out extensions to it, and it seems as if you can derive a Moose-based class from it.

      If an object already is an inside-out object, you have no choice but to continue down that road.
      That's not true.
      package InsideOut; use strict; use warnings; use Hash::Util::FieldHash qw[fieldhash]; fieldhash my %name; sub new { my $class = shift; bless do {\my $var}, $class; } sub set_name { my ($self, $name) = @_; $name{$self} = $name; } sub get_name { my ($self) = @_; $name{$self}; } 1; __END__ package Traditional; use strict; use warnings; use InsideOut; our @ISA = qw[InsideOut]; sub new { my $class = shift; bless {}, $class; } sub set_colour { my ($self, $colour) = @_; $self->{colour} = $colour; } sub get_colour { my ($self) = @_; $self->{colour}; } 1; __END__ #!/usr/bin/perl use 5.010; use strict; use warnings; use Traditional; my $obj = Traditional->new; $obj->set_name("NAME"); $obj->set_colour("COLOUR"); say "The name is ", $obj->get_name, " and its colour is ", $obj->get_c +olour; __END__ The name is NAME and its colour is COLOUR
      As you can see, you can inherit from an inside out object, and use tradition hash based objects in the derived class.

        I note that for the simple example there, the methods and variables are completely independent of each other.

        What happens when the child needs to affect the parent's values? I suspect it would be difficult to keep the Traditional child pure in a practical situation, and you'd end up with an inflexible hybrid child, or a significant re-implementation of the parent to handle the Traditional hijinks that ensue when get/set methods are skipped.