Re: Prevent direct acces to object's attributes

Why would it not be sufficient to just make it clear in your module's POD that direct access to object-internal values is strongly discouraged, and that the get() and set() methods should always be used? Are you really expecting that end-users would deliberately set out to do things that are bad for them?

A common convention that is used to reinforce this "social engineering" aspect of perl 5's OO is to prefix your "internal" variable names with an underscore character ("_atr1", "_atr2", etc).

If you don't have Damian Conway's fine book, Objected Oriented Perl, you should get a copy. Chapter 11, "Encapsulation", explains what you need to know and do to use closures inside your classes so that direct access is effectively ruled out. I'm no expert on this myself, and it would take me a while to demonstrate -- perhaps another monk will step in...

Comment on Re: Prevent direct acces to object's attributes

Replies are listed 'Best First'.
Re^2: Prevent direct acces to object's attributes by almut (Canon) on Sep 07, 2009 at 17:29 UTC
Are you really expecting that end-users would deliberately set out to do things that are bad for them? I guess that's the very personality model that some other languages (e.g. Java) hold of their programmers/end-users... ;)	[reply]
Re^3: Prevent direct acces to object's attributes by CountZero (Bishop) on Sep 07, 2009 at 20:27 UTC
And isn't that exactly why some --such as me-- consider Java to be evil? CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]