Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?

Replies are listed 'Best First'.
Re^2: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by afoken (Chancellor) on Oct 15, 2019 at 21:45 UTC
Why switch from 5 zto 7 when we can switch to Perl 32, much like Java did? Perl 32 sounds like Perl for old 32-bit processors. "Where is the 64 bit Perl edition?" Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]
Re^3: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by Bod (Parson) on Jan 10, 2024 at 23:08 UTC
Perl 32 sounds like Perl for old 32-bit processors If I had seen this back in 2019 I would have suggested that it won't be long before Perl passes through the magic number 32...of course, now it has and this is no longer a concern.	[reply]
Re^2: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by haukex (Archbishop) on Oct 14, 2019 at 15:04 UTC
Why switch from 5 zto 7 when we can switch to Perl 32, much like Java did? Sure, that's a possibility. I guess my post is more about the features than the version numbering. OTOH, many versioning schemes will only switch major version numbers for major features, and so I was thinking the other way around: if Perl 5 wanted to go to Perl 7, what features would warrant that? As kind of a motivation to get those features out of experimental status `:-)` As for the "batteries included", I think a `Perl::BatteriesIncluded` module is a nice idea. Although I included that point somewhat reluctantly, since of course people will have different ideas for what their favorite bundle is, I think that giving new users of the language a set of proven modules to start with is a good idea. ("What do you mean, I have to download and install a bunch of modules just to do OO?") I.e. for newbies, TIMTOWTDIBSCINABTE...	[reply] [d/l] [select]
Re^2: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by tobyink (Canon) on Oct 14, 2019 at 14:57 UTC
There's Task::Kensho. toby döt ink	[reply]
Re^2: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by 1nickt (Canon) on Oct 15, 2019 at 01:25 UTC
I don't get why you dislike Moo, but anyway have you tried Method::Signatures for signatures including named params, and constraints? It's quite powerful. The way forward always starts with a minimal test.	[reply]
Re^3: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by Corion (Patriarch) on Oct 15, 2019 at 15:42 UTC
I don't dislike Moo in the general sense, but more my (and my perceived) use of it, as it leads often to craete glorified hashes. Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors. If Perl had "better" parameter parsing, I can imagine Moo not being necessary, especially as Moo creates an accessor for everything even if what I really wanted was a named parameter in the constructor. Tadeusz put this into words far better than I can in How Moose Made Me a Bad OO Programmer.	[reply]
Re^4: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by haj (Vicar) on Oct 15, 2019 at 17:53 UTC
Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors. From my own practice, I can't confirm this (and I also heavily disagree with Tadeusz on the topic). When working with my old Moo(se) code, I find it very helpful that the modules have a clear optical distinction between the dumb data (the `has ()` stuff) and the object methods which actually do things (the `sub foo { ...; }` things). Maintaining that distinction without Moo(se) needs more discipline than I usually have during my hacking nights. There is some truth in this if the objects are mainly just dumb data containers which don't have methods beyond the accessors. Not having to write code for these is a nice benefit, but you may put this into the category "fancy helpers for constructors". I find these container objects a lot when working with database-heavy stuff. And if the other side is a web application, decent parameter validation makes sense. I'm using other fancy helpers for constructors like coercion and `BUILDARGS` almost exclusively when I want to retain the API from a non-Moose constructor to avoid version dependencies. On the other hand, I have programs where attributes and accessors are almost exclusively used from within the module itself and external uses are through "higher level" functions. For such programs, object inheritance with its method modifiers and in particular roles play a much greater role than the constructor which in itself sometimes is used only internally, exposing factory functions to the outside. Users of these modules (well, mostly I myself) don't even need to know the attributes, but as a developer I'm happy to have them around for debugging.	[reply]
Re^4: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by 1nickt (Canon) on Oct 15, 2019 at 16:57 UTC
Hm, I am not a student of OOP theory, but I find that "most of what Moo faciliates" is not so much in the instance constructor but in attribute declarations, of which I typically have many times more than constructor params. I find that triggers, clearers, predicates and lazy builders etc. are among the main features of the framework, and they are for all attributes declared. I don't normally find a problem with having a RO "accessor" derived from declaring an attribute in order to take a named constructor param, but if you really don't want its value to be available to consumers you could maybe do something with `BUILDARGS`? `package Foo { use Moo; has qux => (is => 'ro'); around BUILDARGS => sub { my ($orig, $class, $args) = @_; return { qux => $args->{bar} * $args->{baz}, }; }; }; use strict; use warnings; use feature 'say'; my $o = Foo->new({ bar => 6, baz => 7, }); say $o->qux; say $o->bar;` [download] Output: `$ perl 11107488.pl 42 Can't locate object method "bar" via package "Foo" at 11107488.pl line + 24.` [download] Hope this helps! The way forward always starts with a minimal test.	[reply] [d/l] [select]
Re^5: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by Corion (Patriarch) on Oct 15, 2019 at 17:26 UTC
Re^6: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by haj (Vicar) on Oct 15, 2019 at 20:14 UTC
Some notes below your chosen depth have not been shown here
Re^6: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by 1nickt (Canon) on Oct 15, 2019 at 20:03 UTC
Some notes below your chosen depth have not been shown here
Re^2: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see? by cavac (Parson) on Oct 18, 2019 at 09:21 UTC
I really like the sound of including the real version number instead of a "5" (or "7") in the name. This way would be much easier to show progress and that it's "the latest, greatest version" `perl -e 'use MIME::Base64; print decode_base64("4pmsIE5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCiAgTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duLi4uIOKZqwo=");'`	[reply] [d/l]