in reply to Re3: Encapsulation through stringification - a variation on flyweight objects
in thread Encapsulation through stringification - a variation on flyweight objects

package Foo;

sub new {return bless {} => shift}
sub oogle {my $shelf = shift; $self -> {key} = shift}


package Bar;
our @ISA = qw /Foo/;

sub gurgle {my $self = shift; $self -> {key} = shift;}

[download]

Both Bar and Foo happen to use the same key, because there's no encapsulation.

Perl na(t)ive OO model stinks, because you've to work hard to get encapsulation. (Note: I'm not saying I want private stuff, I just want encapsulation of the implementation). I do not know a common language whose OO model sucks more than Perls.

Abigail

Replies are listed 'Best First'.
Re5: Encapsulation through stringification - a variation on flyweight objects
by dragonchild (Archbishop) on Apr 02, 2003 at 16:02 UTC
    Ok. I'm missing something when it comes to encapsulation. Why on earth would you want to prevent Bar from accessing attributes it inherited from Foo? That's always been something I didn't understand in C++ - why private attributes were not inherited ...

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]
      I don't know about your coding style, but I prefer to use namespaces and lexically scoped variables, to avoid ACCIDENTAL cluttering of values.

      But I concur. The entire concept of namespaces and lexical variables is just stupid. We should just put all our variables and subs in the main namespace.

      Abigail

[reply]

In Section Meditations