Prev: very important web site to post you know your political protests....
Next: FAQ 3.13 How can I use curses with Perl?
From: Ilya Zakharevich on 6 Feb 2010 20:30
On 2010-02-06, Ben Morrow <ben(a)morrow.me.uk> wrote:
> [1] I consider the fact that fallback => 1 isn't the default to be a bug
> in the perl overloading system, but it's much too late to change
> that now. Apart from anything else, any new overloads (like the -X
> overload that will be in 5.12) must behave as though fallback=>1
> were specified, for compatibility.

If you think so, just make overload::simple which has a different
default for `fallback'.

In my first experiments, I saw that the behaviour with {fallback =>
1} was too error-prone - it was very hard for the developer to see
whether the codepath was through convert-to-Perlish-data methods, or
through the "specialized operations" methods.

So I made the default 0.

Hope this helps,
Ilya
From: Daniel Molina Wegener on 7 Feb 2010 23:34
On Sáb 06 Feb 2010 19:42,
Ben Morrow wrote:

>
> Quoth dmw(a)coder.cl:
>> -----BEGIN PGP SIGNED MESSAGE-----
>
> Please don't do that here.

Sorry for that...

>
>> Well, the error is clear. The /find()/ method returns a Nodelist
>> object, so you are trying to miltiply $books and $pages which are
>> both XML::LibXML::Nodelist objects.
>>
>> Try using something like:
>>
>> $books = int($books->string_value());
>
> The 'int()' is unnecessary, and unclear (since it implies
> $books->string_value might be a float we wish to truncate to an
> integer),

Well, I've proposed the integer conversion since the program
is counting the amount of books, and certainly I the program do
not exposes any calculation with that value. So I've assumed that
Faith was requiring an integer value.

Thanks for your clarification...

>
> Ben

Best regards,
--
Daniel Molina Wegener <dmw [at] coder [dot] cl>
Software Architect, System Programmer & Web Developer
Phone: +1 (510) 629-4267 | Blog: http://coder.cl/
From: Ben Morrow on 8 Feb 2010 18:26

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-02-06, Ben Morrow <ben(a)morrow.me.uk> wrote:
> > [1] I consider the fact that fallback => 1 isn't the default to be a bug
> > in the perl overloading system, but it's much too late to change
> > that now. Apart from anything else, any new overloads (like the -X
> > overload that will be in 5.12) must behave as though fallback=>1
> > were specified, for compatibility.

[I had forgotten you were the one to originally implement overloading.
Just to be clear, the above was in no way intended as any sort of veiled
personal attack.]

> If you think so, just make overload::simple which has a different
> default for `fallback'.

That doesn't help in this case, where someone has written a class that
doesn't use fallback when IMHO it should. It's very unusual in Perl to
have a value that will stringify but won't numify, so one shouldn't be
created without a very good reason.

> In my first experiments, I saw that the behaviour with {fallback =>
> 1} was too error-prone - it was very hard for the developer to see
> whether the codepath was through convert-to-Perlish-data methods, or
> through the "specialized operations" methods.
>
> So I made the default 0.

I can see that might be a problem, though I think it's one the developer
has to deal with anyway. Would you agree with me that new overload types
*must* default to falling back, and that this is then unnecessarily
confusing, with some overloads honouring 'fallback' and some not?

Ben

From: Ilya Zakharevich on 9 Feb 2010 00:20
On 2010-02-08, Ben Morrow <ben(a)morrow.me.uk> wrote:
>> > [1] I consider the fact that fallback => 1 isn't the default to be a bug
>> > in the perl overloading system, but it's much too late to change
>> > that now. Apart from anything else, any new overloads (like the -X
>> > overload that will be in 5.12) must behave as though fallback=>1
>> > were specified, for compatibility.

> [I had forgotten you were the one to originally implement overloading.
> Just to be clear, the above was in no way intended as any sort of veiled
> personal attack.]

Hmm, I do not see anything resembling a personal attack... Anyway,
the fact that I replied is a good indication that I have not
considered it so. ;-)

>> If you think so, just make overload::simple which has a different
>> default for `fallback'.

> That doesn't help in this case, where someone has written a class that
> doesn't use fallback when IMHO it should.

Definitely. I saw (and still see) no way to find a silver bullet
which would make things much simpler...

>> In my first experiments, I saw that the behaviour with {fallback =>
>> 1} was too error-prone - it was very hard for the developer to see
>> whether the codepath was through convert-to-Perlish-data methods, or
>> through the "specialized operations" methods.
>>
>> So I made the default 0.

> I can see that might be a problem, though I think it's one the developer
> has to deal with anyway.

With default being 1, it would be much harder for them to see the
problem. The current way, it is much more probable that *they* would
see the problem first, so the users would have less problems...

> Would you agree with me that new overload types
> *must* default to falling back

How would "new" types be different from the "old" ones? The problem
existed back then; what changed?

> this is then unnecessarily confusing, with some overloads honouring
> 'fallback' and some not?

Confusing: yes. "Unnecessarily"? Do not think so. The complexity is
there, it is not an artificial one...

Yours,
Ilya
From: Ben Morrow on 9 Feb 2010 08:26

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-02-08, Ben Morrow <ben(a)morrow.me.uk> wrote:
>
> >> In my first experiments, I saw that the behaviour with {fallback =>
> >> 1} was too error-prone - it was very hard for the developer to see
> >> whether the codepath was through convert-to-Perlish-data methods, or
> >> through the "specialized operations" methods.
> >>
> >> So I made the default 0.
>
> > I can see that might be a problem, though I think it's one the developer
> > has to deal with anyway.
>
> With default being 1, it would be much harder for them to see the
> problem. The current way, it is much more probable that *they* would
> see the problem first, so the users would have less problems...

Yes, I suppose that's true. Certainly, there are no easy answers here.

> > Would you agree with me that new overload types
> > *must* default to falling back
>
> How would "new" types be different from the "old" ones? The problem
> existed back then; what changed?

What changed is that there are now published classes that use some
overloading, don't specify fallback, and don't overload the new type.
Take for example the new "qr" overload. Under 5.10 and earlier, treating
an object as a regex would invoke the stringify overload, so 5.12 must
continue to do so for objects that don't have a qr overload *even* if
fallback was not requested.

Ben

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: very important web site to post you know your political protests....
Next: FAQ 3.13 How can I use curses with Perl?