in reply to Looking for exportable privacy and protection

For a simple implementation of private attributes and methods you could just use lexicals e.g 
my %attributes;
my $method = sub { ... };

[download]
Of course that would mean that any method which uses a 'private' attribute is also a closure, but you're using a recent version of perl right? If you wanted increased readibilty you could use Sub::Lexical (it'll be on CPAN any day now, honest!). Or you could perhaps write your own source filter to provide such syntactical niceties. There's also a bunch of stuff on the monastery about encapsulation and the like.
HTH

_________
broquaint

Replies are listed 'Best First'.
Re: Re: Looking for exportable privacy and protection
by bronto (Priest) on Jul 11, 2002 at 09:47 UTC

    Thanks for your reply, broquaint

    Unfortunately, it was the only one and your pointers didn't give me the information I was looking for.

    The approach in 178518 was quite similar to my "registry" approach: have object variables hidden out of scope. Rather, I found the approach in Attribute::Protected really interesting. It was one of my choices: using subroutine attributes. But I had no idea on how to mark a sub with Private, for example, and make it automatically callable only by the same package. Nor I knew of Attribute::Handlers.

    Ok, now I have a direction for my research. Anyway, I would like some advice on different approaches:

    • a-la-Class::Struct, with exported functions that install accessors by means of eval
    • using subroutine attributes, and perhaps variable attributes (still experimental in 5.8?)
    • installing methods on the fly using AUTOLOAD and *{$AUTOLOAD} = sub { do { this() and that() } } ;
    • ???

    Thanks again

    --bronto

    # Another Perl edition of a song:
# The End, by The Beatles
END {
  $you->take($love) eq $you->made($love) ;
}

[reply]
[d/l]
[select]
      a-la-Class::Struct, with exported functions that install accessors by means of eval
      Perhaps, but Class::Struct may not be the best module to base your OO interface on since it's intent is to implement C structs in Perl. That and eval is evil ;)
      using subroutine attributes, and perhaps variable attributes (still experimental in 5.8?)
      It'd certainly look very nice syntatically, but I believe attributes are still somewhat of a grey area (esp. for variables).
      installing methods on the fly using AUTOLOAD and *{$AUTOLOAD} = sub { do { this() and that() } } ;
      This is certainly a nice way of generating accessor methods if somewhat heavy-handed (*anything* could be an accessor).

      Unfortunately there is a fundamental flaw to this whole approach - it is *impossible* to have truly encapsulated classes in Perl without taking advantage of lexical scoping. So while closures may look like an abberation in your otherwise pristine code, it may be a necessity to achieve your goal of true encapsulation. I think I'll write a meditation on the whole subject of encapsulation in perl in the next week or so.
      HTH

      _________
      broquaint

[reply]
        I think I'll write a meditation on the whole subject of encapsulation in perl in the next week or so.

        Great!!! You already have a ++ for it, and you'll get one from me on this reply as soon as I get my votes back (no votes to give for me today... weird...)

        Ciao!
        --bronto

        # Another Perl edition of a song:
# The End, by The Beatles
END {
  $you->take($love) eq $you->made($love) ;
}

[reply]

In Section Seekers of Perl Wisdom