Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Mouse CPAN distribution.

Report information
The Basics
Id: 63675
Status: resolved
Priority: 0/
Queue: Mouse

People
Owner: Nobody in particular
Requestors: rt.cpan [...] sartak.org
Cc:
AdminCc:

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



Subject: Non-Mouse class inheritance warning hurts
Hey Goro, The new warning in Mouse, "You inherit from non-Mouse class (...), but it is unlikely to work correctly. Please consider using MouseX::Foreign" is hurting our users. For example, http://lists.jifty.org/pipermail/jifty-devel/2010-December/002392.html and several users in #prophet on freenode. A way to silence this warning with an environment or global variable would be welcome. Having to extend (or monkeypatch) Mouse::Meta::Class just to silence a warning we don't want would be unfortunate. Shawn
It's also possible that Mouse could actually *check* for breakage before warning, by looking for attributes with default/builder without lazy, BUILD or BUILDARGs, etc.
Subject: Re: [rt.cpan.org #63675] Non-Mouse class inheritance warning hurts
Date: Mon, 06 Dec 2010 23:05:34 +0100
To: bug-Mouse [...] rt.cpan.org
From: Florian Ragwitz <rafl [...] debian.org>
"Shawn M Moore via RT" <bug-Mouse@rt.cpan.org> writes: Show quoted text
> It's also possible that Mouse could actually *check* for breakage > before warning, by looking for attributes with default/builder without > lazy, BUILD or BUILDARGs, etc.
I feel a little stronger about this than Shawn. I see how this warning is trying to be helpful and prevent users from accidentally doing something they didn't intent. However, it hurts a lot of users that legitimately inherit from non-Mouse classes without using MouseX::Foreign, like when doing what Shawn described above. Unfortunately though, I don't think the approach he suggests is a very good one. It's not possible to detect all cases where inheriting from non-Mouse classes without MouseX::Foreign would cause trouble. While trying to do that might very well alleviate some of the suffering, it doesn't fix the actual problem, and the other suggestion of introducing an environment variable to turn the warning off won't either. I would like to suggest removing this warning or at least making it opt-in instead of opt-out. Users could, if they want the additional "safety", set an environment variable, pass an additional import() argument, or maybe even load a Mouse::Strict instead of Mouse, to enable this warning, and possibly future other ones. Also, as far as I understand the philosophy behind Mouse, it's a declared goal to be as close as possible to Moose's behaviour, at least as far as the basic user-facing interface is concerned. Moose doesn't issue a warning like that, so Mouse probably doesn't want to do that either. I'm all in favour of helping users out by providing useful errors and warnings in case it's clear that they actually did something wrong. However, detecting that in this case isn't quite possible.
Download (untitled)
application/pgp-signature 197b

Message body not shown because it is not plain text.

FWIW this warning just saved me a lot of debugging. I was writing a Plack::Middleware subclass using Mouse. It was behaving very oddly and the warning pointed exactly at the problem. I was going to make a request that MouseX::Foreign's functionality be added to Mouse when I saw this ticket. If you're going to reference MouseX::Foreign, don't make the user go have to deal with a dependency for a common problem, just include it. It's tiny. The warning did its job. If it's sometimes overzealous, that's why it's a warning and not an error. Analogously, sometimes you really mean to use an uninitialized variable, but you'll go through a few more hoops to initialize it rather than turn the warning off. The answer is to provide two built in ways to safely inherit from a non-Mouse class. One that does what MouseX::Foreign does. One that says to Mouse "I know what I'm doing, shut up" to silence the warning. This is something that I understand would have to be pushed up into Moose and back down again. As for making it opt-in, most users don't know that you can't inherit from a non-Mouse class and won't know to look for some warning to turn on. Things will just mysteriously and silently not work. If the warning is going to be opt-in, just remove it.
0.89 2011-01-27 09:18:39 [BUG FIXES] * Disable foreign class warnings introduced at 0.71, which affects compatibility with Moose (and will re-introduce in more compatible way in the future)