Gday internals
Today I felt over a topic while looking at some documentation bugs,
and as the title says its the Resource constants. From what I could
understand by asking Felipe and reading over some bug reports and such
then resource constants aren't really supported. I had a play around
with it and rand into some "WTF"'s I wanted to get information on so I
can upgrade the documentation for this.
Its possible to use resource constants and they work all perfect for
the quick overview I did of them, but the following things might
confuse our users:
Issue #1:
<?php
define('FP', fopen('/home/kalle/myfile.txt', 'r'));
// ...
fclose(FP);
?>
The value of FP is not an Resource of unknown, which is logical enough
from when working with variables. However when you're working with
variables you might do:
<?php
fclose($fp);
$fp = NULL;
?>
So the value is unset, so we're sure the resource is closed, however
since constants are constants the value will remain that Unknown
resource, so to check if the resource still is of that type we want
(when checking if the resource is active) we need to have a
conditional with a call to get_resource_type() and then match it for
that type we now wanted to check if it was. I belive if that was
changed to NULL it would solve some wondering when debugging your
application.
Issue #2:
<?php
$fp = fopen('/home/kalle/myfile.txt', 'r');
define('FP', $fp);
// ...
?>
Now which should we close using fclose? Calling fclose on the variable
will NOT close the connection, however calling it on the constant will
close it and change it to resource unknown as well as the variable.
Which also may leed to confusion between people who does that. (I'd
like to let people do whatever they want, and not let us deside how to
design the code, so either this is a bug or because its not "really"
supported). This might be a reference issue or something similar, I
didn't look much into the cause of this.
So, I propose its either being a "supported" feature, or simply put an
deprecation notice on it (5.3) and remove it HEAD. I personally vote
for the last option, as I don't think resources should be constants as
they do not have the constant value even though they do on some level.
References:
http://bugs.php.net/bug.php?id=45982
http://bugs.php.net/bug.php?id=46348
http://google.com/codesearch?hl=pt-BR&lr=&q=lang%3Aphp+define%5C%28%5B%5E%2C%5D%2B%2C%5Cs%2A%28mysqli%3F%7Cpg%29_connect%5C%28&sbtn=Pesquisar
--
Kalle Sommer Nielsen
So, I propose its either being a "supported" feature, or simply put an
deprecation notice on it (5.3) and remove it HEAD. I personally vote
for the last option, as I don't think resources should be constants as
they do not have the constant value even though they do on some level.
I recently discussed the same issue on IRC, (due to #45982) we can't get
rid of resources in constants completely as we need that for STDIN,
STDOU, STDERR constants.
We might still block users from doing but I don't see real benefit from
doing that - I think it's ok to have undocumented features ... :-)
johannes
2008/10/26 Johannes Schlüter johannes@php.net:
So, I propose its either being a "supported" feature, or simply put an
deprecation notice on it (5.3) and remove it HEAD. I personally vote
for the last option, as I don't think resources should be constants as
they do not have the constant value even though they do on some level.I recently discussed the same issue on IRC, (due to #45982) we can't get
rid of resources in constants completely as we need that for STDIN,
STDOU,STDERRconstants.
Yes I know, but still I think we should either making it a supported
feature or restrict registering resources on define().
We might still block users from doing but I don't see real benefit from
doing that - I think it's ok to have undocumented features ... :-)
I would rather not have so many undocumented features in the manual as
possible, even though they can be buggy like ticks for Windows
threaded webservers ;)
johannes
--
Kalle Sommer Nielsen
2008/10/26 Johannes Schlüter johannes@php.net:
So, I propose its either being a "supported" feature, or simply
put an
deprecation notice on it (5.3) and remove it HEAD. I personally vote
for the last option, as I don't think resources should be
constants as
they do not have the constant value even though they do on some
level.I recently discussed the same issue on IRC, (due to #45982) we
can't get
rid of resources in constants completely as we need that for STDIN,
STDOU,STDERRconstants.Yes I know, but still I think we should either making it a supported
feature or restrict registering resources ondefine().
Huh, I wasnt even aware that define() supports anything but scalar
values. At any rate I am very sure I never stumbled over code defining
a constant with a ressource. Not a very good idea to support
ressources, especially given the obvious WTF's this causes (as you
rightly pointed out). So I see that an E_DEPRECATED would make sense.
However I am not sure about removing this though, which would make the
E_DEPRECATED a bit odd (why deprecate if we do not remove?).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2008/10/27 Lukas Kahwe Smith mls@pooteeweet.org:
2008/10/26 Johannes Schlüter johannes@php.net:
So, I propose its either being a "supported" feature, or simply put an
deprecation notice on it (5.3) and remove it HEAD. I personally vote
for the last option, as I don't think resources should be constants as
they do not have the constant value even though they do on some level.I recently discussed the same issue on IRC, (due to #45982) we can't get
rid of resources in constants completely as we need that for STDIN,
STDOU,STDERRconstants.Yes I know, but still I think we should either making it a supported
feature or restrict registering resources ondefine().Huh, I wasnt even aware that
define()supports anything but scalar values.
At any rate I am very sure I never stumbled over code defining a constant
with a ressource. Not a very good idea to support ressources, especially
given the obvious WTF's this causes (as you rightly pointed out). So I see
that anE_DEPRECATEDwould make sense. However I am not sure about removing
this though, which would make theE_DEPRECATEDa bit odd (why deprecate if
we do not remove?).
E_DEPRECATED if we deprecated this feature, but I would be happy with
an E_STRICT if this behaviour will be kept. :)
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
--
Kalle Sommer Nielsen
2008/10/27 Lukas Kahwe Smith mls@pooteeweet.org:
2008/10/26 Johannes Schlüter johannes@php.net:
So, I propose its either being a "supported" feature, or simply
put an
deprecation notice on it (5.3) and remove it HEAD. I personally
vote
for the last option, as I don't think resources should be
constants as
they do not have the constant value even though they do on some
level.I recently discussed the same issue on IRC, (due to #45982) we
can't get
rid of resources in constants completely as we need that for STDIN,
STDOU,STDERRconstants.Yes I know, but still I think we should either making it a supported
feature or restrict registering resources ondefine().Huh, I wasnt even aware that
define()supports anything but scalar
values.
At any rate I am very sure I never stumbled over code defining a
constant
with a ressource. Not a very good idea to support ressources,
especially
given the obvious WTF's this causes (as you rightly pointed out).
So I see
that anE_DEPRECATEDwould make sense. However I am not sure about
removing
this though, which would make theE_DEPRECATEDa bit odd (why
deprecate if
we do not remove?).
E_DEPRECATEDif we deprecated this feature, but I would be happy with
anE_STRICTif this behaviour will be kept. :)
so lets mark it as E_DEPRECATED in 5.3 and remove in 6.0, given that
its currently not documented (though oddly it still discourages users
to not do something that is not said to work "Only scalar data
(boolean, integer, float and string) can be contained in constants. Do
not define resource constants.")
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2008/10/27 Lukas Kahwe Smith mls@pooteeweet.org:
2008/10/26 Johannes Schlüter johannes@php.net:
So, I propose its either being a "supported" feature, or simply
put an
deprecation notice on it (5.3) and remove it HEAD. I personally
vote
for the last option, as I don't think resources should be
constants as
they do not have the constant value even though they do on some
level.I recently discussed the same issue on IRC, (due to #45982) we
can't get
rid of resources in constants completely as we need that for
STDIN,
STDOU,STDERRconstants.Yes I know, but still I think we should either making it a
supported
feature or restrict registering resources ondefine().Huh, I wasnt even aware that
define()supports anything but scalar
values.
At any rate I am very sure I never stumbled over code defining a
constant
with a ressource. Not a very good idea to support ressources,
especially
given the obvious WTF's this causes (as you rightly pointed out).
So I see
that anE_DEPRECATEDwould make sense. However I am not sure about
removing
this though, which would make theE_DEPRECATEDa bit odd (why
deprecate if
we do not remove?).
E_DEPRECATEDif we deprecated this feature, but I would be happy with
anE_STRICTif this behaviour will be kept. :)so lets mark it as
E_DEPRECATEDin 5.3 and remove in 6.0, given that
its currently not documented (though oddly it still discourages
users to not do something that is not said to work "Only scalar data
(boolean, integer, float and string) can be contained in constants.
Do not define resource constants.")
ok i guess i was too quick with my call .. but i stirred up some
discussion.
as the following google code search shows the "feature" is used:
http://www.google.com/codesearch?hl=en&lr=&q=lang%3Aphp+define.*(fopen|
mysql_connect)(&sbtn=Search
main use seem to be:
- emulating
STDOUTandSTDERRwhen using cgi - as a pseudo "super global" to pass around db and log file handles
to me 1) seems like something we might want to provide in some other
way, while 2) does not seem like something people really need
constants for. so imho i still think we should deprecate it .. but
other people have noted that they prefer an E_STRICT.
so lets have a quick vote here:
- leave as is
- raise an
E_DEPRECATEDin PHP 5.3 and remove in PHP 6.0 - raise an
E_STRICTin PHP 5.3
Also should there be some other way to get STDOUT and STDERR defined
even if we go for 2) or 3)?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith escribió:
Also should there be some other way to get
STDOUTandSTDERRdefined
I assume we are talking about userland constants right ?
--
"Good, Fast, Cheap: Pick any two (you can't have all three)."
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/
2008/11/5 Cristian Rodríguez crrodriguez@suse.de:
Lukas Kahwe Smith escribió:
Also should there be some other way to get
STDOUTandSTDERRdefinedI assume we are talking about userland constants right ?
Yes, userland constants defined with define().
--
"Good, Fast, Cheap: Pick any two (you can't have all three)."Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/
--
Kalle Sommer Nielsen
2008/11/5 Lukas Kahwe Smith mls@pooteeweet.org:
2008/10/27 Lukas Kahwe Smith mls@pooteeweet.org:
2008/10/26 Johannes Schlüter johannes@php.net:
So, I propose its either being a "supported" feature, or simply put
an
deprecation notice on it (5.3) and remove it HEAD. I personally vote
for the last option, as I don't think resources should be constants
as
they do not have the constant value even though they do on some
level.I recently discussed the same issue on IRC, (due to #45982) we can't
get
rid of resources in constants completely as we need that for STDIN,
STDOU,STDERRconstants.Yes I know, but still I think we should either making it a supported
feature or restrict registering resources ondefine().Huh, I wasnt even aware that
define()supports anything but scalar
values.
At any rate I am very sure I never stumbled over code defining a
constant
with a ressource. Not a very good idea to support ressources, especially
given the obvious WTF's this causes (as you rightly pointed out). So I
see
that anE_DEPRECATEDwould make sense. However I am not sure about
removing
this though, which would make theE_DEPRECATEDa bit odd (why deprecate
if
we do not remove?).
E_DEPRECATEDif we deprecated this feature, but I would be happy with
anE_STRICTif this behaviour will be kept. :)so lets mark it as
E_DEPRECATEDin 5.3 and remove in 6.0, given that its
currently not documented (though oddly it still discourages users to not do
something that is not said to work "Only scalar data (boolean, integer,
float and string) can be contained in constants. Do not define resource
constants.")ok i guess i was too quick with my call .. but i stirred up some discussion.
as the following google code search shows the "feature" is used:
http://www.google.com/codesearch?hl=en&lr=&q=lang%3Aphp+define.*(fopen|mysql_connect)(&sbtn=Searchmain use seem to be:
- emulating
STDOUTandSTDERRwhen using cgi- as a pseudo "super global" to pass around db and log file handles
to me 1) seems like something we might want to provide in some other way,
while 2) does not seem like something people really need constants for. so
imho i still think we should deprecate it .. but other people have noted
that they prefer an E_STRICT.so lets have a quick vote here:
- leave as is
- raise an
E_DEPRECATEDin PHP 5.3 and remove in PHP 6.0- raise an
E_STRICTin PHP 5.3
After thinking it over another time, Im gonna give a +1 to option 3
(raise an E_STRICT), but either way I would be happy with option 2
aswell.
Also should there be some other way to get
STDOUTandSTDERRdefined even if
we go for 2) or 3)?regards,
Lukas Kahwe Smith
mls@pooteeweet.org
--
Kalle Sommer Nielsen
At any rate I am very sure I never stumbled over code defining a
constant with a ressource.
I did stumble over such thing ;)
Not a very good idea to support ressources,
especially given the obvious WTF's this causes (as you rightly pointed
out).
http://stuff.cristianrodriguez.net/patches/define-no-resources-5_3.patch
However I am not
sure about removing this though,
Why not ? it is documented that it only scalar values are accepted, the
code does other thing though =) objects that can be casted to string
also work without warning..
--
"A computer is like an Old Testament god, with a lot of rules and no
mercy. "
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research & Development
http://www.opensuse.org/