Chaim Frenkel wrote:
> > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> GL> There is a difference between "undefined" and "unknown".
>
> GL> Perl undefined is a different concept--that of an uninitialized
> GL> variable. This is proven from its earliest versions where the
> GL> valu
> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
GL> There is a difference between "undefined" and "unknown".
GL> Perl undefined is a different concept--that of an uninitialized
GL> variable. This is proven from its earliest versions where the
GL> value is coerced to 0 or '' (specific
At this point, I think the whole thread on functions throwing
exceptions should either be:
(a) turned into an RFC
or
(b) abandoned.
This discussion is going around and around like a piece of toilet
paper in a weakly-flushing toilet.
Nat
John Porter wrote:
> Glenn Linderman wrote:
> >
> > The idea of a _normal_ situation being considered exceptional is raised when the
> > code written inappropriately handles some of the normal return values.
>
> You would throw exceptions at the problem of bad coding practice.
Not the goal. The
Glenn Linderman wrote:
>
> There is a difference between "undefined" and "unknown".
Can you explain this difference, briefly?
If not, could you give me something off-list?
Thanks,
John Porter
Glenn Linderman wrote:
>
> The idea of a _normal_ situation being considered exceptional is raised when the
> code written inappropriately handles some of the normal return values.
You would throw exceptions at the problem of bad coding practice.
I think it's better to correct the bad coding p
Chaim Frenkel wrote:
> What about a hypothetical, use tristate. This would give undef some
> extra special powers.
There is a difference between "undefined" and "unknown".
SQL NULL, and the resultant tristate operators used in SQL, specifically is based
on NULL representing the "unknown" value.
Chaim Frenkel wrote:
> > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> >> Neither is EOF on a file, or working with an empty list. Adding all these
> >> exceptions for non-exceptional and quite common scenerios is bothersome.
>
> I don't know where this idea of a _normal_ situation
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> I would like to have an undef returned.
NT> Ah, I see. You want subroutines to return undef if they're given it
NT> for any of their arguments. That'd break the lazy programmer practice
NT> of passing unde
> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>> Neither is EOF on a file, or working with an empty list. Adding all these
>> exceptions for non-exceptional and quite common scenerios is bothersome.
GL> Now the loop works fine, but somehow, we need to get out of the
GL> loop when we
Chaim Frenkel wrote:
> But you would still have to catch the exception. Not a nice thing to
> terminate the program just because an expected mismatch occured.
Sometimes it is, sometimes it isn't.
> Not finding something is not exceptional.
Sometimes it is, sometimes it isn't. Why were you loo
> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
GL> That's exactly why it would be nice if index _did_ throw an exception on
GL> failure, then you could write code this way, and catch the failures
GL> without needing to check return values for the error code case before
GL> proceeding w
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> Chaim Frenkel wrote:
>>
>> Removing -1 as a valid result, could be a breakage (if someone is
>> doing something weird with a negative result)
JP> What, like using it as an index into a substr?
JP> Bad Code is its own reward, my friend.
Chaim Frenkel writes:
> I would like to have an undef returned.
Ah, I see. You want subroutines to return undef if they're given it
for any of their arguments. That'd break the lazy programmer practice
of passing undef expecting it to become "" or 0. They don't have
warnings on, of course.
Na
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> Somehow I find
>> if (40 == ($foo = substr($bar, index($bar, 'xyz' {
>> }
NT> I don't understand your hypothetical code. substr() returns the
NT> substring of $bar from the position retutned by index, o
John Porter wrote:
> Chaim Frenkel wrote:
> >
> > Removing -1 as a valid result, could be a breakage (if someone is
> > doing something weird with a negative result)
>
> What, like using it as an index into a substr?
> Bad Code is its own reward, my friend.
>
> > $foo = "flabergasted";
> >
Chaim Frenkel wrote:
>
> Removing -1 as a valid result, could be a breakage (if someone is
> doing something weird with a negative result)
What, like using it as an index into a substr?
Bad Code is its own reward, my friend.
> $foo = "flabergasted";
> substr($foo, index($foo, 'abc'
Chaim Frenkel writes:
> Somehow I find
> if (40 == ($foo = substr($bar, index($bar, 'xyz' {
> }
I don't understand your hypothetical code. substr() returns the
substring of $bar from the position retutned by index, onward.
When would this be 40, if index is going to return the po
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
>> Would it be reasonable to ask that passing undef into the offset
>> or start of substr have substr return an undef?
NT> Wouldn't you get a warning anyway, if you were treating undef like
NT> a number?
Aha, but I don't want a warning
Chaim Frenkel writes:
> Removing -1 as a valid result, could be a breakage (if someone is
> doing something weird with a negative result)
I don't care, so long as the perl526 translator can wrap perl6's
index/rindex. And I gave sample code for it to do that.
> Would it be reasonable to ask that
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> In perl5, index() and rindex() return -1 if the
PRL> substring isn't found. This seems out of step with
PRL> the rest of Perl's functions, which return C
PRL> on error. I propose changing index() and rindex()
PRL> to return C i
Tom Christiansen wrote:
>
> Speaking of failure-mode, all syscalls should return false on failure, not
> ever -1. Right now, wait and waitpid work the other way. They should
> go the undef vs "0 but true" route that ioctl, fcntl, and sysread take.
And system()!
But I'm pretty sure you meant t
Speaking of failure-mode, all syscalls should return false on failure, not
ever -1. Right now, wait and waitpid work the other way. They should
go the undef vs "0 but true" route that ioctl, fcntl, and sysread take.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
rindex and index should return undef on failure
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Sep 12 2000
Mailing List: [EMAIL PROTECTED]
Number: 213
Version: 1
Status:
24 matches
Mail list logo
