Re5: Encapsulation through stringification - a variation on flyweight objects

Let me get this straight: The basic concern with the lack of truly private attributes/methods has to do with the fact that you may only want to inherit the interface, not the object implementation. You want to know that "I am a Foo" and "Foos can bark", so "I can bark" and not have to think anymore about it. Plus, you want to know that by using Foo's capability to bark, you have not harmed your capability to develop any which way you want.

Does that accurately sum it up?

------
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.

Comment on Re5: Encapsulation through stringification - a variation on flyweight objects

Replies are listed 'Best First'.
Re^6: Encapsulation through stringification - a variation on flyweight objects by adrianh (Chancellor) on Apr 03, 2003 at 15:59 UTC
Pretty much. It might be useful to separate out the concepts of encapsulation and data-hiding. A package global variable is encapsulated within it's package (declaring `$Foo::fribble` does not interfere with `$Bar::fribble`), but it's not hidden (you can access `$Foo::fribble` from the Bar package by explicitly stating the package name). Contrast this with a lexical variable which is both encapsulated within its scope and `hidden` from other code (ignoring closures and PadWalker :-) Language support for the encapsulation of class state and behaviour is, for me, the big lack in perl5 OO. Using the default perl OO style of key/value pairs in a hashref to represent an objects state gives you a single namespace for attributes across all the classes that the object belongs to. The same applies to methods. Using the normal `$self->method` style means you have a single namespace for methods across all the classes the object belongs to. They are not encapsulated. Imagine having to develop functional/procedural perl modules without packages. You would have to make sure that every module used different subroutine names and different global variables. While the situation isn't so desperate in the perl5 OO world, because deep inheritence hierarchies are rare, it can still be a problem. In perl5 you cannot encapsulate the implementation details of your class from its public interface easily - its complex (e.g. lexical closures), non-obvious (e.g. inside out objects) and can involve a lot of developer overhead (e.g. prefixing all attributes with the package name and remembering to call all private methods as subroutines). This is why I'm looking forward to things like submethods in perl6 ;-)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^6: Encapsulation through stringification - a variation on flyweight objects
by adrianh (Chancellor) on Apr 03, 2003 at 15:59 UTC

Pretty much.

It might be useful to separate out the concepts of encapsulation and data-hiding.

A package global variable is encapsulated within it's package (declaring $Foo::fribble does not interfere with $Bar::fribble), but it's not hidden (you can access $Foo::fribble from the Bar package by explicitly stating the package name).

Contrast this with a lexical variable which is both encapsulated within its scope and hidden from other code (ignoring closures and PadWalker :-)

Language support for the encapsulation of class state and behaviour is, for me, the big lack in perl5 OO.

Using the default perl OO style of key/value pairs in a hashref to represent an objects state gives you a single namespace for attributes across all the classes that the object belongs to. The same applies to methods. Using the normal $self->method style means you have a single namespace for methods across all the classes the object belongs to. They are not encapsulated.

Imagine having to develop functional/procedural perl modules without packages. You would have to make sure that every module used different subroutine names and different global variables. While the situation isn't so desperate in the perl5 OO world, because deep inheritence hierarchies are rare, it can still be a problem.

In perl5 you cannot encapsulate the implementation details of your class from its public interface easily - its complex (e.g. lexical closures), non-obvious (e.g. inside out objects) and can involve a lot of developer overhead (e.g. prefixing all attributes with the package name and remembering to call all private methods as subroutines).

This is why I'm looking forward to things like submethods in perl6 ;-)

[reply]
[d/l]
[select]