•Re: Filtering access to an Objects functions

If you want Java or C++, you know where to find them. Perl takes a different approach by default. Says the manpage:

Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun.

While you can build code that would reject arbitrary method calls depending on filename, location, superclass, or secret handshake, the moment I got your code I would rip all of that stuff back out.

So, please, don't do that. It hurts.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

Comment on •Re: Filtering access to an Objects functions

Replies are listed 'Best First'.
Re: •Re: Filtering access to an Objects functions by chromatic (Archbishop) on Feb 08, 2003 at 01:44 UTC
I've actually done that for (what I consider to be) a good reason: access controls on objects accessible via SOAP::Lite. In this case, I build a proxy object. All of my accessable methods had sub attributes that gave the permissions they needed and I added authentication tokens used to identify users through sessions. More details in my journal.	[reply]
Re^2: Filtering access to an Objects functions by adrianh (Chancellor) on Feb 07, 2003 at 21:34 UTC
So, please, don't do that. It hurts. Slightly unfair - since we don't know why it's needed. I can think of sensible reasons for doing this sort of thing. For example, I've done something similar when I have had a Template Toolkit based system with "user" and "admin" views of the same structures. To prevent "user" templates being able to do "admin" things by accident I created separate Admin and User classes that delegated a suitable subset of methods to the underlying object. By only supplying the appropriate plugins to the appropriate templates I get a far safer system and can let the designers go play with the templates without a care in the world.	[reply]