Which Perl 5 OO extension can be seen as "standard" (defacto, quasi)?

I

Ilias Lazaridis

I like the very fundamental OO support of Perl 5.

constructs like "separated data/method inheritance", AUTOLOAD, give me
the freedom to implement things as I like: very generic, general and
dynamic.

But as I don't like to "develope away from standard ways to do
things", I've tried to find out which is the OO extension to use with
perl 5.

I've found this very compact one:

http://www.netalive.org/swsu/archives/2004/09/reformed_perl_t.html

but have immediately the problem that "self" is used instead of
"$self" and that it seems that the code adds overhead at execution
time.

Then I've seen Perl6::Bundle which bring Perl 6 stuff to Perl 5

http://www.linux-magazine.com/issue/49/Perl_6_Preview.pdf

but I don't know two things:

* how stable are those implementations?
* how many perl developer do actually use them?
* can I pick just the OO stuff out of the bundle, or are ther
dependencies?
* Is there any document which suggests which modules to use for new
projects?

Any suggestions / comments are welcome.

I summarize all results herein:

http://dev.lazaridis.com/lang/wiki/PerlOO

..
 
M

Michele Dondi

OO support was added in Perl 5. It didn't exist in Perl 4. That is not
my definition of "fundamental". Perhaps you mean "primitive" :)

Yes I think so. In Italian too "fondamentale" can have an acceptation
akin to that one, and a naive translation may be the source for
possible confusion, albeit less so than with other words.
The reform.pm module looks very stable. It was uploaded to CPAN in Sep,
2004 and not updated since.

Or obsolete... (I don't actually know, but that's possible!)


Michele
 
I

Ilias Lazaridis

OO support was added in Perl 5. It didn't exist in Perl 4. That is not
my definition of "fundamental". Perhaps you mean "primitive" :)

No, I meant: it gives me the fundament, on which I can build upon
nicely.

I don't feel it gives me a "basic" or a "primitive' OO support (as I
can
use the fundament to build upon)
You don't need an "OO extension" to do OO programming in Perl. It is
now built into the language.
[...]

of course.

My remarks above subject the build in-support.


[...]
* how stable are those implementations? [...]
* how many perl developer do actually use them? [...]
* can I pick just the OO stuff out of the bundle, or are ther
dependencies? [...]
* Is there any document which suggests which modules to use for new
projects? [...]
Any suggestions / comments are welcome.

I think using any extensions to the language is generally a mistake
[...] - (friendly suggestions and comments, mainly targetting language
beginners)

I summarize from your writings, the there is no OO extension available
which could be seen as a standard.

The build-in OO support of Perl5 is the today's standard.

That's fine for me personally (I alreay enjoy the freedom).

Is there possibly an community agreement on a standard accessor-
extension (e.g. "
if you have to use automated accessor generation, use CPAN::???)

..
 
E

Emmanuel Florac

Le Sat, 16 Jun 2007 22:30:09 +0000, Ilias Lazaridis a écrit :
Is there possibly an community agreement on a standard accessor- extension
(e.g. "
if you have to use automated accessor generation, use CPAN::???)

I don't know for the accessors specifically, but Moose really blows
everything else away IMHO.
 
M

Michele Dondi

I don't feel it gives me a "basic" or a "primitive' OO support (as I
can
use the fundament to build upon)

But it *is* primitive, exactly because of that: but then do not
misunderstand me, I've always been fascinated by the far reaching
consequences of such a simple model. However many feel, and rightly
so, that a more robust, pervasive OO model out of the box in which one
is not forced to build stuff that is also available out of the box in
other languages would be desirable: indeed that's why it's beeing
added to Perl 6.
I summarize from your writings, the there is no OO extension available
which could be seen as a standard.

The build-in OO support of Perl5 is the today's standard.

Yes, it is *the* one and only standard. All of the available modules
which give you bells and whistles build upon that. Talking about them,
anyway... how 'bout Moose?!? (It is not meant as Perl-6-OO-model in
Perl 5 but borrows heavily from the former.)
That's fine for me personally (I alreay enjoy the freedom).

Freedom is fine and all, but don't exaggerate. We recommand daily to
restrict one's own freedom in a useful manner that will help one to
prevent making common programming errors, by using strict and
warnings: with OO programming the situation is different and for the
few things I've ever really needed in that field I also followed the
DIY way, but... well, as a principle a better world should be
possible! ;-)


Michele
 
I

Ilias Lazaridis

[...] - (primitive etc.)
Yes, it is *the* one and only standard.
ok

All of the available modules
which give you bells and whistles build upon that. Talking about them,
anyway... how 'bout Moose?!? (It is not meant as Perl-6-OO-model in
Perl 5 but borrows heavily from the former.)

"Moose Perl 6 OO in Perl 5"
http://svn.pugscode.org/pugs/v6/docs/kp6-Notes.txt
Freedom is fine and all, but don't exaggerate. We recommand daily to
[...]
 
I

Ilias Lazaridis

Le Sat, 16 Jun 2007 22:30:09 +0000, Ilias Lazaridis a écrit :


I don't know for the accessors specifically, but Moose really blows
everything else away IMHO.

* http://search.cpan.org/~stevan/Moose/
* http://search.cpan.org/~stevan/Class-MOP/ Class::MOP

I dislike the verbosity:

has 'x' => (is => 'rw', isa => 'Int');
has 'y' => (is => 'rw', isa => 'Int');

sub clear {
my $self = shift;
$self->x(0);
$self->y(0);
}

But the main question is again:

* how is the adoption of MOP/MOOSE?
* how much are the efforts synchronized with the original perl 6 OO
implementation?

..
 
C

Ch Lamprecht

Ilias said:
I dislike the verbosity:

has 'x' => (is => 'rw', isa => 'Int');
has 'y' => (is => 'rw', isa => 'Int');
You don't need the type constraint here:
has 'x' => (is=>'rw');
has 'y' => (is=>'rw');
If that's still too verbose for you you could wrap &has and make (is=>'rw') default.
 
I

Ilias Lazaridis

Ch Lamprecht :
You don't need the type constraint here:
has 'x' => (is=>'rw');
has 'y' => (is=>'rw');
If that's still too verbose for you you could wrap &has and make (is=>'rw') default.

ok, like this:

hasInt 'x';
has_int 'x';

but most possibly there's a even more elegant way to provide the
default value.

thank's for the clarification.

..
 
M

Michele Dondi

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top