4 ms·

Please don't misunderstand my point - I agree with what you were saying and I think Java is far too verbose. I just think by comparing a framework to a language

Please don't misunderstand my point - I agree with what you were saying and I think Java is far too verbose. I just think by comparing a framework to a language you are misrepresenting the capabilities of Perl and the first Java programmer who knows how much of a hack OOP is in Perl could completely tear your post apart. I mean, in Java can you do this? class MyClass { private String foo; public Class(String foo) { this.foo = foo; } } var inst = new MyClass(); inst._foo = 'I just broke your encapsulation.'; Because you can with psuedo-privacy in Perl and Moose. The other thing is that OOP in Perl without Moose is even more verbose than Java. I will never get over having to write my own new subroutine :) P.S. MooseX::Declare absolutely did not compile on Windows last time I tried back in August. When I asked about this on IRC, it was a "known issue."

jrockway 17y ago
Language vs. framework is a meaningless discussion. All languages are frameworks for getting a big chunk of silicon to do stuff. I'm not sure how Perl's OO is a "hack", in my opinion, people that say this only have a superficial understanding of what object-oriented programming is. It's a way to organize code, it's not a way to prevent people from calling methods. Perl's OO is superset of Java's OO. Hack or not, it encourages reuse and modularity, and makes this very easy for the programmer to get right. "private" is one of the worst programming language concepts ever invented. Perl's lack of this bug is a feature. Private methods are nice for documentation purposes, but most developers misuse "protected" and "private", and it makes their libraries nearly impossible to use. In a perfect world; great idea. In the real world; a huge waste of time.
- deleted 17y ago
  [deleted]
- DavidMcLaughlin 17y ago
  Why are private methods good for documentation? They shouldn't even be documented save for inline comments. The whole idea of privacy in my mind is that the only person or people who should know that these functions even exist are those who maintain the class/library/framework. This helps immensely because when you want to refactor you know EXACTLY which method signatures or attributes have to be supported for backward compatibility. You can really keep on top of things, and as long as you took the time to create a flexible API, you can handle change gracefully. I don't even unit test my private methods because I don't even care about them or what they do. I only care that some data is passed to a public API and returns the correct result. They are there, as you say, purely as a means to organise my code. For example, in my last company I wrote this ORM in Moose. I released it. And the guys I was working with just didn't get the concept of Moose. They kept accessing the attributes from the underlying blessed hash like they did before rather than the accessors. It still worked because internally Moose stores stuff the way Conway recommended in OOP Perl (which was a weird decision imho). One day I renamed one of my database columns and so had to rename my accessor and created a manual function that warned of "obselete call to accessor x" whilst returning the new column name... backwards compatibility, yay! But they didn't see this because they didn't use the accessor and now all their manual hash accessing was returning undefined or null or whatever it is. Of course it only took me going over to their table and explaining to them how Moose worked or getting together for a meeting. Fine. But that was a company with a technical team of around 10 people. Now I work for a big tech company, and I'm in charge of a framework again except now its JavaScript which has the same problems when people force this classical inheritance pattern and now when some guy doesn't get it he's in another building or another country and did so in a repository I didn't even know existed and his code that breaks my encapsulation is in a production device and when I refactor my code I have the possibility that I break live code on some project or some device I don't know about. So yeah, privacy is an important concept and if you don't think so I would say it is you who lives in a superficial bubble where everyone who uses your API or works on your code can be trusted to have good sense.
  - jrockway 17y ago
    No programming language will solve the problem of bad programmers. If you can edit the code, private methods provide no protection -- the programmer that wants to get at that functionality will just change it to public and recompile, or worse, cut-n-paste the code into his own module. The enforced privacy, therefore, adds no safety. Not enforcing privacy at least allows you to write a subclass that carefully changes the behavior of the original, at the risk of coupling the subclass to the superclass (but this is better than cut-n-pasting). In an ideal world, you could rewrite every library that was designed incorrectly, but there is not always time for this. Intentionally limiting flexibility ("private") is worse for code reuse than allowing someone to intentionally change internal details. (Which is what privacy prevents.) A good programmer will use his judgment to determine whether to cut-n-paste, subclass, or rewrite. The programming language should not remove options from his toolbox. Now I work for a big tech company, and I'm in charge of a framework again except now its JavaScript which has the same problems when people force this classical inheritance pattern and now when some guy doesn't get it he's in another building or another country and did so in a repository I didn't even know existed and his code that breaks my encapsulation is in a production device and when I refactor my code I have the possibility that I break live code on some project or some device I don't know about. Well, the tests stop passing. The tests are what ensure your code works, not "private" directives. "private" is just documentation that suggests "you probably don't want to call this directly". "Probably." All I can say is that technical solutions to social problems never work. Rewrite your app in Haskell and I guarantee that dumbass developers will still be able to mess up your code. People are much more clever than programming languages.
- axod 17y ago
  private and protected are fantastic for narrowing down bugs, and controlling access. Certainly not a waste of time. In comparison, a looser language like javascript where any code can call any code any time it likes, can be a complete pain to debug.
  - jrockway 17y ago
    It can call any code any time it likes, but it shouldn't. Why do you think you know what the Future User of your class wants to do better than that Future User? In theory, a good library will have a perfect public interface that anticipates every need that the future users will have. "protected" and "private" eliminate many classes of bugs in that case. But in the real world, they just eliminate many classes of features, because they prevent people from using imperfect libraries.
    - axod 17y ago
      I hardly ever use external libraries so luckily don't have that problem, but I don't think it's a widespread issue :/ If you really want access to a private I'm sure you could work out a way. >> "It can call any code any time it likes, but it shouldn't" Sure but it's nice to have a lock on the door that says "I can say with 100% certainty that this code will not be called from anywhere else". That's a pretty useful feature to have.
      - jrockway 17y ago
        Nice for you, but not nice for anyone else.
      - chromatic 17y ago
        That's only a nice feature until you pull out the Decorator or Adapter patterns to get around some class marked `final` in a library somewhere you can't modify and for which you have to appease the type system because classes do not imply interfaces.

