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 o
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 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 initializers ... onl
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
>
On Wed, Feb 1, 2012 at 5: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?
Limiti
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 app
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 certai
On 02/02/2012 06:42 AM, Damian Conway wrote:
> S12 has an example that explicitly contradicts this constraint that
> constructor
> args have to be public attribute names:
>
> submethod BUILD ($arg) {
> $.attr = $arg;
> }
That example is certainly a fossil.
In BUILD, the object i
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).
Ag
On 2 February 2012 17:40, Damian Conway 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 the behaviour of
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)
13 matches
Mail list logo
