Re^5: Recap: The Future of Perl 5

The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

Agreed. And since there are already multiple competing modules to handle type constraints and OO in general any Perl programmer could happily ignore anything added to the language and continue to use their existing favourite module because TIMTOWTDI.

having more than one in a project, which is inevitable for bigger projects, hurts.

Ain't that the truth. It certainly looks like that particular horse has long since bolted, unfortunately.

Comment on Re^5: Recap: The Future of Perl 5

Replies are listed 'Best First'.

Re^6: Recap: The Future of Perl 5
by tobyink (Canon) on Aug 24, 2018 at 13:12 UTC

since there are already multiple competing modules to handle type constraints and OO in general

My main point is that Perl should provide an API for those existing competing modules to hook into the same syntactic sugar within a particular scope. I don't have any problem with there being a core way and alternatives on CPAN.

The choice is there being multiple type constraint systems which each have their own syntax, or multiple type constraint systems which at least can take advantage of a common syntax.

Like how Moose, Mouse, Moo, and hand-crafted classes can all use ClassName->new(%params) as their constructor. You can write your constructor differently, like ClassName::get_factory(parameters => \%params)->new_object() but except in unusual circumstances, most people would prefer to ease cognitive load by using the common pattern.

toby döt ink

[reply]
[d/l]
[select]


laziness, impatience, and hubris
	PerlMonks