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

Reply via email to