# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #116783] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=116783 >
<TimToady> r: https://gist.github.com/TimToady/4963642 <TimToady> jnthn: that gets me an error Nominal type check failed for parameter '$payload'; expected T but got Int instead <TimToady> but T is supposed to instantiate to Int <jnthn> Sure is. <jnthn> Any idea exactly which T it is? <TimToady> the sig in post-insert <jnthn> oh. <jnthn> role DLL[::T] { <jnthn> my class DLLE does DLL_Element[T] {} <jnthn> You nested a class in a role. <TimToady> I don't know how to do that otherwise <jnthn> Roles aren't as macro-ish as you expected them... <jnthn> It doesn't make a fresh class per role instance. <TimToady> well, I guess I can instantiate in parallel, but it'd be nice if one could drive the other <jnthn> And the one declaration sees the uninstantiated type variable, 'cus it comes into existence before the role is ever composed. <TimToady> okay...have to think about it s'more <jnthn> Does the spec make a call on what happens to packages declared inside roles? iirc, it doesn't call either way <jnthn> I've always had it down as a grey area. :) <TimToady> here be grey dragons... <jnthn> I suspect we *could* find a way to make it work but by then we're pushing roles further into macro territory <japhb_> .oO( TimToady: "Do I want this enough to change the spec so jnthn has to make it so ...?" :-) ) <TimToady> I just think it's kind of typical to want to instantiate a forest of classes together <jnthn> TimToady: While you're on it, you may also wish to ponder this issue: <jnthn> r: role Foo { our sub foo() { say 42 } }; Foo::foo() 22:31 <+p6eval> rakudo 1e85ff: OUTPUT«Could not find symbol '&foo' [...] <jnthn> That at first blush looks like it should work, but it doesn't at the moment. <jnthn> The reason it doesn't is... <jnthn> role Foo { }; role Foo[::T] { } <jnthn> Roles are multiple dispatch <jnthn> What's actually installed in Foo is not actually the role. It's basically a thingy that does a multi dispatch to pick a role. <jnthn> Which gets a type object of its own. <jnthn> ParametricRoleGroupHOW or so. <TimToady> the downside to all this punning... <moritz> .oO( punning for the fjords...) <jnthn> Yeah. Well, I've mentioned before just how many different forms roles come in :) <jnthn> Which I don't see as a problem per se. <jnthn> But the only sane way I found to implement all the things is to untangle the puns. <jnthn> tbh, I think putting our scoped stuff inside something generic is crazy anyway... * TimToady imagines Foo as a search path of packages, and shudders <TimToady> which is why I declared my inner class with 'my' :) <jnthn> That is, I can imagine that if you try to install something our-scoped inside a role, we say "no, this won't end well" :) <jnthn> Yeah. I can see what you wanted it to do. :) <jnthn> I'm just asking if we really want the complexity of doing it :) <TimToady> dunno; do Java generics have a story on this sort of thing? <jnthn> It *is* the same machinary masak++ will want for declarations in macros, so in a sense we're gonna have to solve the problem anyway. <TimToady> .oO(and you thought *monads* were hard to lift...) <jnthn> Java generics are mostly an example of what not to do. :) <jnthn> C# ones, otoh, are done properly. <TimToady> so what do they do in this case? <jnthn> In C#, if you write an inner class inside a generic class, it also becomes generic. <jnthn> Hm, darn, I just said that's the proper thing to do, didn't I... :) * TimToady is not going to torment the implementors (much) more than they torment themselves <jnthn> From the spec: <jnthn> Any class nested inside a generic class declaration or a generic struct declaration (§25.2) is itself a generic class declaration, since type parameters for the containing type shall be supplied to create a constructed type. <jnthn> We maybe don't want quite that factoring, since our type parameters are just lexical. <jnthn> We just want to hang on to the class in a generic form and then reify it. <TimToady> but an inner class that is dependent on T, like mine... <jnthn> Well, I guess we'd treat any class inside a role as generic in some sense. <jnthn> I suspect making it do what you expected is (a) possible, (b) least surprising, and (c) hard. :) <jnthn> Which basically makes it a great candidate for a Perl 6 feature. ;-) <TimToady> vicarious suffering, and all that... <TimToady> well, just because it's Friday doesn't mean you have to do it today :) <jnthn> :) <jnthn> Anyway, no objections if you want to spec it that way. * TimToady is not sure he understands it well enough yet to talk about it <masak> TimToady, jnthn: could either of you golf an example of expected/actual behavior of a class nested in a generic role? then I can rakudobug it. <TimToady> masak: here: https://gist.github.com/TimToady/4967666 <masak> r: role Foo[::T] { has T $.p = T }; role Bar[::T] { my class Fooey does Foo[T] {}; submethod BUILD { Fooey.new } }; class RatBar does Bar[Rat] {}; RatBar.new <p6eval> rakudo 1e85ff: OUTPUT«Cannot type check against type variable T [...] * masak submits rakudobug <TimToady> and yes, RatBar is an allusion to the Vorkosigan universe :)
