DEV Community

Discussion on: Bringing Modern OO To Perl

Collapse
mhd profile image
Michael Dingler • Edited on

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).

Collapse
cliff profile image
Cliff Stanford

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.

Collapse
ovid profile image
Ovid Author

You're not going to get slated at all! Everyone has their preferences and we won't be removing bless from the core. So if you prefer to write your OO code that way, go right ahead. We won't break it.

Collapse
ovid profile image
Ovid Author

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.

Collapse
jplindstrom profile image
Johan Lindstrom • Edited on

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:

class Cache::LRU;            # to end of file
class Cache::LRU { ... };    # to end of block
Enter fullscreen mode Exit fullscreen mode

So what is the argument?

Thread Thread
ovid profile image
Ovid Author

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 has function or a method keyword 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.

Collapse
mhd profile image
Michael Dingler

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 method wouldn't compile either, just like one nested within a class. 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 😉