Re: Cor—An object system for the Perl core

Hi again Ovid,

Well, you've made it clear in your replies in this thread that your intent is nothing less than to extend the Perl language itself to have a built-in object factory. Better than any of the other object framework/tools that currently exits for Perl -- and better than any that exist for any other language, built in or not.

Wow. That's an ambitious goal! Were it to become reality, that would be fantastic.

However, foremost in my mind, besides what Fletch highlighted, is what I mentioned earlier: that the last time someone had an idea this grandiose and it was stuffed into Perl, we got the decade-long smartmatch fiasco. Meanwhile Damian Conway and the rest realized that wasn't going to work, so they started the "Perl6" project, squatted on the Perl name for 15 years, blocking Perl's major release process, and finally, thankfully, took their ball and left to play elsewhere.

Many people said during that ordeal (I think you were among them?) that Perl did not deserve a major version release because it was lacking at least two prerequisistes: a built-in method signatures framework, and a built-in object framework.

IIUC from reading here, signatures are likely to be implemented in Perl 5.32 or 5.34. I'm not a fan of that personally, for the same reason I am not a fan of your idea: I will continue to use Method::Signatures because I don't think the new stuff is as good, so now my perl will have stuff built in that I don't want and won't use. Frankly, I don't think that is the Perl way.

I'd much rather see signatures and Cor, or whatever /p(?:7|34|42|2021)p/ decides upon, included in the next major version release of Perl.

Like it or not, Moo is the de facto standard for modern Perl application development. "Real developers" (coff, coff) of "large-scale codebases", who may or may not be "heavily, publicly involved in the language" know this, and maintain uncounted applications, all around the world, that depend on hundreds of CPAN modules, as well all their in-house libraries, that are all based on Moo. None of those "real developers" is going to change any of that production code; it's absurdly arrogant to think so.

Your own mostly wonderful Test::Most is a great example of how a designer's assumptions that are baked in make things less than completely Perlish. RJBS decided that he would export methods named all and any by default from Test::Deep, then you implemented Test::Most in a way that disallows controlling the bundled imported methods. So now it's impossible to test code that uses a method named any, e.g. from List::Util, without fiddling with the symbol table to rename the methods Rik and you assumed everyone wants exported.

I wish you well, but please adjust your plan to aim at the next Perl major version release. Perl can't withstand another backward-compatibility mistake that hamstrings it for a decade.

The way forward always starts with a minimal test.

Comment on Re: Cor—An object system for the Perl core Select or Download Code

Replies are listed 'Best First'.
Re^2: Cor—An object system for the Perl core by Ovid (Cardinal) on May 29, 2020 at 12:17 UTC
1nickt wrote (emphasis mine): Your own mostly wonderful Test::Most is a great example of how a designer's assumptions that are baked in make things less than completely Perlish. RJBS decided that he would export methods named all and any by default from Test::Deep, then you implemented Test::Most in a way that disallows controlling the bundled imported methods. So now it's impossible to test code that uses a method named `any`, e.g. from List::Util, without fiddling with the symbol table to rename the methods Rik and you assumed everyone wants exported. This is not true. Specifically, it's not true that "it's impossible to test code that uses a method named `any`" (nitpick: it's a subroutine, not a method). First, you can fully qualify your subroutine name as `List::Util::any` to test it. However, a better solution is to simply exclude `Test::Deep` via `use Test::Most '-Test::Deep';`. This behavior is clearly documented and has been in `Test::Most` for a decade. Neither solution requires "fiddling with the symbol table." Cheers, Ovid Hire me for training or software development.	[reply]
Re^3: Cor—An object system for the Perl core by 1nickt (Canon) on Jun 01, 2020 at 21:11 UTC
Neither does either proposed solution solve the problem. I have a class. The class uses a bundle module. The bundle imports List::Util::any into the calling package. I like to test my classes. I like to use Test::Most. If I use Test::Most with default imports I get an exception (under strictures). Instructing Test::Most to not import Test::Deep in order to avoid this collision means that I cannot use the other methods in Test::Deep that I require. Test::Most does not allow granular control over the exports of the modules it imports. That's a design assumption: the user will either want all of Test::Deep or none of it. It limits the value of Test::Most. I don't want to see similar design assumptions baked into Perl. No one set of assumptions can possibly meet everyones's needs. It would be a mistake to put Cor or any other OOP framework into the Perl language. Q.E.D. The way forward always starts with a minimal test.	[reply]
Re^2: Cor—An object system for the Perl core by 1nickt (Canon) on May 22, 2020 at 17:27 UTC
Alternatively, release and maintain a fork, maybe "CorPerl - Perl with objects"? In that scenario, you'd be equivalent to RPerl and CPerl; you could get endorsement, support, maybe cash, from TPF. Because Perl is a family of languages, don't you know. Heck, maybe Will the Chill wants core objects, and y'all could get together and publish "CoRPerl", if fast is among your goals. The way forward always starts with a minimal test.	[reply]
Re^3: Cor—An object system for the Perl core by perlfan (Vicar) on Jun 02, 2020 at 01:18 UTC
I tried to upboat this more than once, but it won't let me. I've mention Qore here before. Although Perl folks pretend it doesn't exist and the creator of Qore at one point said he'd never heard of Perl. So idk, that's a little strange. Anyway, TFM says, Programmers familiar with C, C++, Java, and/or Perl should find the standard Qore syntax intuitive and should be productive fairly quickly with the language. However Qore has unique features that differentiate it from other languages, and these features must be mastered in order to leverage the full power of Qore. In fact, it goes well beyond, ...Perl (programmers) should find the standard Qore syntax intuitive and should be productive fairly quickly. Well I've found that it's demonstrably true that a useful subset of Qore is identical to a marginally useful subset of Perl. It's also: truly SMP with real threading supports `$REAL` OOP when you actually want it super cool And I have mentioned this before, too. It's not my go-to language. Perl is. Why, despite knowing darn well what's good for me? Qore is not perlish to the degree I want it to be I don't need SMP, and when I think I do, `fork` works well enough for me (who needs child processes to communicate back with their parents? ha!) I can assume `perl` is anywhere I need it to be Even if Perl and Qore pretend each other doesn't exist, it's still a better and less awkward love story than all the perl forks and broken dreams. Update - found this nice down about Qore on their GH wiki, Why Use Qore. And it's on MacPorts! (no they don't call it MacQore)...now I gotta go lookup MacPorts vs Homebrew. Update 2 - it occurred to me why I do prefer Perl. It's because it's the perfect tool for bending *nix to one's will. It turns a system into putty in a master's hands (or even a baby's). And that's why I use it. Of course implied is also it's fabulous community of free thinkers and hackers.	[reply] [d/l] [select]
Re^4: Cor—An object system for the Perl core by marto (Cardinal) on Jun 02, 2020 at 08:10 UTC
"I tried to upboat this more than once, but it won't let me." Unsurprising. Your links don't work, notes on how to do this properly are displayed each time you post.	[reply]
Re^4: Cor—An object system for the Perl core by soonix (Canon) on Jun 02, 2020 at 12:04 UTC
I hadn't heard of Qore either, therefore more interesting for me would have been these links Wikipedia page Qore tutorial You wrote a useful subset of Qore is identical* to a marginally useful subset of Perl.* Depending on what exactly you mean by "identical" influences the size of the "subset". I see similarities, Wikipedia says "inspired", but not exactly identical...	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks