OO systems and Perl 5 (Was: Recap: Future of Perl 5)

Ovid's Recap: The Future of Perl 5 got me curious, so I did some searching and found something interesting.

Object creation in Perl compared to Smalltalk (the putative parent language of OO languages): They are surprisingly similar.

Using Ovid's Point example, in Smalltalk:

Object subclass: 'Point' instanceVariables: 'x y '

x
 ^x

x: coord
 x := coord

y
 ^y

y: coord
 y := coord

init
 x := Float new.
 y := Float new.
[download]

Then to create an instance:

p := Point new.
p init.
p x: 1.5.
p y: 1.5.
[download]

Doesn't that look a lot like:

my $p = bless {}, Point;
$p->init;
$p->x(1.5);
$p->y(1.5);
[download]

For a friendlier object creation, you can define a class method to do all that:

newX: xc Y: yc
 p := Point new.
 p init.
 p x: xc.
 p y: yc.
 ^p
[download]

Then:

Point newX: 1.5 Y: 1.5.
[download]

Also, Smalltalk's new is a method inherited from the Object class and can be overridden by defining a new method as a class method of any user defined class. I'm leaving that as exercise for the readers.

So, maybe Perl 5's much maligned OO system can be blamed on Smalltalk. Not sure what else Larry et al had available to look at, but looks like Smalltalk had a strong influence.

Still, there is hope for Perl 5's OO system.

For those who've forgotten or are not familiar, Perl 5 has an equivalent to Object called UNIVERSAL. All classes in Perl 5 inherit from UNIVERSAL.

In theory, Perl 5 could provide a default new method for all classes by defining a new method in UNIVERSAL.pm

Maybe Ovid can present a compelling enough argument to do that. That would be a great first step.

But, since I'm writing this comment, I'll suggest 2 additions to UNIVERSAL.pm

sub init
{
    # Nothing to do, this is just here so classes don't have to define
+ init
}

sub new
{
    my $class = shift;
    my $object = bless {}, $class;
    $object->init(@_);
    return $object;
}
[download]

I'm sure someone will come up with a better default new. This one is just an example of what could be done.

Disclaimer: None of this code is tested. YMMV

Comment on OO systems and Perl 5 (Was: Recap: Future of Perl 5) Select or Download Code

