# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #119355]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=119355 >
<BenGoldberg> rn: (^Inf but role {})[0].print
<camelia> niecza v24-88-g1f87209: OUTPUT«0»
<camelia> ..rakudo 63a865: OUTPUT«No such method 'BUILD' for invocant
of type 'Range+{<anon>}' [...]
<masak> I'm almost tempted to report that one as a rakudobug.
<jnthn> Weird error.
* masak submits rakudobug
<FROGGS> rn: (^3 but role {})[0].print
<camelia> niecza v24-88-g1f87209: OUTPUT«0»
<camelia> ..rakudo 63a865: OUTPUT«No such method 'BUILD' for invocant
of type 'Range+{<anon>}' [...]
<masak> Niecza's result looks perfectly reasonable to me.
<TimToady> it's a submethod, so cannot be used by a subclass
<jnthn> ah, yes.
<FROGGS> yeah, seen that too right now
<TimToady> guessing the generic BUILD method then can't handle the difference
<masak> still, an error seems a bit harsh.
<TimToady> maybe some types need to supply a method rather than a
submethod BUILD, if they are fiddly to derive from
<TimToady> though in this case, it seems as though it's a missing Mu.BUILD
<masak> r: print ((1..1) but role {})[0]
<camelia> rakudo 63a865: OUTPUT«1»
<masak> o.O
<TimToady> or the submethod is blocking inheritance of the generic Mu.BUILD
<masak> why does *that* work?
<masak> r: print ((0..3) but role {})[0]
<camelia> rakudo 63a865: OUTPUT«No such method 'BUILD' for invocant of
type 'Range+{<anon>}' [...]
<masak> r: print ((3..3) but role {})[0]
<camelia> rakudo 63a865: OUTPUT«3»
<masak> ah.
<masak> needs to have different endpoints.
<masak> r: print ((3..0) but role {})[0]
<camelia> rakudo 63a865: ( no output )
<masak> needs to have start smaller than end, even.
<jnthn> I guess it's on creation of the next iterator
<jnthn> Which makes sense given BUILD is complained about.
<masak> jnthn: aye.
<TimToady> so how *does* rakudo handle missing BUILD submethods, anyway?
* masak .oO( badly )
<TimToady> S12:667 seems to indicate there should be a Mu.BUILD
<TimToady> not to mention S12:866
<jnthn> TimToady: Calling a BUILD that actually does introspection
etc. turned out to be incredibly slow. BUILDALL actually executes a
class-compose-time assembled "plan" for how to do the object
construction. Thus the lack of "need" for a Mu.BUILD.
<TimToady> ok, but the plan in this case seems...lacking...
<jnthn> TimToady: Thanks to all the named arg passing around, it's
rather hard to get object construction to perform decently...
<jnthn> TimToady: I think that the range "make a next iterator" code
is cheating and doing a .BUILD call directly on a .CREATE'd object...
<jnthn> Which I guess is an OK cheat, expect it's also marked as a submethod
<TimToady> so maybe it should be a normal method?
<TimToady> or would that break differently? :)
<jnthn> That would seem to fix this particular issue, yes.
<jnthn> I can't immediately think of anything else it'd break
<TimToady> well, it'd be nice to have a better story than Ruby on
derivation from built-in types :)
<TimToady> but one also wants speed
<jnthn> The real pain I find with trying to get object construction to
perform is that new gets a named slurply, which it then flattens to
pass to bless, which in turn creates a new named slurpy
<jnthn> You can't just re-use the capture because bless wants one extra arg, *
<TimToady> right
<jnthn> For the thingy to bless.
<TimToady> maybe default bless doesn't take an arg, and we add a
bless_this or some such
<TimToady> and default bless can do its own create
<TimToady> names negotiable, of course
<jnthn> What role does bless actually fill today?
<TimToady> well, we don't want people putting nqp::create into their
constructors, at least
<jnthn> Just allowing for a candidate created with a different
representation to be passed in?
<jnthn> Sure, though I guess the .CREATE macro-ish thing maps down to it.
<jnthn> But yeah, a normal new shouldn't have to call that, I don't think.
<TimToady> rename BUILDALL to bless, then let them call either
Type.bless or Type.create.bless, and dispatch on :D ?
<jnthn> Could work
<TimToady> and .create by default assuming *
<TimToady> but you could create the candidate any other way, as long
as you pass a $cand.bless that bless can handle
<TimToady> otoh, $type.create.bless assumes you can pass the type
through the candidate, which might be problematic for some kinds of
candidate?
<TimToady> thinking about why .HOW requires the object as well as the metaobject
<jnthn> To allow prototype OO
<TimToady> just wondering if Type.create.bless can always work
<TimToady> can a candidate dispatch to its .bless without properly
knowing its original Type, I guess I'm asking myself
<TimToady> seems like not, but it's still too early in the morning
<TimToady> also, it'd be nice if the BUILD plan could just inline
whether to do the create or not, and maybe the create/no-create
distinction more declarative
