Years ago, when I first stumbled on Perl, I had been programming in many languages, including C, assembler, COBOL, BASIC, and Java. I had been work...
For further actions, you may consider blocking this person and/or reporting abuse
As with all syntax issues, it's a pretty silly pet peeve, but there's one thing I reallly like better in the core version: There's one indentation level less for most of the file. Most of the time you don't have multiple classes per file, so it's usually quite obvious that you're within class scope and I don't need another 4 char margin (or preferably 8, if I'm not beaten over the the head with PBP by co-workers).
I know what you mean and people have pointed this out a few times. The reason for this is when I mention that this is designed to be "backwards-compatible, but also allows the overall language to grow."
By having that extra level of indentation and putting the class definition in a block, we guarantee that, unless you're doing something really, really strange, it's backwards-compatible. That's because this code could never have compiled on older versions of Perl. The introduction of that block structure gives us the freedom to do anything in that block we feel is necessary, but companies can rest assured that they can still upgrade without our changing anything that currently exists.
As I've mentioned this is only a slight pet peeve and doesn't really impact me all that that much one way or another. Raku using the nested blocks alone would be a good reason for using that.
But I do feel a bit daft nonetheless: A top-level
methodwouldn't compile either, just like one nested within aclass. On the other hand, once you bring in stuff like Moops, Dios or just Function::Parameters, everything is possible.Having everything isolated in a block is a good visual boundary, definitely agree on that, but "could never have compiled" is a bit hard to parse for me on a Monday 😉
I don't understand the argument. How is "it can't compile" backwards compatible? It's new syntax that should blow up in earlier versions. And it does.
Aside from that, a class declaration with / without a block seems to blow up the same way:
So what is the argument?
This is something that was pointed out to me (by Sawyer? can't recall) a while ago as an unintended benefit. In short, if I wanted to repurpose syntax such as
my Dog $spot, I'd be stepping on existing syntax. However, by creating a new syntax with an unambiguous scope and is guaranteed not to run on older versions of Perl (short of something really bizarre going on), we have a brand new syntax which is guaranteed not to clash with existing usage.Further, because its scope is well-defined, we can play around with new syntax in that scope. Just adding a
hasfunction or amethodkeyword to the language could break all sorts of existing code that is already trying to do something like that. But by doing it in a new scope, we're safe.Actually, I'm probably going to get slated for this but I prefer the core version. I'd have written it more concisely but, IMO, it's easier to read and easier to write.
You're not going to get slated at all! Everyone has their preferences and we won't be removing
blessfrom the core. So if you prefer to write your OO code that way, go right ahead. We won't break it.I like this! I think you are on the right track. And I agree 100% that the proper goal is to produce a better OO language than any available today. Perl has been falling behind the curve for too long now, and if we are going to revitalize the community we need to be jumping ahead rather than catching up.
The one part of the specification that worries me so far is that slot variables defined after the last :new slot variable in a class will be undefined when CONSTRUCT is called. It seems to me that "the last :new slot variable" is going to be a difficult thing to keep track of in large class definitions, where developers may be adding and removing :new from various declaration lines as development proceeds.
I suggest instead an additional attribute :after, such that slot variables with this attribute will not be defined until after CONSTRUCT is called. All other slot variables will be defined before CONSTRUCT is called, in the order defined. Specifying this explicitly rather than positionally will, I think, avoid a lot of confusion.
Since this was posted, we've had a lot of discussion around
CONSTRUCTand have since realized that as a phaser, it actually doesn't work since it needs to return a value. So we dropped it entirely. Now, we just use alternate constructors if we need to munge the arguments, or do validation in theADJUSTphaser.Good, the implementation of CONSTRUCT as proposted on the current Wiki page bothered me a great deal. I agree that dropping it was a good choice. Can you point me to where these discussions are going on? I'd love to follow along and give my input where warranted.
Largely they're on irc.perl.org on the #cor channel. Mostly it's pretty quiet right now because we've nailed down much of the behavior and the push to get the next version of Perl out the door is taking priority.
I am super excited to see this come to fruition. There seems to be very careful thought going into what "Corinna" should be in the core.
Its been a long wait. Really looking forward to this
Please provide some test cases so that we can improve your code.
I looked at some Perl I wrote the other day, from about 15 years ago or thereabouts.
I have literally no idea how any of it works, and it's kind of turned into that thing.