Do you know that Perl 5.0 actually had less syntax than Perl 4? It had more generalizable syntax, and was mostly backwards compatible, but it had fewer actual syntax rules!

Useless trivia. Both the . and the -> notations for OO programming have their roots in C. If foo is a struct, and bar is a property of the struct, foo.bar pulls that property out. If baz is a pointer to foo, then baz->bar does likewise.

In Perl the . was already taken for string concatenation, so -> was the next reasonable choice. And the analogy is surprisingly exact. For example if $foo = $bar = {} then calling bless($foo) will also bless $bar since both are just references to the actual object.

As for lots of ways to say the same thing, TIMTOWTDI was an intentional goal.

Sure, TIMTOWTDI was an intentional goal. I'm not sure it was a good goal, in hindsight. The whole "What idiot wrote this crap? Oh yeah, me" problem was worse in Perl than in other languages. And reading other people's code often involved learning whole new programming concepts.

Which is actually incorrect usage of "object oriented stuff", because you should use an accessor, not depend on the underlying representation. So that should have read `$this->mess`

And who writes accessor methods in PERL?

At that point, you might as well start using a heavier language.

In Modern Perl (5) you use a module such as [Moose](https://metacpan.org/pod/Moose) or if that's too heavy for you [Moo](https://metacpan.org/pod/Moo).

You rarely write accessor methods yourself in Perl 5. In Perl 6, you describe your accessors/mutators in the class definition:

    class Pointer {
        has $.x;       # a ro accessor
        has $.y is rw; # a rw mutator
    }

Which, by the way, is now faster than Perl 5.

> has $.x; # a ro accessor

> has $.y is rw; # a rw mutator

Opinion: I don't like the asymmetry of that, although I do understand that having to write "is ro" too, would make the language slightly more verbose.

Python has something similar with the syntax for properties; don't like that syntax too, for the same reason (asymmetry).

E.g.: The 2nd code example in the question here -

https://stackoverflow.com/questions/17330160/how-does-the-pr...

- the one that uses

    @x.setter

I'm not a language designer or close to it, though, just saying.

You can always add `is ro` trait modifier.

    multi sub trait_mod:<is> (Attribute:D $attr, :$ro!) {
      # no need to do anything, because this is the default
    }

    class Pointer {
        has $.x is ro;
        has $.y is rw;
    }

That is assuming you aren't fine with using `is readonly`.

    class Pointer {
        has $.x is readonly;
        has $.y is rw;
    }

Which works better with the trait mod `is required`

    class Pointer {
        has $.x is readonly is required;
        has $.y is rw;
    }