Buddha Buck wrote:
On RFC 204 (LOL refs as indices), I have followed the discussion from
Ilya that list references will have problems when objects that used
blessed references to lists as their internal representation are used
as indices. This does indeed seem to be a problem, but I'm
Bart Lateur wrote:
On 20 Sep 2000 04:07:27 -, Perl6 RFC Librarian wrote:
Where an array is declared without ':bounds', @# returns the largest
bounds of each dimension that has been accessed:
Wouldn't that be slow?
It depends. The array creation RFC proposes that LOLs declared with a
At 13:23 +0200 2000.09.20, Bart Lateur wrote:
This surely was a bad design decision from the hardware guys. Very
shortsighted.
I don't know if it has anything to do with the hardware clock. It has to
do with what the Mac OS API returns for seconds since epoch. The
difference from GMT, or the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should have a print operator
=head1 VERSION
Maintainer: Jon Ericson [EMAIL PROTECTED]
Date: 5 Aug 2000
Last Modified: 20 Sept 2000
Mailing List: [EMAIL PROTECTED]
Number: 39
Version: 4
The DBI has this very problem! DBI-connect() returns DBI::db
objects, DBI-prepare() returns DBI::st. If you want to override the
behavior for statement handles and connections, its not enough to just
subclass DBI::st and DBI::db, you must also subclass DBI and override
connect() and prepare()
I haven't (and won't) have time to go into this in detail :-(
I feel that this proposal is solving the wrong problem. The issue is
that the original Forest and Frog (or DBI and DBI::st) classes are not
*designed* for user-definable Frogs (DBI::st's). If that functionality
is widely needed, the
Damian Conway wrote:
I didn't see any mention of my plea that Ctie should pass the
original variable being tied as one of its arguments. :-(
That's because it's a dumb idea!!
**Kidding!**
I forgot about this, sorry. I'll add it to the next version ;-)
my $x = 10;
tie
On Mon, 18 Sep 2000 13:26:45 -0700, Glenn Linderman wrote:
Read RFC 241 for a brief overview of pseudo-hash problems.
I've already read RFC 241. Re-reading in this context results in the following
comments/quests for information. The remaining quotes here come from RFC 241...
Thanks for getting this RFC together, Piers.
A few comments:
* I suggest you remove my alternative C:must(Foo) suggestion.
It's too ugly to live, inless you just want to use it as a
scare tactic to encourage Larry to chose the Cinterface
syntax instead ;-)
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Revamp tie to support extensibility (Massive tie changes)
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 7 Sep 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL
In 12839.969393548@chthon, Tom Christiansen writes:
:What can be done to make $ work "better", so we don't have to
:make people use /foo\z/ to mean /foo$/? They'll keep writing
:the $ for things that probably oughtn't abide optional newlines.
:
:Remember that /$/ really means /(?=\n?\z)/. And
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Could you explain what the problem is?
TC /$/ does not only match at the end of the string.
TC It also matches one character fewer. This makes
TC code like $path =~ /etc$/ "wrong".
Sorry, I'm missing it.
$_ = "etc\n"; /etc$/;
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Could you explain what the problem is?
TC /$/ does not only match at the end of the string.
TC It also matches one character fewer. This makes
TC code like $path =~ /etc$/ "wrong".
Sorry, I'm missing it.
I know.
On your "longest match",
On Wed, 20 Sep 2000 10:03:08 +0100, Hugo wrote:
In 12839.969393548@chthon, Tom Christiansen writes:
:What can be done to make $ work "better", so we don't have to
:make people use /foo\z/ to mean /foo$/? They'll keep writing
:the $ for things that probably oughtn't abide optional newlines.
Gee
That was my second thought. I kinda like it, because //s would have two
effects:
+ let . match a newline too (current)
+ let /$/ NOT accept a trailing newline (new)
Don't forget /s's other meaning.
--tom
Tom Christiansen wrote:
Don't forget /s's other meaning.
Do you enjoy making people ask what you're talking about? What other
meaning did you have in mind, overriding $*?
--
Robert Mathews
Software Engineer
Excite@Home
perl6-language-regex
Summary report 2920
Mark-Jason Dominus has relinquished the wg chair due to the pressure
of other commitments; I'll be taking over the chair for the short
time remaining. Thanks to Mark-Jason for all his hard work.
I'll be contacting the authors of all outstanding RFCs
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
counting matches
=head1 VERSION
Maintainer: Richard Proctor [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 110
Version: 6
Status:
On Tue, 19 Sep 2000 07:40:07 -0700 (PDT), Dave Storrs wrote:
Doesn't this reflect C's idea of "a string is an array of characters"?
Which isn't the idea behind strings in Perl. The basic idea is wrong.
Therefore, making length(@array) work, would be a wrong signal.
I personally do not
What I said was: making length(@array) "work" would be catering to
novice people *coming from C*. We shouldn't. Not that much. In Perl, a
string is not an array.
I'm pretty sure it's not just the people coming from C who expect this.
This all points to the bug^H^H^Hdubious feature which is the
On Wed, Sep 20, 2000 at 04:15:13AM -, Perl6 RFC Librarian wrote:
=head2 The Basics
The new Cautoload pragma would rely on an Cautoload.conf file that
was located in C@INC and looked something like this:
What happens when there are multiple Cautoload.conf files in C@INC?
A custom one
This will make programs highly nonportable. You can't easily know what
modules they really need.
--tom
On Wed, 20 Sep 2000, Bart Lateur wrote:
The argument against my reasoning would be if the bulk of people making
this mistake are *not* coming from C. I don't know.
I have a feeling we're either arguing the same side without
realizing it, or we're just having a straight-up
On Wed, 20 Sep 2000 07:03:33 -0600, Tom Christiansen wrote:
I'm pretty sure it's not just the people coming from C who expect this.
Uh-oh.
This all points to the bug^H^H^Hdubious feature which is the sub($)
context template as applied to named arrays and hashes. Requiring
an explicit
"Bart" == Bart Lateur [EMAIL PROTECTED] writes:
Bart So length is already picky on what it accepts. You need to turn it into
Bart print length(scalar(@a, 'this is a string'));
Bart to get perl to accept it.
And then what it's accepting is the scalar-comma operator, giving you
the length of
Damian Conway wrote:
Should I point out that RFC 225 (Superpositions) actually covers most of this?
Cnull is equivalent in semantics to Cany() or Call().
I'd love to read your not yet available paper to which the RFC refers. However,
until it is available, and I have time to read it, I'll
On Tue, 19 Sep 2000, Glenn Linderman wrote:
I agree that undef and NULL have different semantics. However, this is
clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
just because we occasionally have to interface with their system.
They are different. Neither is a
Glenn Linderman [EMAIL PROTECTED] writes:
Russ Allbery wrote:
I agree with Tom; I think it's pretty self-evident that they're the
same thing. undef means exactly the same thing as null; that's not the
problem. The problem is that Perl doesn't implement the tri-state
logic semantics that
Should I point out that RFC 225 (Superpositions) actually covers
most of this?
Cnull is equivalent in semantics to Cany() or Call().
I'd love to read your not yet available paper to which the RFC
refers. However, until it is available, and I have time to read it,
In message 2920001558$[EMAIL PROTECTED]
Garrett Goebel [EMAIL PROTECTED] wrote:
I'm particularly interested in commentary for and against:
- the proposal as a whole
I think there's a big difference between the sort of short
circuiting provided by RFC 199 which I feel is best
On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote:
undef null
$a = undef; $a = null;
$b = 1; $b = 1;
$c = $a + b; $c = $a + $b;
$c is 1
On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote:
Perl already has exactly the data value that you're looking for. This RFC
is proposing to fix the wrong problem; the things that need to be changed
(conditionally) are the logical operators, not the data value.
Absolutley,
On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
=head1 TITLE
Add null() keyword and fundamental data type
=head1 MIGRATION
None. New functionality.
Not true. Apart from the discussion if undef is the same as null, in which I
take no stance, Migration *is* an
David Nicol Wrote in RFC 262:
foreach $item (@items){
#print "$item was at location ",$item:n,"\n";
print "$item was at location ${item:n}\n";
};
What would really be nice here is an Cindex function, similar to the
scalar version, that returns the index of the matching entry in a list. For
On Wed, Sep 20, 2000 at 08:05:20AM -0400, Webmaster wrote:
David Nicol Wrote in RFC 262:
foreach $item (@items){
#print "$item was at location ",$item:n,"\n";
print "$item was at location ${item:n}\n";
};
What would really be nice here is an Cindex function, similar to the
scalar
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
2. In your abstract, you say that undef is used to mean that a
variable's value is undefined, which I presume means uninitialized.
You say that null would provide a useful way to
Graham Barr Wrote:
Well if there ever is a way to shortcut grep this could be genera;ized
to
my $index = grep { break if $_ eq $seek; 1 } @items;
Wouldn't this also assume that grep return the number of times the block was
NOT true, rather than it's current implementation of the number of
On Wed, Sep 20, 2000 at 09:03:39AM -0400, Webmaster wrote:
Graham Barr Wrote:
Well if there ever is a way to shortcut grep this could be genera;ized
to
my $index = grep { break if $_ eq $seek; 1 } @items;
Wouldn't this also assume that grep return the number of times the block was
NOT
Graham Barr wrote:
But what does it do if the block
is a curried function of three arguments, but the list only contains two ?
Return a curried function of one argument, of course.
At least, that's what it *should* do...
--
John Porter
iain truskett wrote:
Return a specified value (such as 'undef'). It would allow for more
elegant code, I think. The universe is old enough to cope by itself.
When I first read this, I thought it said:
The universe is old enough to copy itself.
!-)
--
John Porter
Nathan Wiger wrote:
Since undef() has established semantics, I don't think these should
change. I believe taking from RDBMS and adding null() which has the
correct NULL semantics is the way it should go.
You realize, I hope, that there is no end of different "special non-value"
semantics.
Tom Christiansen wrote:
You want to have more properties that work like tainting does: a
per-SV attribute that is enabled or disabled by particular sorts
of expressions, sometimes dependent upon the previous presence or
absence of that property, other times, not so.
While we're at it,
Nathan Wiger wrote:
undef null
$a = undef; $a = null;
$b = 1; $b = 1;
$c = $a + b; $c = $a + $b;
$c is 1 $c is null
Uh, this is a
On Tue, 19 Sep 2000, Tom Christiansen wrote:
This RFC proposes that the internal cursor iterated by the Ceach function
be stored in the pad of the block containing the Ceach, rather than
being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
Add null() keyword and fundamental data type
I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
Given that making overloaded objects fast
Graham Barr wrote:
If you want an operator to act differently on some piece of data then a pragma
is the way to do it.
I was thinking about this on the way to work. As much as I don't like
conflating undef and null, I dislike even more the idea of the 200 pages
in Learning Perl that will have
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Currently many programs handle error returns by examining the text of
the error returned in $@. This makes changes in the text of the error
message, an issue for the backwards compatibility police.
TC eval { fn() };
TC if ($@ ==
On Wed, Sep 20, 2000 at 10:00:56AM -0700, Damien Neil wrote:
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
Add null() keyword and fundamental data type
I think that this is better done as a special overloaded object used
Incidentally, I'm surprised that DBI hasn't
On Tue, Sep 19, 2000 at 08:05:50PM -0700, Nathan Wiger wrote:
$_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
its way to its grave already, see Cuse base.
Yeah, but you're still just sidestepping my point. Your position seems
poised on the hope that no more special
Tom Christiansen wrote:
The warning for the use of an unassigned variable should be "use of
uninitialized variable C$x".
The problem with that idea, now as before, is that this check happens
where Perl is looking at a value, not a variable. Even were it possible
to arduously modify Perl
Nathan Wiger wrote:
Here's my concern about changing the meaning of undef.
undef has a very well-defined (ha!) Perl meaning: that something is
undefined.
Here's something you and Glenn don't seem to understand:
it doesn't *matter* what the human meaning of undef is.
Call it undefined,
Nathan Wiger wrote:
...a "use tristate" pragma which obeys blocks
bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
--
John Porter
And what about $$x?
Dang, are we back to this incredible confusion about what it is to be
defined in Perl.?
undef $a;
That is now UNINITIALIZED. So is this:
$a = undef;
You have initialized it to undef. There is no reasonable difference.
Solution:
Remove all references from
Nathan Wiger wrote:
...a "use tristate" pragma which obeys blocks
bka "lexically scoped". If I'm not mistaken, pragmas *are* lexically scoped.
They *can* be. They needn't be.
--tom
Steve Fink wrote:
I am merely suggesting that the compiler detect, when it can, that
you're trying to use the value of a variable without ever having
assigned a value to that variable. And in THAT message, you had better
know the name of the variable, since it's the basis of the analysis. And
John Porter wrote:
Nathan Wiger wrote:
undef null
$a = undef; $a = null;
$b = 1; $b = 1;
$c = $a + b; $c = $a + $b;
$c is 1 $c is
Damian Conway wrote:
Should I point out that RFC 225 (Superpositions) actually covers
most of this?
Cnull is equivalent in semantics to Cany() or Call().
I hope you won't mind my pointing out that the documentation of the
Quantum::Superpositions module -- to which the
"Konovalov, Vadim" wrote:
I'm quite sure that adding "null" into the language will complicate
programming and hardly will give any benefits. One should differentiate
between "null" and "undef", sometimes (or better always!) check variables
with defined(...) *and* isnull(...).
Unlike undef,
"H.Merijn Brand" wrote:
On 20 Sep 2000 04:12:09 -, Perl6 RFC Librarian [EMAIL PROTECTED] wrote:
=head1 TITLE
Add null() keyword and fundamental data type
=head1 MIGRATION
None. New functionality.
Not true. Apart from the discussion if undef is the same as null, in which I
John Porter wrote:
Nathan Wiger wrote:
Since undef() has established semantics, I don't think these should
change. I believe taking from RDBMS and adding null() which has the
correct NULL semantics is the way it should go.
You realize, I hope, that there is no end of different
Russ Allbery wrote:
Glenn Linderman [EMAIL PROTECTED] writes:
Russ Allbery wrote:
I agree with Tom; I think it's pretty self-evident that they're the
same thing. undef means exactly the same thing as null; that's not the
problem. The problem is that Perl doesn't implement the
Sam Tregar wrote:
On Tue, 19 Sep 2000, Glenn Linderman wrote:
They are different. Neither is a mistake.
How do you explain the fact that every SQL book I've ever seen has
included copious text on problems concerning NULL?
I'm not sure what SQL books you've seen. The standard treatise
The semantics for NULL is different, read the SQL standard.
Perl has no business contaminating itself with SQL.
--tom
Bad idea. See my multitudinous posts on why. Briefly:
1) can't use null and undef together
2) not extendable to 29 versions of null, when SQL defines them
Nathan Wiger wrote:
Graham Barr wrote:
If you want an operator to act differently on some piece of data then a pragma
is the way
Unlike undef, which gets assigned to uninitialized variables, NULL is only
used by choice. So you only need deal with NULL when there is the
possibility that it needs to be handled in some special way, and might exist
as a value in the expression being handled.
This can be done without being in
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
--tom
Glenn Linderman wrote:
Eric Roode wrote:
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
I would expect it to be considered false. Logical expressions involving
NULL are defined to be "undefined", actually, which is not
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
Looks more like a string of no length than a null string.
--
iain.
Damien Neil wrote:
On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
Add null() keyword and fundamental data type
I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
It could be done
Perl has *one* out-of-band value. It doesn't need more. That
doesn't mean that perhaps some rare sorts of programming might not
benefit from fancy weirdnesses. That's what modules are for.
You don't need to complicate the general language to get what
you want. Don't make others pay for your
$a = null;
$b = ($a == 42);
print defined($b)? "defined" : "not defined";
would print "not defined", maybe?
In a sane world of real (non-oo-sneaky) perl, the "==" operator returns
only 1 or "". Both are defined.
--tom
It only takes a few pages, and a few truth tables to explain NULL.
It should only take a few pages and a few examples, to explain the
difference between undef and null.
Ah, so the cost of this is twice a few pages of explanation, plus truth
tables and examples? Are you mad?
I can think of no
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
Looks more like a string of no length than a null string.
Well, it's not. That's a null string. You're thinking of "\0",
a true value in Perl.
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Currently many programs handle error returns by examining the text of
the error returned in $@. This makes changes in the text of the error
message, an issue for the backwards compatibility police.
TC eval { fn() };
TC if ($@ ==
Today around 1:03pm, Tom Christiansen hammered out this masterpiece:
: Perl has *one* out-of-band value. It doesn't need more. That
: doesn't mean that perhaps some rare sorts of programming might not
: benefit from fancy weirdnesses. That's what modules are for.
: You don't need to
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 06:09]:
iain wrote:
* Tom Christiansen ([EMAIL PROTECTED]) [21 Sep 2000 05:49]:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
Looks more like a string of no length than a null string.
Eric Roode wrote:
Glenn Linderman wrote:
Eric Roode wrote:
1. You don't say in your RFC, but I'm guessing, that a null value
evaluates to false in a boolean context. Correct?
I would expect it to be considered false. Logical expressions involving
NULL are defined to be "undefined",
Tom Christiansen wrote:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted. NULL is neither number nor string,
Tom Christiansen wrote:
Perl has *one* out-of-band value. It doesn't need more. That
doesn't mean that perhaps some rare sorts of programming might not
benefit from fancy weirdnesses. That's what modules are for.
You don't need to complicate the general language to get what
you want.
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
Tom Christiansen wrote:
It only takes a few pages, and a few truth tables to explain NULL.
It should only take a few pages and a few examples, to explain the
difference between undef and null.
Ah,
Some of oriental characters in Japanese and Korean are usually
aligned as if they have 2 columns per character.
Japanese has another formatting rule that punctuation characters
cannot appear at the beginning of or end of line (depending on
their meanings).
The proposed
Nathan Wiger [EMAIL PROTECTED] writes:
undef has a very well-defined (ha!) Perl meaning: that something is
undefined. null has a very well-defined RDBMS meaning: that something is
unknown. Perl allows you to add and concatenate stuff to undef, because
that value can be coerced into 0 and ""
Jonathan Scott Duff [EMAIL PROTECTED] writes:
Yep, this is bad IMHO. Your concern is valid I think, but your
"solution" isn't a good one. Why not just use a module like Damian's
Quantum::Superpositions?
No offense to Damian, but I tried to read and understand his documentation
and I
That's not much different than the cost of undef, so I fear it proves
nothing, universally.
YOU OVERQUOTEDsen wrote:
YOU OVERQUOTEDkes a few pages, and a few truth tables to explain NULL.
YOU OVERQUOTEDonly take a few pages and a few examples, to explain the
YOU OVERQUOTED between undef and
For example, assuming this code:
$name = undef;
print "Hello world!" if ($name eq undef);
So don't do that. Use Cdefined $name if you want to ask that question.
That's why I want to change the names of these things. The current
situation invites errors such as seen previously.
Tom Christiansen wrote:
no strict;
$a = undef;
$b = null;
Perl already has a null string: "".
That's an empty string. In any case, if you really want to call it a
null string, that's fine, just a little more likely to be
misinterpreted.
In Perl, this is the null string:
I'm not happy with your use of "coerce". There's no mutation. It simply
*is* those things.
Fine. So, in particular, it _isn't_ null.
Of course it's null. That's why it has length zero. Stop speaking
SQL at me. I'm speaking Perl.
4) The antiïinitialized value is autovivified to a true
Tom Christiansen wrote:
By your "reasoning", we can just add infinitely more things that
take twice a few pages to explain.
Perl is already too hard.
Yes, it is.
And that's why I'm against Cuse invocant.
(Had to get that plug in there) ;-)
-Nate
* Russ Allbery ([EMAIL PROTECTED]) [21 Sep 2000 07:22]:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
Yep, this is bad IMHO. Your concern is valid I think, but your
"solution" isn't a good one. Why not just use a module like
Damian's Quantum::Superpositions?
No offense to Damian, but
On Wed, Sep 20, 2000 at 07:45:16PM -, Perl6 RFC Librarian wrote:
"VARIABLE used only once: possible typo" should be replaced with
warnings on uses of uninitialized variables (including lexicals).
$x = 3
I don't understand, who's to say you didn't misspell $x? If you're only
using it
On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
It could be done as an overloaded object. You'd have to be able to overload all
the
Glenn Linderman wrote:
Not a solution.
Frankly, you haven't demonstrated that there's a problem.
--
John Porter
On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
No offense to Damian, but I tried to read and understand his documentation
and I thought I was back in grad school. I don't think it's the fault of
the writing either; I think that Quantum::Superpositions is trying to do
something
On Wed, Sep 20, 2000 at 02:47:01PM -0600, Tom Christiansen wrote:
In Perl, this is the null character: "\0"
...
It's a shame you don't like it, but this is the way we speak.
Well, it's the way you speak. Myself, I'd call that the NUL
character. :
- Damien, exercising a pet
On Fri, 15 Sep 2000 10:29:31 +1100 (EST), Damian Conway wrote:
Why not just give \I..\E a special "turn-on-interpolation" meaning in
q{} docs?
This has been uppered already in the pre-discussion to this RFC.
Currently, '\I' is nothing special in q{}, and a lot of people don't
want to chage
$a = null;
$b = ($a == 42);
print defined($b)? "defined" : "not defined";
would print "not defined", maybe?
defined() is the wrong operator to be using there. Rather,
$a = null;
$b = ($a == 42);
print is_null($b)? "is null" : "is not null";
In general, what
At 12:38 PM 9/20/00 -0700, Glenn Linderman wrote:
OK, scalar variables. But I see code in the XML modules that check
defined (@array)
Then they should be fixed. That doesn't do anything useful right now.
Interesting. I learn something every day. Today, you helped. Maybe you
can help
some
Damien Neil [EMAIL PROTECTED] writes:
If I could be assured that the performance penalty was minimal, I'd
be delighted to write
if ($errno == any(EAGAIN EINTR)) { ... }
over
if ($errno == EAGAIN || $errno == EINTR) { ... }
The former is less typing and reads more clearly (to me, at
Eric Roode wrote:
Steve Fink wrote:
I am merely suggesting that the compiler detect, when it can, that
you're trying to use the value of a variable without ever having
assigned a value to that variable. And in THAT message, you had better
know the name of the variable, since it's the basis
But that doesn't even matter that much here; I'm saying that if the
compiler can definitely determine that you are using an uninitialized
variable, it should warn.
...
$x is a global. The compiler cannot detect all possible assignments to
or accesses of globals, so it never warns about them.
1 - 100 of 130 matches
Mail list logo