jrockway 17y ago

Language vs. framework is a meaningless discussion. All languages are frameworks for getting a big chunk of silicon to do stuff. I'm not sure how Perl's OO is a "hack", in my opinion, people that say this only have a superficial understanding of what object-oriented programming is. It's a way to organize code, it's not a way to prevent people from calling methods. Perl's OO is superset of Java's OO. Hack or not, it encourages reuse and modularity, and makes this very easy for the programmer to get right. "private" is one of the worst programming language concepts ever invented. Perl's lack of this bug is a feature. Private methods are nice for documentation purposes, but most developers misuse "protected" and "private", and it makes their libraries nearly impossible to use. In a perfect world; great idea. In the real world; a huge waste of time.

deleted 17y ago
[deleted]
DavidMcLaughlin 17y ago
Why are private methods good for documentation? They shouldn't even be documented save for inline comments. The whole idea of privacy in my mind is that the only person or people who should know that these functions even exist are those who maintain the class/library/framework. This helps immensely because when you want to refactor you know EXACTLY which method signatures or attributes have to be supported for backward compatibility. You can really keep on top of things, and as long as you took the time to create a flexible API, you can handle change gracefully. I don't even unit test my private methods because I don't even care about them or what they do. I only care that some data is passed to a public API and returns the correct result. They are there, as you say, purely as a means to organise my code. For example, in my last company I wrote this ORM in Moose. I released it. And the guys I was working with just didn't get the concept of Moose. They kept accessing the attributes from the underlying blessed hash like they did before rather than the accessors. It still worked because internally Moose stores stuff the way Conway recommended in OOP Perl (which was a weird decision imho). One day I renamed one of my database columns and so had to rename my accessor and created a manual function that warned of "obselete call to accessor x" whilst returning the new column name... backwards compatibility, yay! But they didn't see this because they didn't use the accessor and now all their manual hash accessing was returning undefined or null or whatever it is. Of course it only took me going over to their table and explaining to them how Moose worked or getting together for a meeting. Fine. But that was a company with a technical team of around 10 people. Now I work for a big tech company, and I'm in charge of a framework again except now its JavaScript which has the same problems when people force this classical inheritance pattern and now when some guy doesn't get it he's in another building or another country and did so in a repository I didn't even know existed and his code that breaks my encapsulation is in a production device and when I refactor my code I have the possibility that I break live code on some project or some device I don't know about. So yeah, privacy is an important concept and if you don't think so I would say it is you who lives in a superficial bubble where everyone who uses your API or works on your code can be trusted to have good sense.
- jrockway 17y ago
  No programming language will solve the problem of bad programmers. If you can edit the code, private methods provide no protection -- the programmer that wants to get at that functionality will just change it to public and recompile, or worse, cut-n-paste the code into his own module. The enforced privacy, therefore, adds no safety. Not enforcing privacy at least allows you to write a subclass that carefully changes the behavior of the original, at the risk of coupling the subclass to the superclass (but this is better than cut-n-pasting). In an ideal world, you could rewrite every library that was designed incorrectly, but there is not always time for this. Intentionally limiting flexibility ("private") is worse for code reuse than allowing someone to intentionally change internal details. (Which is what privacy prevents.) A good programmer will use his judgment to determine whether to cut-n-paste, subclass, or rewrite. The programming language should not remove options from his toolbox. Now I work for a big tech company, and I'm in charge of a framework again except now its JavaScript which has the same problems when people force this classical inheritance pattern and now when some guy doesn't get it he's in another building or another country and did so in a repository I didn't even know existed and his code that breaks my encapsulation is in a production device and when I refactor my code I have the possibility that I break live code on some project or some device I don't know about. Well, the tests stop passing. The tests are what ensure your code works, not "private" directives. "private" is just documentation that suggests "you probably don't want to call this directly". "Probably." All I can say is that technical solutions to social problems never work. Rewrite your app in Haskell and I guarantee that dumbass developers will still be able to mess up your code. People are much more clever than programming languages.
axod 17y ago
private and protected are fantastic for narrowing down bugs, and controlling access. Certainly not a waste of time. In comparison, a looser language like javascript where any code can call any code any time it likes, can be a complete pain to debug.
- jrockway 17y ago
  It can call any code any time it likes, but it shouldn't. Why do you think you know what the Future User of your class wants to do better than that Future User? In theory, a good library will have a perfect public interface that anticipates every need that the future users will have. "protected" and "private" eliminate many classes of bugs in that case. But in the real world, they just eliminate many classes of features, because they prevent people from using imperfect libraries.
  - axod 17y ago
    I hardly ever use external libraries so luckily don't have that problem, but I don't think it's a widespread issue :/ If you really want access to a private I'm sure you could work out a way. >> "It can call any code any time it likes, but it shouldn't" Sure but it's nice to have a lock on the door that says "I can say with 100% certainty that this code will not be called from anywhere else". That's a pretty useful feature to have.
    - jrockway 17y ago
      Nice for you, but not nice for anyone else.
    - chromatic 17y ago
      That's only a nice feature until you pull out the Decorator or Adapter patterns to get around some class marked `final` in a library somewhere you can't modify and for which you have to appease the type system because classes do not imply interfaces.