Re^6: perl 5.38: can the body of a class declaration contain arbitrary code?

Replies are listed 'Best First'.
Re^7: perl 5.38: can the body of a class declaration contain arbitrary code? by cavac (Prior) on Jul 07, 2023 at 09:34 UTC
Sorry for the rant below, these are just my own, very heated, views on the topic. I've already banned "class" from all my projects. It's way to inflexible. Can't decide WHEN to call new() on the parent class Can't return undef from new() when init fails, meaning a `bla->new() or handleerror()` doesn't work. The "can't decide what to return from new()" problem also means factories will have to stay with the old package approach. Renaming new() to something else (connect() for example like in DBI) requires workarounds. No multiple inheritance and no partial classes. I sometimes use that to combine helpers and base classes to reduce code duplication and clutter Child classes can't access variables ("fields") of the parent unless declared public. So i would declare ALL fields public to lessen code rework and headaches further down the line. Which defeats the entire purpose of the new C++ style class system. While i generally like the style of declaring class variables and them the functions contained, the new `class` system feels way to restrictive and limited. And as we discussed in Thoughts on new 'class' OO in upcoming perl, i think the approach of "it's good for newbies, and later they can upgrade to using bless" is complete nonsense. As i've stated before: In my opinion, the ability of a language should suffice for experts, but at the basics should be easy for novices to learn. Without limiting their ability to use already learned stuff later when they start to climb their ladder to become an expert. As it stands now, "class" simply doesn't qualify. It introduces an artificial ceiling that requires re-learning Perl OO (using bless) and a complete rewrite of your code when the problem you need to solve gets more complex. I don't want to step on anyones toes, but `class` seems to be designed and optimized to look pretty and modern, functionality be damned. Which, in a way, is funny because people like me switched to Perl not because of how pretty it looks but because it has a much more flexible approach to, well, everything. The ability to bend the language to the problem, not the other way around. I also find the idea somewhat funny that a new, "more readable" OO system will attract new users because it makes the code easier to read. Pretty much every book on Perl introduces inline regular expressions in like chapter 2 and array slices/map/grep in chapter 3. If people can learn that stuff without running for python, blessy OO in chapter 10 isn't going to turn them away, either. XS in chapter 15 might be a different story, though... Yes, Perl could certainly use a more modern OO that is build into the language. But it should be at least as flexible as what we already have, but easier to use. Make it easier to learn, yet enable the experienced experts to bend it to whatever edge case requirements come up today. PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^7: perl 5.38: can the body of a class declaration contain arbitrary code?
by cavac (Prior) on Jul 07, 2023 at 09:34 UTC

Sorry for the rant below, these are just my own, very heated, views on the topic.

I've already banned "class" from all my projects. It's way to inflexible.

Can't decide WHEN to call new() on the parent class
Can't return undef from new() when init fails, meaning a bla->new() or handleerror() doesn't work.
The "can't decide what to return from new()" problem also means factories will have to stay with the old package approach.
Renaming new() to something else (connect() for example like in DBI) requires workarounds.
No multiple inheritance and no partial classes. I sometimes use that to combine helpers and base classes to reduce code duplication and clutter
Child classes can't access variables ("fields") of the parent unless declared public. So i would declare ALL fields public to lessen code rework and headaches further down the line. Which defeats the entire purpose of the new C++ style class system.

While i generally like the style of declaring class variables and them the functions contained, the new class system feels way to restrictive and limited. And as we discussed in Thoughts on new 'class' OO in upcoming perl, i think the approach of "it's good for newbies, and later they can upgrade to using bless" is complete nonsense. As i've stated before:

In my opinion, the ability of a language should suffice for experts, but at the basics should be easy for novices to learn. Without limiting their ability to use already learned stuff later when they start to climb their ladder to become an expert.

As it stands now, "class" simply doesn't qualify. It introduces an artificial ceiling that requires re-learning Perl OO (using bless) and a complete rewrite of your code when the problem you need to solve gets more complex.

I don't want to step on anyones toes, but class seems to be designed and optimized to look pretty and modern, functionality be damned. Which, in a way, is funny because people like me switched to Perl not because of how pretty it looks but because it has a much more flexible approach to, well, everything. The ability to bend the language to the problem, not the other way around.

I also find the idea somewhat funny that a new, "more readable" OO system will attract new users because it makes the code easier to read. Pretty much every book on Perl introduces inline regular expressions in like chapter 2 and array slices/map/grep in chapter 3. If people can learn that stuff without running for python, blessy OO in chapter 10 isn't going to turn them away, either. XS in chapter 15 might be a different story, though...

Yes, Perl could certainly use a more modern OO that is build into the language. But it should be at least as flexible as what we already have, but easier to use. Make it easier to learn, yet enable the experienced experts to bend it to whatever edge case requirements come up today.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

[reply]
[d/l]
[select]