On Fri, Nov 04, 2005 at 12:37:04PM +0100, TSa wrote: : The above also describes my perception of the $. twigil notation which : are variables bound through the invocant(s). My mental picture beeing : one where a method is instanciated as a not yet invoked sub after selecting : the target code body in the dispatch process and binding the twigils of it : on the invocant(s). This models twigil variables of the $. form as a kind : of pointer into the object's state. The information how to perform this : binding travels along the lines of inheritance. For twigiled vars of the : private data form $: this knowledge is *not* forwarded in the inheritance : process. The non-twigiled forms of variables are lexically scoped without : relation to the object state. : : Question: what is the current state of affairs in @Larry about the private : instance data notation? Is it still with an underscore as the first char in : the variable's name? Or are we back with $. and $: twigils?
At the moment $: is dead, and we last left it at: has $.foo; # public has $foo; # private has $._foo; # private storage of $.foo I like the fact that it makes it easier to name the private $foo attribute than to name $.foo, and I also like the fact that the privacy is lexically enforced with $foo. On the other hand, without the twigil, it become problematic to write a BUILD routine that automatically sets attributes. We can't really allow: submethod BUILD ($.public, $private) { } Instead we get a backwards result like submethod BUILD ($.public, $privatearg) { $private = $privatearg; } where it becomes *harder* to write the private initializer than the public one. That I don't like. And $._foo is just plain ugly. So I think we haven't finished thinking this one through. The $: approach had the advantage of making a positive visual statement about the privacy. Arguably though, the interface of submethod BUILD ($.public, $:private) { } is giving away some info about the private name of a variable. But that can't really be helped, and we now have the :foo($bar) syntax to rename parameters. But $: was dead for several good reasons, and I think it'll stay dead for at least some of those reasons. Maybe we can go back to $!foo for private vars. That's easier to type (at least on my keyboard) than $.foo, and has some connotations of NOT public. And then maybe, since $.foo is virtual, $!foo could be the devirtualized storage for $.foo. And since .foo is not a self call any more, we don't have the visual confusion of ! or .! where a term is expected. self!foo() is a private method call on yourself (but why not just write $!foo), while $other!foo() is a private method call on some class that trusts this class. Another possibility is to take $? away from the compiler. All the compiler variables could go under $= instead, since pod is actually just one particular kind of compiler-time data, and there's really no particular mnemonic relationship between ? and the compiler. But $?foo is harder to type than $!foo. Maybe we hold $?foo in reserve for some other kind of attribute scope. Another possibility is that the twigil is never an official part of the attribute name, so that when you say has $.foo; you're really declaring the private storage variable $foo, and $.foo is just how you explicitly refer to it virtually. To explicitly refer to it non-virtually you use $!foo, but it means the same as $foo. It's your choice as to whether you want to be explicit about the privacy, except in submethod BUILD ($.public, $!private) { } where the ! is required to get autoassignment to $private. Interestingly, though, you could write that submethod BUILD ($!public, $!private) { } and get the same effect, since $!public is referring to $public, which is the private storage for $.public, and in the case of an initializer you want to be setting the private storage anyway. Arguably it should earn you a warning to use a virtual $.public within a submethod rather than the non-virtual $!public. : On the same line of thought: is the has declarator also supported outside : of class declarations? As in : : my $x has $.blahh; : : $x.blahh = 42; The thing that bugs me about that is "my $x" is a variable declaration, but your "has" declaration seems to want to do something to the type of a non-existent value in $x. So I'm not really sure what that desugars to. Larry