On Tue, Jul 19, 2005 at 02:21:44PM +1200, Sam Vilain wrote: : Larry Wall wrote: : > > Users of the class includes people subclassing the class, so to them : > > they need to be able to use $.month_0 and $.month, even though there : > > is no "has $.month_0" declared in the Class implementation, only : > > "has $.month". : >We thought about defining the attribute variables that way, : >but decided that it would be clearer if they only ever refer to : >real attributes declared in the current class. : : Clearer in what way? : : This implies that you cannot; : : - refactor classes into class heirarchies without performing : code review of all methods in the class and included roles. : : - "wrap" internal attribute access of a superclass in a subclass : : This in turn implies that the $.foo syntax is, in general, bad : practice!
Well, maybe it's bad outside of submethods, where we must have a way to devirtualize. I see what you're saying, but I'll have to think about it a little. It does seem a bit inconsistent that we're forcing virtualization of class names within methods but not attributes. Perhaps $.foo should be used to refer to the actual attribute storage only within submethods, and when you declare "has $.foo" you're not declaring an accessor method but rather a submethod that wraps the actual attribute. The question is then whether normal methods should treat $.foo as an error or as $?SELF.foo(). Yes, I know your preference. :-) Anyway, I have to do a bit of driving the next two days, so hopefully I'll have a chance to think about it s'more. But my gut feeling here is that we both oughta be right on some level, so it probably just means the current design is drawing some border in the wrong place. The right place might or might not be the method/submethod boundary. Larry
