Re^4: Recap: The Future of Perl 5

[haj]

I'd be quite fine with eleven different opinions on how Str should be implemented. The Perl developers should then talk to each other, look for a consensus and make this the way it is done.

It is the subtle differences between Perl's (CPAN) object systems which drives me nuts, not the individual behaviour of any of these systems. I can live just fine with any of them, but having more than one in a project, which is inevitable for bigger projects, hurts.

[hippo]

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.

[tobyink]

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.