Re: What if Perl had an OO standard library?

Venus is a rich demonstration that it is possible to implement "Everything is an object" in Perl. But honestly, I doubt that it is much more than that.

Objectification of arrays and hashes makes it look like Java, which isn't bad, but no particular benefit either. It gets weird when primitives like numbers and strings are objectified. Venus::Number objects can, thanks to overload, be manipulated with the usual arithmetic operators. However, as soon as I apply an arithmetic operator on a Venus number, the result loses its object properties and is just a plain number. There are no methods like $one->add($two) which would allow to return new Venus::Number objects.

Here's some experiments I ran. Some results weren't as I expected.

use 5.028;
use Venus qw(catch);
use Venus::Number;
my $one = Venus::Number->new(1);
my $two = Venus::Number->new(2);

say "one = ", $one;
# one = 1

say "one = $one";
# Argument "one = " isn't numeric in addition (+) ....
# 10     <---- Venus::Number objects don't interpolate

print "two = ";
$two->print_string;
print "\n";
# two = 2 <--- Methods don't interpolate either

# Arithmetics 
my $three = $one + $two;

say "three = ", $three;
# three = 3 <---- Now it does interpolate

print "three = ";
$three->print_string;
print "\n";
# Can't locate object method "print" via package "3"
#           <---- but has lost its blessing

# Strings
use Venus::String;
my $just    = Venus::String->new('Just');
my $another = Venus::String->new('another');
my $perl    = Venus::String->new('Perl');
my $hacker  = Venus::String->new('hacker');
say "$just $another $perl $hacker";
# ----> hackerPerlanotherJust
[download]

Comment on Re: What if Perl had an OO standard library? Download Code

Replies are listed 'Best First'.
Re^2: What if Perl had an OO standard library? by awncorp (Acolyte) on Aug 24, 2022 at 03:25 UTC
Thanks for your feedback. It's much appreciated. While I understand your perspective I maintain a difference of opinion. For example: Your take: "it is possible to implement "everything is an object" in Perl ... which isn't bad, but no particular benefit either" My take: You're right to call out that this is a move towards "everything is an object" in Perl. As mentioned in another comment/reply, "the lack of a native type system means that your classes and methods can’t be certain of the type of data they’re being passed, which forces you into a position of defensive programming". Your observation: "Venus::Number objects can, thanks to overload, be manipulated with the usual arithmetic operators. However, as soon as I apply an arithmetic operator on a Venus number, the result loses its object properties and is just a plain number." My response: You're correct and this is intentional. All value class methods, intentionally, return native data types. I refer to this in the article under "guiding principles" where I state that "the library should ease the multi-paradigm identity crisis" and "be a compliment, not a cudgel", i.e. if I'm using Venus and (in a particular context) I only want to leverage the Venus::Array#any algorithm (e.g. `Venus::Array->new([1..8])->any(sub{$_ > 5})`) I can use that and have the result be a basic arrayref, OR, if I want to opt-into "everything is an object" and chaining method calls via autoboxing I can do that easily too (e.g. `Venus::Array->new([1..8])->box->any(sub{$_ > 5})->count->unbox`). P.s. Thanks again for the great feedback. Based on it I'll be adding the simple math routines to the Number class in an upcoming release, as well as fixing the string interpolation bug. "I am inevitable." - Thanos	[reply] [d/l] [select]
Re^3: What if Perl had an OO standard library? by haj (Vicar) on Aug 25, 2022 at 12:29 UTC
the lack of a native type system means that your classes and methods can’t be certain of the type of data they’re being passed, which forces you into a position of defensive programming Well, in my view Perl does never force me into any position, but, depending on the task, defensive programming is recommended. Using objects as a surrogate for a type system is just a thin layer. For safety, this only helps if the classes do the appropriate validations on object creation. For example, Venus::Number accepts any value, so my classes and methods still can't be certain of the type of data they're being passed: `use 5.028; use warnings; use Venus::Number; use File::Temp; my $n; # These two come with warnings say Venus::Number->new($n); # '' say Venus::Number->new($n,$n); # 0 $n = 1; say Venus::Number->new($n); # 1 $n = "abc"; say Venus::Number->new($n); # abc $n = [3,2,1]; say Venus::Number->new($n); # ARRAY(0x...) say Venus::Number->new($n)->abs; # 94653281131368 $n = File::Temp->new; say Venus::Number->new($n); # /tmp/ER2Mi14BOz` [download]	[reply] [d/l]
Re^4: What if Perl had an OO standard library? by awncorp (Acolyte) on Aug 31, 2022 at 23:35 UTC
Thanks for the feedback. I don't mean to be argumentative but if you write a Perl subroutine expecting a certain type of data (say a hashref), how do you handle the case where the routine is called with something else (say an integer). As far as I can tell you only have two options: i.e. yolo! and let it crash, or try to do some simple sanity checking. The simple sanity checking is defensive programming (and you're forced to do it (or at the very least, coerced)). The most recent release of Venus, v1.30, ships with a simple type assertion framework that all standard library classes utilize via the "make" method. The new method still allows value classes to accept bad values, intentionally. The idea is that "make" is useful in situations where you're unsure about the data being submitted. Obvisouly "make" (e.g. new w/type checking) is not as performant as "new". `Venus::Number->make; # Exception! Venus::Number->make(0,0); # bless(..., "Venus::Number") Venus::Number->make(1); # bless(..., "Venus::Number") Venus::Number->make('abc'); # Exception! Venus::Number->new([3,2,1]); # Exception! Venus::Number->new([3,2,1])->abs; # Exception!` [download] "I am inevitable." - Thanos	[reply] [d/l]


Just another Perl shrine
	PerlMonks