Skip Menu |
 

This queue is for tickets about the Moose CPAN distribution.

Report information
The Basics
Id: 117325
Status: rejected
Priority: 0/
Queue: Moose

People
Owner: Nobody in particular
Requestors: thomas.pansino [...] intel.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



MIME-Version: 1.0
X-Spam-Status: No, score=-1.9 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham
X-Titus-Metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTE2ODBmYWUtNjUxYy00M2UzLWI1NWUtNzRmODQ1MmRjYTVhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjNYdkw3RFdZdXdNQ0RkSU54RTczUXVDWERlcFdQb3RZNkNZZUpVZTZQZDA9In0=
X-Spam-Flag: NO
X-Virus-Checked: Checked
X-Ctpclassification: CTP_IC
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_3895B0FA33E2C44E91AB5A151C9A229A23070CABCRSMSX101amrcor_"
Message-ID: <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-MS-Tnef-Correlator:
X-Extloop1: 1
X-Ironport-Av: E=Sophos;i="5.30,255,1470726000"; d="scan'208,217";a="2572959"
X-Spam-Score: -1.9
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 686472401FC for <cpan-bug+Moose [...] hipster.bestpractical.com>; Tue, 30 Aug 2016 02:34:57 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ8ZBYsv-I-V for <cpan-bug+Moose [...] hipster.bestpractical.com>; Tue, 30 Aug 2016 02:34:54 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 85466240137 for <bug-Moose [...] rt.cpan.org>; Tue, 30 Aug 2016 02:34:54 -0400 (EDT)
Received: (qmail 28047 invoked by alias); 30 Aug 2016 06:34:54 -0000
Received: from mga06.intel.com (HELO mga06.intel.com) (134.134.136.31) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 29 Aug 2016 23:34:50 -0700
Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP; 29 Aug 2016 23:34:44 -0700
Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga005.jf.intel.com with ESMTP; 29 Aug 2016 23:34:44 -0700
Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 29 Aug 2016 23:34:44 -0700
Received: from crsmsx152.amr.corp.intel.com (172.18.7.35) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 29 Aug 2016 23:34:43 -0700
Received: from crsmsx101.amr.corp.intel.com ([169.254.1.191]) by CRSMSX152.amr.corp.intel.com ([169.254.5.166]) with mapi id 14.03.0248.002; Tue, 30 Aug 2016 00:34:42 -0600
Delivered-To: cpan-bug+Moose [...] hipster.bestpractical.com
Subject: Nested roles not flagging conflicts
Return-Path: <thomas.pansino [...] intel.com>
Thread-Index: AdIChb/68ZlY1i8qQpmg5AhRrG9Vvw==
X-RT-Mail-Extension: moose
X-Original-To: cpan-bug+Moose [...] hipster.bestpractical.com
X-Spam-Check-BY: la.mx.develooper.com
Date: Tue, 30 Aug 2016 06:34:42 +0000
X-Spam-Level:
X-MS-Has-Attach:
Thread-Topic: Nested roles not flagging conflicts
X-Originating-Ip: [172.18.205.10]
Accept-Language: en-US
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
From: "Pansino, Thomas" <thomas.pansino [...] intel.com>
X-RT-Interface: Email
Content-Length: 0
content-type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: ascii
Content-Length: 2131
I have some code similar to the following: Show quoted text
> ls
BaseRole.pm ChildRoleA.pm ChildRoleB.pm MyClass.pm test.pl ====== BaseRole.pm ====== package BaseRole; use Moose::Role; sub foo { print("Calling BaseRole::foo\n"); } 1; ====== ChildRoleA.pm ====== package ChildRoleA; use Moose::Role; with 'BaseRole'; sub bar { print("Calling ChildRoleA::bar\n"); } 1; ====== ChildRoleB.pm ====== package ChildRoleB; use Moose::Role; with 'BaseRole'; requires 'bar'; sub foo { print("Calling ChildRoleB::foo\n"); } 1; ====== MyClass.pm ====== package MyClass; use Moose; with 'ChildRoleA'; with 'ChildRoleB'; __PACKAGE__->meta()->make_immutable(); 1; ====== test.pl ====== #!/usr/bin/env perl use v5.14.1; use strict; use warnings; use MyClass; my $class = MyClass->new(); $class->foo(); $class->bar(); Running test.pl produces the following output: Calling BaseRole::foo Calling ChildRoleA::bar When I originally wrote this, I was hoping that the definition of ChildRoleB::foo would override BaseRole::foo since the with call to ChildRoleB comes after the with call to ChildRoleA. After quite a bit of manual reading and Internet research, I realized Moose roles don't really have inheritance like that. The only overriding that's valid would have been a definition for foo in MyClass, therefore having two definitions for foo in two different roles should actually have been flagged as a conflict when MyClass was composed. So first thing - is my understanding correct? You can only override a method from a role with a definition in a composing class? All other conflicting definitions in roles needs to be dealt with via exclusion or aliasing? If so, then the real question is, why is this not being flagged as a conflict? I tested and it does flag correctly in version 2.08, but not in 2.16 if I do the with as two separate statements like it is in my example. If I change it to be a single with call though, it works as expected. My guess is something changed in Moose::Util::apply_all_roles between these two versions. Thoughts?
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: ascii
Content-Length: 8051
MIME-Version: 1.0
In-Reply-To: <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-11151-1473568436-1864.117325-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 315
Download (untitled) / with headers
text/plain 315b
On Tue Aug 30 02:34:58 2016, thomas.pansino@intel.com wrote: Show quoted text
> with 'ChildRoleA'; > with 'ChildRoleB';
This is your problem. If you consume each role separately Moose cannot detect conflicts. You should always consume all of your roles in a single "with" call: with 'ChildRoleA', 'ChildRoleB'; Cheers, -dave
MIME-Version: 1.0
X-Spam-Flag: NO
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.901
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 8EE97240370 for <cpan-bug+Moose [...] hipster.bestpractical.com>; Mon, 12 Sep 2016 13:15:14 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfE02zM3EgNM for <cpan-bug+Moose [...] hipster.bestpractical.com>; Mon, 12 Sep 2016 13:15:12 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 8A5312401AC for <bug-Moose [...] rt.cpan.org>; Mon, 12 Sep 2016 13:15:12 -0400 (EDT)
Received: (qmail 14344 invoked by alias); 12 Sep 2016 17:15:10 -0000
Received: from mga04.intel.com (HELO mga04.intel.com) (192.55.52.120) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 12 Sep 2016 10:15:05 -0700
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP; 12 Sep 2016 10:15:01 -0700
Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 12 Sep 2016 10:15:01 -0700
Received: from fmsmsx151.amr.corp.intel.com (10.18.125.4) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 10:15:00 -0700
Received: from crsmsx102.amr.corp.intel.com (172.18.63.137) by FMSMSX151.amr.corp.intel.com (10.18.125.4) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 10:15:00 -0700
Received: from crsmsx101.amr.corp.intel.com ([169.254.1.191]) by CRSMSX102.amr.corp.intel.com ([169.254.2.5]) with mapi id 14.03.0248.002; Mon, 12 Sep 2016 11:14:58 -0600
Delivered-To: cpan-bug+Moose [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Spam-Check-BY: la.mx.develooper.com
Thread-Index: AdIChb/68ZlY1i8qQpmg5AhRrG9VvwJkkBGAAEAt6IA=
Date: Mon, 12 Sep 2016 17:14:58 +0000
X-Spam-Level:
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
Content-Transfer-Encoding: base64
In-Reply-To: <rt-4.0.18-11151-1473568437-56.117325-6-0 [...] rt.cpan.org>
X-Spam-Status: No, score=-5.901 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, FROM_OUR_RT=-4, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham
X-Titus-Metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjc3ZTEyMTctZWQ4ZS00ZGZlLWI3NGYtZDk5YzAxYjM5NDkxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6InpPTlRCREpVR2hFOHBBSjZIUFBzaHIzQkY2VWp5QVJXUUtmN0FncVZpWEk9In0=
X-RT-Interface: API
X-Ctpclassification: CTP_IC
Content-Language: en-US
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-11151-1473568437-56.117325-6-0 [...] rt.cpan.org>
Message-ID: <3895B0FA33E2C44E91AB5A151C9A229A23076ADC [...] CRSMSX101.amr.corp.intel.com>
X-MS-Tnef-Correlator:
X-Extloop1: 1
X-Ironport-Av: E=Sophos;i="5.30,323,1470726000"; d="scan'208";a="759899027"
Return-Path: <thomas.pansino [...] intel.com>
X-RT-Mail-Extension: moose
X-Original-To: cpan-bug+Moose [...] hipster.bestpractical.com
X-MS-Has-Attach:
Thread-Topic: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Originating-Ip: [172.18.205.10]
Accept-Language: en-US
From: "Pansino, Thomas" <thomas.pansino [...] intel.com>
RT-Message-ID: <rt-4.0.18-18437-1473700515-1171.117325-0-0 [...] rt.cpan.org>
Content-Length: 937
Download (untitled) / with headers
text/plain 937b
Thanks Dave. Shouldn't this be flagged though? As I mentioned it does flag correctly in 2.08, but as of 2.16 it accepts this silently and does the wrong thing. At the very least, the requirement to use only one with call per class is unclear from the documentation and should be updated. -Tom Show quoted text
-----Original Message----- From: Dave Rolsky via RT [mailto:bug-Moose@rt.cpan.org] Sent: Saturday, September 10, 2016 21:34 To: Pansino, Thomas <thomas.pansino@intel.com> Subject: [rt.cpan.org #117325] Nested roles not flagging conflicts <URL: https://rt.cpan.org/Ticket/Display.html?id=117325 > On Tue Aug 30 02:34:58 2016, thomas.pansino@intel.com wrote:
> with 'ChildRoleA'; > with 'ChildRoleB';
This is your problem. If you consume each role separately Moose cannot detect conflicts. You should always consume all of your roles in a single "with" call: with 'ChildRoleA', 'ChildRoleB'; Cheers, -dave
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-18437-1473700515-1171.117325-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-11151-1473568437-56.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076ADC [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-18437-1473700515-1171.117325-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-29265-1473702136-1904.117325-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 660
Download (untitled) / with headers
text/plain 660b
On 2016-09-12 12:15:15, thomas.pansino@intel.com wrote: Show quoted text
> Thanks Dave. > > Shouldn't this be flagged though? As I mentioned it does flag > correctly in 2.08, but as of 2.16 it accepts this silently and does > the wrong thing. > At the very least, the requirement to use only one with call per class > is unclear from the documentation and should be updated.
I'm surprised that this caused an error in 2.08. I'm guessing that maybe it was a _different_ error than the one you get when you consume both roles in a single with statement. I'm pretty surprised the docs don't make a point of mentioning that you should just use one with statement. I'll fix that.
MIME-Version: 1.0
In-Reply-To: <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-29505-1473702374-1870.117325-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 39
MIME-Version: 1.0
X-Spam-Flag: NO
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -3.901
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 7F99524039E for <cpan-bug+Moose [...] hipster.bestpractical.com>; Mon, 12 Sep 2016 14:09:53 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hGb9Bu3JebH for <cpan-bug+Moose [...] hipster.bestpractical.com>; Mon, 12 Sep 2016 14:09:51 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id CBAC624039C for <bug-Moose [...] rt.cpan.org>; Mon, 12 Sep 2016 14:09:48 -0400 (EDT)
Received: (qmail 16645 invoked by alias); 12 Sep 2016 18:09:48 -0000
Received: from mga07.intel.com (HELO mga07.intel.com) (134.134.136.100) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 12 Sep 2016 11:09:45 -0700
Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP; 12 Sep 2016 11:09:35 -0700
Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 12 Sep 2016 11:09:33 -0700
Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 11:09:31 -0700
Received: from crsmsx152.amr.corp.intel.com (172.18.7.35) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 11:09:31 -0700
Received: from crsmsx101.amr.corp.intel.com ([169.254.1.191]) by CRSMSX152.amr.corp.intel.com ([169.254.5.166]) with mapi id 14.03.0248.002; Mon, 12 Sep 2016 12:09:29 -0600
Delivered-To: cpan-bug+Moose [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Spam-Check-BY: la.mx.develooper.com
Thread-Index: AdIChb/68ZlY1i8qQpmg5AhRrG9VvwKyhmKAAAwBIFA=
Date: Mon, 12 Sep 2016 18:09:29 +0000
X-Spam-Level:
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
Content-Transfer-Encoding: base64
In-Reply-To: <rt-4.0.18-29505-1473702375-608.117325-6-0 [...] rt.cpan.org>
X-Spam-Status: No, score=-3.901 tagged_above=-99.9 required=10 tests=[AWL=2.000, BAYES_00=-1.9, FROM_OUR_RT=-4, RP_MATCHES_RCVD=-0.001] autolearn=ham
X-Titus-Metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWRjYjQ2MjAtNzJkZi00ZWE2LTljZTItOGM3NTkxMmU3MTBlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjdiOHYwZDd0VGNFVXBlZU5DVDJXRVhHa09lTVVsUnJ4cklCM0M0R0lRNTA9In0=
X-RT-Interface: API
X-Ctpclassification: CTP_IC
Content-Language: en-US
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-29505-1473702375-608.117325-6-0 [...] rt.cpan.org>
Message-ID: <3895B0FA33E2C44E91AB5A151C9A229A23076BC2 [...] CRSMSX101.amr.corp.intel.com>
X-MS-Tnef-Correlator:
X-Extloop1: 1
X-Ironport-Av: E=Sophos;i="5.30,324,1470726000"; d="scan'208";a="1028864067"
Return-Path: <thomas.pansino [...] intel.com>
X-RT-Mail-Extension: moose
X-Original-To: cpan-bug+Moose [...] hipster.bestpractical.com
X-MS-Has-Attach:
Thread-Topic: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Originating-Ip: [172.18.205.10]
Accept-Language: en-US
From: "Pansino, Thomas" <thomas.pansino [...] intel.com>
RT-Message-ID: <rt-4.0.18-2116-1473703794-1979.117325-0-0 [...] rt.cpan.org>
Content-Length: 833
Download (untitled) / with headers
text/plain 833b
That looks tremendously better, thanks! So follow up question - could this not be flagged? It seems like it would be beneficial to have a bit somewhere that tracks if apply_all_roles (and maybe ensure_all_roles too) was called, and die with an appropriate error if called more than once. That would cover my case with multiple with calls as well as anyone who is doing dynamic Role addition to individual classes (I think?) which would also be at risk for this masking behavior. Show quoted text
-----Original Message----- From: Dave Rolsky via RT [mailto:bug-Moose@rt.cpan.org] Sent: Monday, September 12, 2016 10:46 To: Pansino, Thomas <thomas.pansino@intel.com> Subject: [rt.cpan.org #117325] Nested roles not flagging conflicts <URL: https://rt.cpan.org/Ticket/Display.html?id=117325 > https://github.com/moose/Moose/pull/133
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-2116-1473703794-1979.117325-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-29505-1473702375-608.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076BC2 [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-2116-1473703794-1979.117325-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-7332-1473703953-1723.117325-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 956
Download (untitled) / with headers
text/plain 956b
On 2016-09-12 13:09:54, thomas.pansino@intel.com wrote: Show quoted text
> That looks tremendously better, thanks! > > So follow up question - could this not be flagged? It seems like it > would be beneficial to have a bit somewhere that tracks if > apply_all_roles (and maybe ensure_all_roles too) was called, and die > with an appropriate error if called more than once. That would cover > my case with multiple with calls as well as anyone who is doing > dynamic Role addition to individual classes (I think?) which would > also be at risk for this masking behavior.
There are valid (corner) use cases for calling "with" more than once because of various limitations in how roles work. But generally speaking, unless you encounter such a case you should consume all your roles in one shot. To do what you're suggesting would require roles to work more like a compile-time thing, which would be very hard to do in Perl 5 as it stands now. But Perl 6 gets this right ;)
MIME-Version: 1.0
X-Spam-Flag: NO
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -7.401
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 1674E240369 for <cpan-bug+Moose [...] hipster.bestpractical.com>; Mon, 12 Sep 2016 14:29:55 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4M7+PRPE+eS for <cpan-bug+Moose [...] hipster.bestpractical.com>; Mon, 12 Sep 2016 14:29:53 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 4DD20240365 for <bug-Moose [...] rt.cpan.org>; Mon, 12 Sep 2016 14:29:53 -0400 (EDT)
Received: (qmail 17503 invoked by alias); 12 Sep 2016 18:29:52 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 12 Sep 2016 11:29:44 -0700
Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP; 12 Sep 2016 11:29:40 -0700
Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga005.fm.intel.com with ESMTP; 12 Sep 2016 11:29:40 -0700
Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 11:29:40 -0700
Received: from crsmsx152.amr.corp.intel.com (172.18.7.35) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 11:29:39 -0700
Received: from crsmsx101.amr.corp.intel.com ([169.254.1.191]) by CRSMSX152.amr.corp.intel.com ([169.254.5.166]) with mapi id 14.03.0248.002; Mon, 12 Sep 2016 12:29:38 -0600
Delivered-To: cpan-bug+Moose [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Spam-Check-BY: la.mx.develooper.com
Thread-Index: AdIChb/68ZlY1i8qQpmg5AhRrG9VvwKyhmKAAAwBIFD//0LTj////ryg
Date: Mon, 12 Sep 2016 18:29:38 +0000
X-Spam-Level:
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
Content-Transfer-Encoding: base64
In-Reply-To: <rt-4.0.18-7332-1473703953-1501.117325-6-0 [...] rt.cpan.org>
X-Spam-Status: No, score=-7.401 tagged_above=-99.9 required=10 tests=[AWL=3.500, BAYES_00=-1.9, FROM_OUR_RT=-4, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
X-Titus-Metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGY4YTM3YzEtZDM0Yy00MWRmLThlMWQtZDZlMmU3NzI4YzMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImFVRXJ2UTBvMXYxcmFTeHRzOE8zTjFGV3UydVVHS013SFhiSDVYRnIrbkk9In0=
X-RT-Interface: API
X-Ctpclassification: CTP_IC
Content-Language: en-US
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-29505-1473702375-608.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076BC2 [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-2116-1473703794-1979.117325-6-0 [...] rt.cpan.org> <rt-4.0.18-7332-1473703953-1501.117325-6-0 [...] rt.cpan.org>
Message-ID: <3895B0FA33E2C44E91AB5A151C9A229A23076C12 [...] CRSMSX101.amr.corp.intel.com>
X-MS-Tnef-Correlator:
X-Extloop1: 1
X-Ironport-Av: E=Sophos;i="5.30,324,1470726000"; d="scan'208";a="7444831"
Return-Path: <thomas.pansino [...] intel.com>
X-RT-Mail-Extension: moose
X-Original-To: cpan-bug+Moose [...] hipster.bestpractical.com
X-MS-Has-Attach:
Thread-Topic: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Originating-Ip: [172.18.205.10]
Accept-Language: en-US
From: "Pansino, Thomas" <thomas.pansino [...] intel.com>
RT-Message-ID: <rt-4.0.18-7352-1473704995-936.117325-0-0 [...] rt.cpan.org>
Content-Length: 2074
Show quoted text
> There are valid (corner) use cases for calling "with" more than once because of various limitations in how roles work.
Of course, it always breaks somebody ;) I guess what I'm more concerned with is Moose silently retaining the first sub definition despite other definitions being applied in later roles. It seems to go against Moose's mantra of requiring conflicts be explicitly resolved by the developer, which to me is one of the big safety features here. The documentation update will at least keep people on the fairway now and out of the rough patch I was in, but I think if the intention is to flag any duplicate definitions in roles, then this should be a case where it flags too. Thoughts? Thanks for all that you do btw, really appreciate your contributions as a whole. Show quoted text
-----Original Message----- From: Dave Rolsky via RT [mailto:bug-Moose@rt.cpan.org] Sent: Monday, September 12, 2016 11:13 To: Pansino, Thomas <thomas.pansino@intel.com> Subject: [rt.cpan.org #117325] Nested roles not flagging conflicts <URL: https://rt.cpan.org/Ticket/Display.html?id=117325 > On 2016-09-12 13:09:54, thomas.pansino@intel.com wrote:
> That looks tremendously better, thanks! > > So follow up question - could this not be flagged? It seems like it > would be beneficial to have a bit somewhere that tracks if > apply_all_roles (and maybe ensure_all_roles too) was called, and die > with an appropriate error if called more than once. That would cover > my case with multiple with calls as well as anyone who is doing > dynamic Role addition to individual classes (I think?) which would > also be at risk for this masking behavior.
There are valid (corner) use cases for calling "with" more than once because of various limitations in how roles work. But generally speaking, unless you encounter such a case you should consume all your roles in one shot. To do what you're suggesting would require roles to work more like a compile-time thing, which would be very hard to do in Perl 5 as it stands now. But Perl 6 gets this right ;)
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-7352-1473704995-936.117325-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-29505-1473702375-608.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076BC2 [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-2116-1473703794-1979.117325-6-0 [...] rt.cpan.org> <rt-4.0.18-7332-1473703953-1501.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076C12 [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-7352-1473704995-936.117325-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-7352-1473705720-21.117325-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1777
Download (untitled) / with headers
text/plain 1.7k
On 2016-09-12 13:29:55, thomas.pansino@intel.com wrote: Show quoted text
> > There are valid (corner) use cases for calling "with" more than once > > because of various limitations in how roles work.
> Of course, it always breaks somebody ;) > > I guess what I'm more concerned with is Moose silently retaining the > first sub definition despite other definitions being applied in later > roles. It seems to go against Moose's mantra of requiring conflicts be > explicitly resolved by the developer, which to me is one of the big > safety features here. The documentation update will at least keep > people on the fairway now and out of the rough patch I was in, but I > think if the intention is to flag any duplicate definitions in roles, > then this should be a case where it flags too. > > Thoughts? Thanks for all that you do btw, really appreciate your > contributions as a whole.
Patches welcome, but this could be really challenging. Keep in mind that when a class consumes a role with a method of the same name, it is _intentional_ that the class's version silently wins. This allow classes to override roles, which is a feature. In the two-with situation, the second with sees the methods from the first role as being part of the class, not as being role methods. Now we _do_ keep track of where methods came from, so in theory we could check that and die, _but_ there are all sorts of corner cases I could imagine here. Only dying when necessary while still allowing meta-fun trickery could range from difficult to impossible. That said, it has _always_ been the intention that you only call with just once, which is why I was so surprised it wasn't mentioned in the docs. It's been "common" knowledge among Moose users for a really long time, but obviously explicit is better.
MIME-Version: 1.0
X-Spam-Flag: NO
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -6.068
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 0E5CE240396 for <cpan-bug+Moose [...] hipster.bestpractical.com>; Tue, 13 Sep 2016 17:07:37 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjGWKRkk2E41 for <cpan-bug+Moose [...] hipster.bestpractical.com>; Tue, 13 Sep 2016 17:07:35 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id D1F8F24035F for <bug-Moose [...] rt.cpan.org>; Tue, 13 Sep 2016 17:07:34 -0400 (EDT)
Received: (qmail 20408 invoked by alias); 13 Sep 2016 21:07:34 -0000
Received: from mga07.intel.com (HELO mga07.intel.com) (134.134.136.100) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 13 Sep 2016 14:07:28 -0700
Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 13 Sep 2016 14:07:21 -0700
Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by FMSMGA003.fm.intel.com with ESMTP; 13 Sep 2016 14:07:20 -0700
Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 13 Sep 2016 14:07:20 -0700
Received: from crsmsx102.amr.corp.intel.com (172.18.63.137) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 13 Sep 2016 14:07:20 -0700
Received: from crsmsx101.amr.corp.intel.com ([169.254.1.191]) by CRSMSX102.amr.corp.intel.com ([169.254.2.5]) with mapi id 14.03.0248.002; Tue, 13 Sep 2016 15:07:18 -0600
Delivered-To: cpan-bug+Moose [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Spam-Check-BY: la.mx.develooper.com
Thread-Index: AdIChb/68ZlY1i8qQpmg5AhRrG9VvwKyhmKAAAwBIFD//0LTj////ryggAAJcuj//koqoA==
Date: Tue, 13 Sep 2016 21:07:17 +0000
X-Spam-Level:
To: "bug-Moose [...] rt.cpan.org" <bug-Moose [...] rt.cpan.org>
Content-Transfer-Encoding: base64
In-Reply-To: <rt-4.0.18-7352-1473705721-136.117325-6-0 [...] rt.cpan.org>
X-Spam-Status: No, score=-6.068 tagged_above=-99.9 required=10 tests=[AWL=-0.167, BAYES_00=-1.9, FROM_OUR_RT=-4, RP_MATCHES_RCVD=-0.001] autolearn=ham
X-Titus-Metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzhhZjQzNDQtNWM3YS00MjY5LWJhMzItNjc5NWViNTk2ZmQ5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Imo2SzJ2clwvcW9qOU93ZzYxN05BdzNxYUhjMTRwZkhHOVI2Q3pLRVZ5R2t3PSJ9
X-RT-Interface: API
X-Ctpclassification: CTP_IC
Content-Language: en-US
References: <RT-Ticket-117325 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23070CAB [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-29505-1473702375-608.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076BC2 [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-2116-1473703794-1979.117325-6-0 [...] rt.cpan.org> <rt-4.0.18-7332-1473703953-1501.117325-6-0 [...] rt.cpan.org> <3895B0FA33E2C44E91AB5A151C9A229A23076C12 [...] CRSMSX101.amr.corp.intel.com> <rt-4.0.18-7352-1473704995-936.117325-6-0 [...] rt.cpan.org> <rt-4.0.18-7352-1473705721-136.117325-6-0 [...] rt.cpan.org>
Message-ID: <3895B0FA33E2C44E91AB5A151C9A229A230775E9 [...] CRSMSX101.amr.corp.intel.com>
X-MS-Tnef-Correlator:
X-Extloop1: 1
X-Ironport-Av: E=Sophos;i="5.30,330,1470726000"; d="scan'208";a="760364448"
Return-Path: <thomas.pansino [...] intel.com>
X-RT-Mail-Extension: moose
X-Original-To: cpan-bug+Moose [...] hipster.bestpractical.com
X-MS-Has-Attach:
Thread-Topic: [rt.cpan.org #117325] Nested roles not flagging conflicts
X-Originating-Ip: [172.18.205.10]
Accept-Language: en-US
From: "Pansino, Thomas" <thomas.pansino [...] intel.com>
RT-Message-ID: <rt-4.0.18-25072-1473800858-1244.117325-0-0 [...] rt.cpan.org>
Content-Length: 3248
Download (untitled) / with headers
text/plain 3.1k
Show quoted text
> Keep in mind that when a class consumes a role with a method of the same name, it is _intentional_ that the class's version silently wins.
Right, but actually I originally expected that the second role would override methods from the first role, kind of like how inheritance works. I think that was where I went wrong - treating roles like they would inherit, which is why having a safeguard to flag if someone _else_ tries to do that would be useful I think. But I'm not familiar enough with Moose internals to pull that off yet, and you all are busy doing other things, so documentation is probably enough for now. If I ever decide to go after this I'll reach out to you, get a feel for some of those corner cases you're thinking of that I might not know about. Show quoted text
> It's been "common" knowledge among Moose users for a really long time, but obviously explicit is better.
I think that was the missing part - I don't know many other Moose users and am just getting into using Moose heavily on a project. The documentation so far has been excellent, kudos to you all for that, it just needed that missing part. Thanks! Show quoted text
-----Original Message----- From: Dave Rolsky via RT [mailto:bug-Moose@rt.cpan.org] Sent: Monday, September 12, 2016 11:42 To: Pansino, Thomas <thomas.pansino@intel.com> Subject: [rt.cpan.org #117325] Nested roles not flagging conflicts <URL: https://rt.cpan.org/Ticket/Display.html?id=117325 > On 2016-09-12 13:29:55, thomas.pansino@intel.com wrote:
> > There are valid (corner) use cases for calling "with" more than once > > because of various limitations in how roles work.
> Of course, it always breaks somebody ;) > > I guess what I'm more concerned with is Moose silently retaining the > first sub definition despite other definitions being applied in later > roles. It seems to go against Moose's mantra of requiring conflicts be > explicitly resolved by the developer, which to me is one of the big > safety features here. The documentation update will at least keep > people on the fairway now and out of the rough patch I was in, but I > think if the intention is to flag any duplicate definitions in roles, > then this should be a case where it flags too. > > Thoughts? Thanks for all that you do btw, really appreciate your > contributions as a whole.
Patches welcome, but this could be really challenging. Keep in mind that when a class consumes a role with a method of the same name, it is _intentional_ that the class's version silently wins. This allow classes to override roles, which is a feature. In the two-with situation, the second with sees the methods from the first role as being part of the class, not as being role methods. Now we _do_ keep track of where methods came from, so in theory we could check that and die, _but_ there are all sorts of corner cases I could imagine here. Only dying when necessary while still allowing meta-fun trickery could range from difficult to impossible. That said, it has _always_ been the intention that you only call with just once, which is why I was so surprised it wasn't mentioned in the docs. It's been "common" knowledge among Moose users for a really long time, but obviously explicit is better.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.