I wrote my first perl6 over the weekend, needing some help on #perl6.
And now after finishing some lunchtime thoughts I wanted to post here
on my main sticking point.
If one wants to set a private attribute, one must define a submethod
BUILD. If one wants to use any argument in the constructor
Why must we use 'submethod BUILD' instead of 'method BUILD'? Is it some sort
of chicken-and-egg dilemma?
Jonathan Lang ():
Why must we use 'submethod BUILD' instead of 'method BUILD'? Is it some
sort of chicken-and-egg dilemma?
Philosophically, BUILD submethods are submethods because they do
infrastructural stuff that is very tied to the internals of the class.
Submethods are internal methods
On Wed, Feb 1, 2012 at 3:24 PM, Jonathan Lang datawea...@gmail.com wrote:
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
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
On Wed, Feb 1, 2012 at 5:41 PM, Carl Mäsak cma...@gmail.com wrote:
...
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
Looking back at my paltry code, what I ended up doing was having a
BUILD submethod that just listed all my attributes, private and
public, and an empty block, essentially turning bless into
blessall. Which makes submethod BUILD looks like boilerplate, a
magic invocation, repeated in my classes.
On 02/01/2012 11:41 PM, Carl Mäsak wrote:
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?
The current approach
Yary wrote:
If one wants to use any argument in the constructor other than a
public attribute (positional OR named other than an attribute name),
one must define a method new( ... ).
Huh? I know I've been out of the loop lately, but this seems fundamentally
wrong.
Constructor args certainly
Moritz clarified:
In BUILD, the object isn't yet fully constructed, and thus using $.attr
(which is really a virtual method call in disguise) is wrong. STD and
niecza already catch that at compile time, and I'm currently trying to
make rakudo catch it too (branch 'has-self' on github).
On 2 February 2012 17:40, Damian Conway dam...@conway.org wrote:
I sounds like I simply misunderstood yary's problem, but I'd be
very glad to be reassured that's the case. :-)
AIUI, yary is talking about the default BUILD submethod that is generated
if you don't provide your own (or maybe its
On 02/02/2012 07:40 AM, Damian Conway wrote:
My point was that I don't want the named arguments that BUILD can take
to be restricted to only the names of public attributes...which was, I
thought, yary's complaint when writing:
No, the complaint was that when you write self.bless(*, |%named) in
12 matches
Mail list logo
