Re^2: Introducing MooseX::hasn't

The link you posted doesn't work.

Thanks, fixed.

If it doesn't support the same operations as Person then in what sense does it extend Person?

See "Doesn't this break polymorphism?" in the FAQ.

Or is this meant to be an Acme type module?

Initially, yes, hence the release date. But I can see potential uses for it.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Comment on Re^2: Introducing MooseX::hasn't

Replies are listed 'Best First'.
Re^3: Introducing MooseX::hasn't by Arunbear (Prior) on Apr 03, 2012 at 10:23 UTC
It breaks the inheritance contract, not polymorphism per se (I think you've got the two concepts confused). Polymorphism doesn't depend on inheritance, e.g. Roles enable polymorphism without inheritance.	[reply]
Re^4: Introducing MooseX::hasn't by tobyink (Canon) on Apr 03, 2012 at 13:14 UTC
No, polymorphism doesn't depend on inheritance, and I never claimed that it did. Polymorphism is generally an expected outcome of inheritance though. There are clearly other ways of allowing polymorphism though - roles as you say; also mocking, delegation, etc. `perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'`	[reply]
Re^5: Introducing MooseX::hasn't by Arunbear (Prior) on Apr 03, 2012 at 17:58 UTC
From the POD: The idea behind polymorphism is that if Bar inherits from Foo, then I should be able to use an object of type Bar wherever I'd normally use Foo. That makes it sound like you're equating polymorphism with inheritance.	[reply]