Jonathan Lang (>>), yary (>): >> Why must we use 'submethod BUILD' instead of 'method BUILD'? >> Is it some sort of chicken-and-egg dilemma? > > from S12: > "Submethods are for declaring infrastructural methods that shouldn't > be inherited by subclasses, such as initializers ... only the methods > are visible to derived classes via inheritance. A submethod is called > only when a method call is dispatched directly to the current class." > > It isn't chicken-and-egg, it's safety. The BUILD submethod doesn't get > used for anything other than the class it is defined in, even if that > class is derived from.
When I first used submethods, I thought of them as just subroutine-method hybrids: they are a little like subs because they don't inherit. They are a little like methods because they take an invocant. I didn't much care about the "infrastructural" bit, mostly using them as a kind of private methods. (Nowadays I use private methods as private methods.) :-) Getting back to the topic of the original post: I think "blessall" is a bad name for what's proposed, and I don't see a fantastically large need for that functionality. What's wrong with just defining a BUILD submethod in the class? I also don't see a problem of having to divide initialization code between .new and .BUILD. They have different purposes -- .new is outwards-facing, receiving arguments. .BUILD is infrastructural and inwards-facing, building up (as the name suggests) your attributes. If you need to modify both these behaviors, you override both. // Carl