Because encapsulation helps prevent action at a distance, structured naming helps prevent typos

And here I go on an irrelevant-to-OP tirade again, sorry.

Is Perl's business to prevent action at a distance and typos? Educate, supervise, mentor and pay a developer more and they will be more careful. Then, code reviews can reveal practices which are considered "bad" by management (i.e. action at a distance).

IMO encapsulation means encapsulation of the program logic. Creating a black box which goes out and hunt. Encapsulation, for me, does not mean protecting each and every variable in there from sloppy devs, although I am sure there will be countless "software" "engineering" "books" out there promoting this hysteria. Hey, why don't we enclose each Object within a firewall for good measure? That's the nanny-state of programming.

But that's exactly what it came to mean today. It's this industry alone which promoted all those sloppy devs or rather the sloppy dev processes and "key-hole programming". The current meaning of the word encapsulation brings to my mind all those phone chargers which have been encapsulated in raisin so hard one can not remove a single piece of copper from them or fix them. For safety, they claimed. But in the 3rd-world's dump heaps which inevitably said chargers end up they are "de-capsulated" really well in true Gordian fashion: burn the plastic and melt them in acid, which kills them poors and the planet too.

Personally, I don't want to see Perl "polluted" by new keywords and new syntax. Aesthetically, at least, I am not comfortable with the "has" and friends. So I only use the minimalist (classic) OO provided by core Perl. KISS. But I also see the point of view of the others who do like or rather need, and use them. Fine.

Subjective, personal opinions: I consider OOP a real step forward, like Man standing on 2 feet. Judging from PM questions (a very rough indicator) OOP+Perl is used by only few. Even using packages alone to encapsulate and separate program logic is not the commonest practice. I would concentrate on making these two things much more accessible than actually alienating users by enforcing extra nomenclature like "has" (see where make-a-keyword-a-day Java ended up). I said before, albeit being ignorant about the details: those who can, perhaps could spend their effort in modernising the perlguts instead. Or offer us mortals truly accessible, simple documentation to perlguts and XS so we can be educated and participate. "has" can wait AFAIC (and so can function signatures).

I wake up each day in fear that Hashtables fall to the hands of "language revisionists" (sorry!) (re: typos of keys). That will be a slaughter.

I welcome down-voting as a means of "silent" disagreement.

bw, bliako

Is Perl's business to prevent action at a distance and typos?

This is silly.

Yes, of course Perl is coming to your house, dumping you out of your chair, throwing strict on all of your code, and stepping on your fingers with its jackbooted feet on its way out, so you can't not ever use encapsulation again.

No one has ever added a feature or a test or documentation to Perl, hoping that it'll help people get their jobs done better.

I wake up each day in fear that Hashtables fall to the hands of "language revisionists" (sorry!) (re: typos of keys). That will be a slaughter.

IMHO, you need to worry about more important things.

> Educate, supervise, mentor and pay a developer more and they will be more careful.

Having already problems to find skilled personnel, a manager will think twice to pay more!

Especially if his competitors can solve more problems with less and cheaper hackers, just because they are guided by a strict framework / IDE.

Then he will rather try to imitate their approach.

> That's the nanny-state of programming.

So you are never activating strictures, because you don't want to be "nannied"?

Maybe time to return to assembler? ;)

> Aesthetically, at least, I am not comfortable with the "has" and friends.

Saying so I'm critical about has because it's putting the emphasis on the objects data during the design process.

An object is primarily doing something it's not necessarily supposed to have something.

It should be planned by its interface not by its state. °

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

update

°) See also this excellent talk

"Tadeusz Sośnierz. How Moose made me a bad OO programmer" on YouTube

Tadeusz is showing how syntax decisions are nudging programmers into designing objects leaking their internal state instead of hiding the implementation.

The has keyword is from Raku, or as it was called at the time, Perl 6. Moose copied it. Others copied Moose.

toby döt ink