Private/public attributes/methods (was: An interview with Larry Wall (LinuxVoice))

Private
=======

Almost all the Perl 6 code I've seen uses the `!` symbol for private attribute declarations. I've read many Perl 6 coders say they prefer to use it.

But the `!` is optional. One can write as you suggest for the private attribute except missing out the word `private`:

class Foo { has Task @dependencies; # declare a private attribute that's an array of Tasks }

Public
======

A public accessor is a method, not an attribute.

A method is called using `.` syntax. Thus, assuming a public accessor method called `done` has been written for a class `Foo`, one might write code such as `say Foo.new.done` and it'll work.

The typical way to get a public accessor method written is to ask Perl 6 to automatically generate it for you:

class Foo { has Bool $.done; # declare attribute, generate public accessor }

The `.` is there in the declaration to remind one of a method call.

All methods called with `.` are public method calls so I'm not seeing the benefit of using the word 'public'. And dropping the `.` would be a big backward step imo.

So...
=====

Use `.` for declaring both a private attribute and public accessor method.

Then use the same `.` for calling the method -- with associated semantics/performance (run-time method resolution that only the JIT can optimize).

Use `!` (or simply omit the `.`) for declaring a private attribute.

Then use the same `!` (or not) for reading/writing the private attribute -- with associated semantics/performance (compile-time direct attribute access that's inlinable by an AOT optimizer).

---------------------------------------------

> Using ~ for string concatenation ... is weird.

I still recall the first time Larry explained his choice. It looks like a piece of string. If this mnemonic doesn't instantly make you go "ahhh", well, you're weird. :P

---------------------------------------------

> A good language design should take best practices, and not re-invent the wheel everywhere.

Sure. It sounds like we just disagree on what best practices to focus on and when innovation is a good thing.