OO is already becoming a core feature of Perl. And this is a new programming language called Perl 6.
There is no advantage to crippling Perl by forcing OO on everything.
« Forcing OO on everything » is not in the Perl culture. Perl is not Java. Perl has instead a strong culture of mixing programming paradigms (« There is more than one way to do it ») and this is preserved in Perl 6, improving the support for existing ones, and adding more (such as parallel processing).
]]>@Stevan Little -- see above comment about OO fanatics insisting that OO be use for everything.
@Olivier Mengué -- You will note how popular Perl 6 is.
]]>This "if OO will be easy and integral, people will force it upon me everywhere, all the time" claim is not just silly, but it's absurd and unfounded. It's actually just FUD.
Toby pointed at the bless mechanism, which people don't force upon everything.
Preventing a modern feature because someone might ask you to use it when you don't want to is a terrible reason not to do it. It's fucking 2013, the Fortran people are laughing at us.
]]>This is Perl after all, TIMTOWTDI will **ALWAYS** be the core of the language.
]]>That is not simple?
]]>1) It confuses class methods and instance methods by having &new in the same namespace as other methods.
2) It accepts anything you give it for attribute values with no checking at all. Even if you don't want that strictness, it still loses out on self-documentation, meaning, I have no idea what your expected attributes are.
3) While it sort of handles inheritance by allowing #2, it does not handle object initialization at all (and every subclass that is made will have to handle it explicitly (and hopefully they will all do it right way)).
4) Classes share the same namespace as a package, this means imported utility functions can be called as methods even if they make no sense to be called as such.
5) Methods are just subroutines, they only differ in the way that they are called (and can be called either way).
6) Inheritance is defined by populating a specifically named package variable with a string which will, at runtime, be looked up to find if it corresponds to another package that has been loaded.
7) The instance structure itself is indistinguishable from (and has the same interface as) a non-instance HASH reference, meaning it can be easily be mistaken as such and have it's encapsulation violated.
Now, don't get me wrong, I believe there is an elegant simplicity to Perl's OO system. That said, it simply requires too much boilerplate to just get off the ground, much less use on a reasonable scale. The fact is that you are missing a lot in your example, the full version would look like this:
package Foo;
use strict;
use warnings;
sub new {
my $class = shift @_;
my $self = { @_ };
bless $self, $class;
}
Whereas I am proposing that you instead would just have to write this:
class Foo {}
It refers to the Weakly typed languages article, and looks interesting in that it gives the language typing debate a much practical value, through a real world example.
The only caveat is that it is written in Swedish and only the abstract is in English; so if anybody finds it interesting and knows Swedish then I would much appreciate a translated overview!
OO is in core Perl: bless is in the core, unless I am mistaken;
'This "if OO will be easy and integral, people will force it upon me everywhere, all the time" claim is not just silly, but it's absurd and unfounded. It's actually just FUD.'
OO is easy and integral in Perl already, and is forced upon us everywhere, whether it makes sense or not, but it is our duty to resist such pressures when we think it does not make sense :); crippling Perl for this reason does not make sense, though it might make sense to mark the new OOP schemes as "experimental" for a couple of releases after they get in the official core.
]]>I had not heard the term until Jean-Damien used it., but Wikipedia has a good article on it:http://en.wikipedia.org/wiki/Source-to-source_compiler. I like the term very much and find it fills a true need. In describing the kind of work people are doing with Marpa, I've had trouble -- "compiler" suggests something that not only parses and produces another useable format, but also takes the original language down to the hardware level. I like to point out the great things being done with Marpa, but I also try to avoid exaggeration, and if you say "Marpa allows you to produce compilers easily and quickly", it suggests that Marpa makes it easy to write another GCC. I believe Marpa would make writing another GCC considerably easier, but to write a full compiler like GCC you have to solve a whole lot of problems that Marpa does not even begin to address.
The distinction between "compilers", which take the language a major distance down toward the metal, and "transpilers", which convert the languages at the same level of abstraction is extremely significant in theory and in practice. Having a word for it makes it easier to talk about it.
]]>Weird->can("foo")
as an indicator of whether the Weird
package loaded successfully.]]>
That's part of the reason I advocate simply to use a module instead of use_ok, and with dying on test failure, you have another stopgap measure to help trap that (the latter argument being less persuasive, I admit).
]]>use_ok()
before I continue. :)]]>
See this pseudo-code where the "run" function dies on all errors:
lives_ok { run("mount server:/abc /mnt/abc") "Mounting";
lives_ok { run("dd if=/dev/zero of=/mnt/abc/file count=1M") } "dd";
This will still run the dd and only abort after that. I haven't figured out a good way to deal with that except for adding an "or die ..." after every critical test.
]]>See this pseudo-code where the "run" function dies on all errors:
lives_ok { run("mount server:/abc /mnt/abc") "Mounting";
lives_ok { run("dd if=/dev/zero of=/mnt/abc/file count=1M") } "dd";
This will still run the dd and only abort after that. I haven't figured out a good way to deal with that except for adding an "or die ..." after every critical test.
]]>