Replies are listed 'Best First'.
Re: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by tobyink (Canon) on Aug 29, 2018 at 02:01 UTC
That's pretty much what UNIVERSAL::Object aims to do, but uses UNIVERSAL::Object::new instead of UNIVERSAL::new. Probably pretty easy to do something like: `push @UNIVERSAL::ISA, 'UNIVERSAL::Object';` [download] toby döt ink	[reply] [d/l]
Re^2: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by RonW (Parson) on Aug 29, 2018 at 23:31 UTC
Certainly a very interesting project. The advantage of UNIVERSAL::new would be that UNIVERSAL is automatically `use`d. Of course, that leaves the task of actually getting anything added to UNIVERSAL.pm. From the comments in the file, it seems that a lot has already been removed from it and some people want to remove more from it.	[reply] [d/l]
Re^3: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by tobyink (Canon) on Aug 30, 2018 at 07:57 UTC
UNIVERSAL.pm itself is not so important. It's mostly just documentation. The guts of the UNIVERSAL package (UNIVERSAL::can, UNIVERSAL::isa, UNIVERSAL::DOES) are hard-coded into Perl, not part of a module. The disadvantage of having UNIVERSAL::new is that all packages automatically inherit from UNIVERSAL; even ones not designed to be used as classes. How much sense do things like this make? `use strict; my $thing = strict->new;` [download] A whole lot of modules would need to add code like this to them: `sub new { # override UNIVERSAL::new require Carp; Carp::croak("$_[0] is not a class"); }` [download] toby döt ink	[reply] [d/l] [select]
Re^4: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by RonW (Parson) on Aug 31, 2018 at 00:11 UTC
Re^5: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by LanX (Sage) on Aug 31, 2018 at 01:44 UTC
Re: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by LanX (Sage) on Aug 29, 2018 at 00:57 UTC
> Not sure what else Larry et al had available to look at, IIRC was it Python, and he said he repented it. edit Larry Wall's 11th State of The Onion: I don't really know much about Python. I only stole its object system for Perl 5. I have since repented. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^2: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by eyepopslikeamosquito (Bishop) on Aug 29, 2018 at 04:35 UTC
Yeah, this was discussed recently by you and I in a reply (Re^7: Curious about Perl's strengths in 2018) to the original discussion posted by Crosis. There were a lot of interesting topics discussed in this long (and at times meandering) discussion thread.	[reply]
Re^2: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by RonW (Parson) on Aug 29, 2018 at 23:09 UTC
Apparently, someone in the Python project did some repenting, too. The Python 3 (and, it seems, Python 2) OO system appears to have been redone since Larry stole from Python. (see https://realpython.com/python3-object-oriented-programming/)	[reply]
Re^3: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by LanX (Sage) on Aug 30, 2018 at 00:05 UTC
What exactly? ? ? update I read all of it and this is semantically almost identical. Larry just reused `package` for `class` ° and added more freedom: you can choose the name of your constructor(s) (usuall new) you can bless any reference as instance container not only hashes you won't have collisions between methods and instance vars class attributes don't collide with object attributes Actually you can translate this whole tutorial almost 1-to-1 with a bit of syntactic sugar! Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice} °) python doesn't seem to have anything like a package keyword	[reply] [d/l] [select]
Re^4: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by RonW (Parson) on Aug 31, 2018 at 00:04 UTC
Re^5: OO systems and Perl 5 (updated) by LanX (Sage) on Aug 31, 2018 at 01:15 UTC
Some notes below your chosen depth have not been shown here
Re: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by LanX (Sage) on Aug 29, 2018 at 14:43 UTC
I don't consider me an expert in OO beyond standard perldocs ... ... but from a strategic POV all remodeling in P5 should try to stay as close as possible to the semantics of P6. (NB: semantic != syntax) Any divergence should have good reasons. Why? Much thoughts were already invested in designing P6, so why reinvent the brain wheels? We should facilitate a later migration We could profit from synergies in later development. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]
Re^2: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by chromatic (Archbishop) on Aug 29, 2018 at 18:04 UTC
Any divergence should have good reasons. To expand on my comment in Re^5: Recap: The Future of Perl 5, any of the P6 OO semantics which assume stronger type guarantees and identities will be troublesome to implement in Perl. Smartmatch is the best example of that, but type coercions will also be interesting (and not in the fun way).	[reply]
Re^3: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by LanX (Sage) on Aug 29, 2018 at 18:21 UTC
Not sure what type indenties mean°, but stronger type guarantees could at least happen at runtime, or am I missing something? Perl 5 already allows to define a type in declarations (see `my` ) but alas it's only (mostly) a placebo. Would be interesting to know what the plan was... Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice} update °) you probably mean what JS is handling by the difference between `==` and `===` ?	[reply] [d/l] [select]
Re^2: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by RonW (Parson) on Aug 29, 2018 at 23:01 UTC
A suitable implementation of UNIVERSAL::new could provide similar default behavior to Perl 6's new. So could a suitable implementation of UNIVERSAL::init - and would be more friendly to "immigrants" from other languages' OO systems - Class::init will be called with an already blessed object, so will only need to perform initializations (and, maybe, validate supplied parameters). (Not surprisingly, overriding new in Perl 6 requires the new class's new method to use bless to create the new object.)	[reply]
Re^3: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by LanX (Sage) on Aug 30, 2018 at 00:56 UTC
Unfortunately ammending UNIVERSAL will certainly break some CPAN modules. Just imagine packages trying to catch `new` in AUTOLOAD. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply] [d/l]
Re^4: OO systems and Perl 5 (Was: Recap: Future of Perl 5) by RonW (Parson) on Aug 31, 2018 at 00:07 UTC


Keep It Simple, Stupid
	PerlMonks

OO systems and Perl 5 (Was: Recap: Future of Perl 5)

edit

update

update