in reply to Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
in thread What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

You can do this already. But it doesn't make sense to do this instead of creating accessors.
IMHO, accessors are way too heavy instrument. The same objection as using regex for trimming whitespace applies: sending tank division to capture unarmed village.

Also enforcing/encouraging OO programming style where it is not appropriate is bad, unless you are a book author ;-) Anything connected with classes and instances of them requires the problem that fits this model (remember Simula-67 in which the concept was originated stems from simulation language Simula, where this is lingua franka: simulation objects typically exist in many-many instances ). It is not a universal paradigm, as some try to present it.

This topic is actually a part of BioPerl vs BioPython debate and I think one of the reasons that Perl so far holds its own for small bioinformatic programs (say less then 1K LOC) written by researchers is that it introduces less overhead and programs written in it consume less memory while processing the same data sets (which is important for server nodes with only 128GB of RAM, which are most common for bioinformatic clusters nows -- only few "large memory nodes" have 1TB or more of RAM ). See, for example:

  • Comment on Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

Replies are listed 'Best First'.
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami (Pope) on Sep 18, 2020 at 09:17 UTC

    Also enforcing/encouraging OO programming style where it is not appropriate is bad

    Do you listen to yourself? Having modules provide functions is not bad.

    Besides, I said you can already do this without accessors.

Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Anonymous Monk on Sep 18, 2020 at 01:14 UTC
    https://link.springer.com/article/10.1186/1471-2105-9-82/figures/3

    Oh hey, I've seen that link before. You're ignoring the elephant in the room: if you want speed, you need to use C. Oh, and C++ isn't very far behind so maybe it's worth using that instead because std::string is so much nicer than cstrings.

    I'm not sure what you're up to here, I see no point to any of your recommendations on Perl 7 and, worse yet, you insist on misquoting Knuth to support your position.

    Ok, I'm sorry. That probably feels like an attack. I'd like to think your heart is in the right place and that you're really trying to make Perl better. Assuming your realm is genetics, the way to make Perl faster is XS so you can use C for the speed. Micro-optimizing on $_ is not the answer.