* demerphq <[EMAIL PROTECTED]> [2008-01-04 00:00]:
> Consider that with 5.10 its possible to use other method
> resolution rules than the one your snippet mimics.
Does it change the MRO globally without regard for whether any
loaded classes are prepared for that?
Regards,
--
Aristotle Pagaltzis
On 03/01/2008, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote:
> * Andy Armstrong <[EMAIL PROTECTED]> [2008-01-03 18:25]:
> > On 3 Jan 2008, at 16:55, Ovid wrote:
> >> my $super = __PACKAGE__->can("SUPER::$sub") or die;
> >>
> >> This is OO code and that should actually read:
> >>
> >> my $super =
On 3 Jan 2008, at 21:02, Aristotle Pagaltzis wrote:
No. That calls `can` from the superclass, but passes
`__PACKAGE__` as the invocant. Assuming that the subclass and the
superclass use the same inherited `can` method, the result is
therefore exactly the same.
The correct incantation is
my (
* Andy Armstrong <[EMAIL PROTECTED]> [2008-01-03 18:25]:
> On 3 Jan 2008, at 16:55, Ovid wrote:
>> my $super = __PACKAGE__->can("SUPER::$sub") or die;
>>
>> This is OO code and that should actually read:
>>
>> my $super = __PACKAGE__->can($sub) or die;
>
> Should that be __PACKAGE__->SUPER::can($
On 03/01/2008, chromatic <[EMAIL PROTECTED]> wrote:
> On Thursday 03 January 2008 09:58:28 demerphq wrote:
>
> > And thinking about it more i think that was the whole point of the
> > weird call, Im guessing here, but probably this code isnt in a method
> > which means that he doesnt have access to
On Thursday 03 January 2008 09:58:28 demerphq wrote:
> And thinking about it more i think that was the whole point of the
> weird call, Im guessing here, but probably this code isnt in a method
> which means that he doesnt have access to SUPER so, he passes it into
> can() which does.
>
> The foll
On 03/01/2008, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 3 Jan 2008, at 17:20, Andy Armstrong wrote:
> >> my $super = __PACKAGE__->can($sub) or die;
> >
> > Should that be __PACKAGE__->SUPER::can($sub) ?
>
>
> Hmm. Does that do what I think it does? Maybe not.
Without looking at the code we d
On 03/01/2008, Ovid <[EMAIL PROTECTED]> wrote:
> --- demerphq <[EMAIL PROTECTED]> wrote:
>
> > > The problem is this line in Template::Timer:
> > >
> > > my $super = __PACKAGE__->can("SUPER::$sub") or die;
> > >
> > > This is OO code and that should actually read:
> > >
> > > my $super = __PACK
On 3 Jan 2008, at 17:20, Andy Armstrong wrote:
my $super = __PACKAGE__->can($sub) or die;
Should that be __PACKAGE__->SUPER::can($sub) ?
Hmm. Does that do what I think it does? Maybe not.
And talking to yourself? What's all that about?
--
Andy Armstrong, Hexten
On 3 Jan 2008, at 16:55, Ovid wrote:
my $super = __PACKAGE__->can("SUPER::$sub") or die;
This is OO code and that should actually read:
my $super = __PACKAGE__->can($sub) or die;
Should that be __PACKAGE__->SUPER::can($sub) ?
--
Andy Armstrong, Hexten
--- demerphq <[EMAIL PROTECTED]> wrote:
> > The problem is this line in Template::Timer:
> >
> > my $super = __PACKAGE__->can("SUPER::$sub") or die;
> >
> > This is OO code and that should actually read:
> >
> > my $super = __PACKAGE__->can($sub) or die;
>
> Er, i dont see how it could. Then
On 03/01/2008, Ovid <[EMAIL PROTECTED]> wrote:
> I mentioned that we removed UNIVERSAL::can because of bugs introduced
> by global behavior changes, but to be fair to chromatic, I should
> explain that this is because of code in Template::Timer:
>
> perl -MUNIVERSAL::can -MTemplate::Timer -e 1
>
I mentioned that we removed UNIVERSAL::can because of bugs introduced
by global behavior changes, but to be fair to chromatic, I should
explain that this is because of code in Template::Timer:
perl -MUNIVERSAL::can -MTemplate::Timer -e 1
Died at lib/perl5/Template/Timer.pm line 63.
Compilati
13 matches
Mail list logo
