On Sat, Nov 05, 2005 at 11:35:38AM -0800, Jonathan Lang wrote: : First off: is there a way to declare a method as being private to a role?
We're still batting around the notion of private methods. Certainly with a lexically scoped sub you can get most of the same benefit. Trust could then perhaps simply be exportation of the sub to another scope, though naming another lexical scope is problematic, and if you export into a package the name becomes public property. So the import needs to be into a different lexical scope that happens to be governed by a particular trusted class name. Lexically scoped methods or submethods are also a syntactic possibility: my method foo {...} my submethod BUILD {...} If this is how you write private methods, though, these have to be totally invisible to the ordinary dispatcher. And just as "has" defaults to private in the absence of a twigil, perhaps it does on methods too: has $foo; # short form private has $!foo; # long form private (but same variable as $foo) has $.foo; # public virtual interface to private $!foo has method foo; # short form private? has method !foo; # long form private? has method .foo; # public? same as "method foo" But that's a little strange--"has" should probably indicate that each object maintains its own copy. Maybe it's really the underlying delegation mechanism: has method foo = some_other_foo(); # init at BUILD time So probably "my" is still better for private methods, and tends to keep weirdness out of the package's public interface. It would be nice if the package only contains public method names and private metadata is confined to the meta object (whether class or proto based). : Second: can a role reclassify as private a method that is composed : into it from another role? I don't see much point. Private methods are non-virtual, and shouldn't be inherited, or block the inheritance of anything public. Private methods are really just subs in disguise. We allow them to be called with something resembling ordinary dispatch syntax (probably via $!foo and $obj!foo() these days) but the public and private dispatch mechanisms have no overlap. Larry