Re^4: Closure objects with public, private, and protected fields

My point is that if you use anything but the publicly defined interface, you take your life into your own hands. Make the interface to each class clean and you don't have to worry about breaking people that don't use it. I don't feel bad if I break the code of someone who relied on a non-public interface to one of my classes. Some people don't understand that you don't need things like protected or private.

As an aside, the openness or closedness of the source has little to do with this conversation. There are plenty of open source Java programs that must implement the class control mechanisms mentioned above because that's the way that that language works. In its current incarnation, Perl has no such notions.

thor

The only easy day was yesterday

Comment on Re^4: Closure objects with public, private, and protected fields

Replies are listed 'Best First'.
Re^5: Closure objects with public, private, and protected fields by adrianh (Chancellor) on Mar 06, 2006 at 23:58 UTC
My point is that if you use anything but the publicly defined interface, you take your life into your own hands. Make the interface to each class clean and you don't have to worry about breaking people that don't use it. I don't feel bad if I break the code of someone who relied on a non-public interface to one of my classes. Some people don't understand that you don't need things like protected or private. Well, that depends on your definition of need. While the _private_method naming convention is a nice signal to the reader that this particular subroutine is not part of the public API, it doesn't help with encapsulation. See Re^2: characterstics of private in perl and Re^4: Encapsulation through stringification - a variation on flyweight objects for some examples of where this sort of encapsulation problem can cause problems for people who are not deliberately poking at things they shouldn't be. Sure they can go poke at the source and figure out the problem. But wouldn't it be nicer if the language stopped it happening in the first place? (and of course this need not stop people being able to poke into the innards if they want to - just provide a separate syntax.)	[reply]

Replies are listed 'Best First'.

Re^5: Closure objects with public, private, and protected fields
by adrianh (Chancellor) on Mar 06, 2006 at 23:58 UTC

My point is that if you use anything but the publicly defined interface, you take your life into your own hands. Make the interface to each class clean and you don't have to worry about breaking people that don't use it. I don't feel bad if I break the code of someone who relied on a non-public interface to one of my classes. Some people don't understand that you don't need things like protected or private.

Well, that depends on your definition of need.

While the _private_method naming convention is a nice signal to the reader that this particular subroutine is not part of the public API, it doesn't help with encapsulation. See Re^2: characterstics of private in perl and Re^4: Encapsulation through stringification - a variation on flyweight objects for some examples of where this sort of encapsulation problem can cause problems for people who are not deliberately poking at things they shouldn't be.

Sure they can go poke at the source and figure out the problem. But wouldn't it be nicer if the language stopped it happening in the first place?

(and of course this need not stop people being able to poke into the innards if they want to - just provide a separate syntax.)

[reply]