Re: Thoughts on replacing -> with .

[davido]

If this is seriously being considered (as opposed to the lively banter that goes on within the p5p list, usually leading to no change), I'm very much opposed.

This is Perl. I want to be able to look at Perl code and know that the -> operator does what it's been known for more than a decade to do, and that the ~ and . operators do what they also are expected to do. I don't want to have to look through the code for some pragma use that changes the meaning.

I totally get the usefulness of // and //=. I even get the well intentioned but possibly overly ambitious and misguided rationale that brought us ~~. But to change the meaning of existing operators just so that -> is easier to type, and looks more like JavaScript... that's an utter waste of time and energy, at best. At worst, it will contribute to harder to maintain, harder to understand code as well as an entirely new round of Perl-internals bugs to squash before finally deciding it was a bad idea and deprecating it for Perl 5.24.

If it's such a great idea, let someone implement it via overload and put its use into production. If he's still employed in 60 days, we can revisit the issue. ;) I do see that Acme::RenameTheOperators is an available namespace.

It's fine to dream and think, "what if?" But honestly, before a change gets into the core, someone ought to be asking the question, "What problem is this solving that justifies the additional complexity?" Because make no mistake, this does introduce additional complexity. And it doesn't make anything possible or easier that was previously impossible or difficult.

[davido]

I just wanted to follow up by mentioning that I have now read the entire Perl5-Porters thread, and am surprised at how well received this is. There are a few dissenters, but a lot of "hey, neat" sentiment.

My opinion remains the same, if it doesn't make impossible things possible, or hard things easy, it isn't worth the added complexity, confusion, and certain need for debugging that would be levied on the poor user base. But perhaps it does beg a different discussion; the proposed change requires a patch to the Perl code base. Rather than patch to make this change, patch to make it easier to implement such a change without modifying Perl itself. In other words, make it possible for mortals to create a "dots" pragma without each such pragma requiring a change to the Perl core. That would be a more generalized and more useful solution, and while it would still be adding complexity and a round of debugging, it would at least be giving the users the tools rather than the widget made by the tools. We know exactly how a "dots" pragma would be used (if at all). Its advantages seem only to shave a few keystrokes. What benefits a language more is those features that are general enough that we cannot predict all use cases.

If hooks were implemented in Perl's code base to allow a "dots" pragma to be created without recompiling Perl, the pragma could be placed on CPAN rather than as part of the Perl core. CPAN is really where something like this belongs. And someone might actually find a way to use those hooks that is more meaningful than just re-purposing dot, and eliminating ->.

[perlfan]

I believe it's the squawking of overzealous minority, which gives the impression of the silent majority -some thinking this is a sick joke and others really just too tired at this point to defend yet another trojan horse proposal.