3 ms·

I completely agree with the point you are making about accessors, but something I don't agree with is the way you made your point: > In Perl, I can just say:

I completely agree with the point you are making about accessors, but something I don't agree with is the way you made your point: > In Perl, I can just say: Moose is an OOP framework built on top of Perl, comparing it to out-of-the-box Java code is quite misleading and I'm not sure what point it proves? It's like saying MVC in PHP is verbose compared to Django or Rails rather than Python or Ruby. Using MooseX::Declare is even more misleading. Does that even work on Windows yet?

jrockway 17y ago
Build a sane framework on top of Java, and you can use that for comparisons. MooseX::Declare has always worked on Windows. If you can compile Perl, you can compile Devel::Declare. Regardless, MooseX::Declare does not change the verbosity of the code: use MooseX::Declare; class Foo { has 'bar' => ( is => 'ro' ); } package Foo; use Moose; has 'bar' => (is => 'ro'); The MX::D version is one line longer :P.
- DavidMcLaughlin 17y ago
  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.
mechanical_fish 17y ago
So you're saying that the argument would work better if the examples were in Ruby? At first glance, I'd say they would translate quite easily into idiomatic Ruby. jrockway is a Perl programmer; he writes in the language he knows. And if you object to comparing against "out-of-the-box" Java code, that's fine. My understanding is that there are, in fact, JVM-based tools that let you write code in the approximate style of Moose. The only stumbling block is that these tools are called "JRuby" or "Clojure", and the average Java programmer doesn't know or recognize them. [1] Certainly they make no appearance at all in the original article. --- [1] Or maybe my impression is wrong and one or another of the alternative JVM languages really is on track for widespread recognition. I wouldn't know.

jrockway 17y ago

Build a sane framework on top of Java, and you can use that for comparisons. MooseX::Declare has always worked on Windows. If you can compile Perl, you can compile Devel::Declare. Regardless, MooseX::Declare does not change the verbosity of the code: use MooseX::Declare; class Foo { has 'bar' => ( is => 'ro' ); } package Foo; use Moose; has 'bar' => (is => 'ro'); The MX::D version is one line longer :P.

DavidMcLaughlin 17y ago
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.

mechanical_fish 17y ago

So you're saying that the argument would work better if the examples were in Ruby? At first glance, I'd say they would translate quite easily into idiomatic Ruby. jrockway is a Perl programmer; he writes in the language he knows. And if you object to comparing against "out-of-the-box" Java code, that's fine. My understanding is that there are, in fact, JVM-based tools that let you write code in the approximate style of Moose. The only stumbling block is that these tools are called "JRuby" or "Clojure", and the average Java programmer doesn't know or recognize them. [1] Certainly they make no appearance at all in the original article. --- [1] Or maybe my impression is wrong and one or another of the alternative JVM languages really is on track for widespread recognition. I wouldn't know.