Re: Perl 5 OOP solutions

in reply to Perl 5 OOP solutions

When someone makes claims that something is a "problem", particularly when they start waving the magic word "solution", it's sometimes insightful to replace "problem" with "possible issue" and then ask:

What evidence has been provided that this is a real issue?
What is the nature of the issue? Who does it affect, how, and when? Is it likely to affect me?
How is the issue mitigated?
Is the cost of the mitigation worth the effort?

In the specific case the visibility of member variables (hash elements) of stock Perl objects, yes, they are visible. Is this a problem? It comes down to a matter of trust. If you trust yourself and your team to not abuse the feature, I'll argue, (based on experience with two substantial perl-based applications, one in the 600KLOC range) that visibility isn't an issue worth the cost of the various workarounds.

If you don't trust your team, then visibility is an issue, but isn't your biggest issue.

YMMV.

Comment on Re: Perl 5 OOP solutions

Replies are listed 'Best First'.
Re^2: Perl 5 OOP solutions by adrianh (Chancellor) on Apr 15, 2006 at 16:36 UTC
In the specific case the visibility of member variables (hash elements) of stock Perl objects, yes, they are visible. Is this a problem? It comes down to a matter of trust. If you trust yourself and your team to not abuse the feature, I'll argue, (based on experience with two substantial perl-based applications, one in the 600KLOC range) that visibility isn't an issue worth the cost of the various workarounds. For me the issue isn't trust. The problems I've had are not due to deliberate fiddling with member variables - they're to do with accidental ones. People having subclasses break when new superclasses are released by different teams because instance variables or private methods clash, etc. So yes, for me, it has occasionally been quite a significant issue - and solutions like Class::InsideOut look like a nice low cost way to avoid it in the future.	[reply]

Replies are listed 'Best First'.

Re^2: Perl 5 OOP solutions
by adrianh (Chancellor) on Apr 15, 2006 at 16:36 UTC

In the specific case the visibility of member variables (hash elements) of stock Perl objects, yes, they are visible. Is this a problem? It comes down to a matter of trust. If you trust yourself and your team to not abuse the feature, I'll argue, (based on experience with two substantial perl-based applications, one in the 600KLOC range) that visibility isn't an issue worth the cost of the various workarounds.

For me the issue isn't trust. The problems I've had are not due to deliberate fiddling with member variables - they're to do with accidental ones. People having subclasses break when new superclasses are released by different teams because instance variables or private methods clash, etc.

So yes, for me, it has occasionally been quite a significant issue - and solutions like Class::InsideOut look like a nice low cost way to avoid it in the future.

[reply]

In Section Seekers of Perl Wisdom