On 04.11.2008, at 23:02, Lukas Kahwe Smith wrote:
On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote:
2008/10/27 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
2008/10/26 Johannes Schlüter <[EMAIL PROTECTED]>:
On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote:
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.
Yes I know, but still I think we should either making it a
supported
feature or restrict registering resources on define().
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?).
E_DEPRECATED if we deprecated this feature, but I would be happy with
an E_STRICT if 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.")
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:
1) emulating STDOUT and STDERR when using cgi
2) 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:
1) leave as is
2) raise an E_DEPRECATED in PHP 5.3 and remove in PHP 6.0
3) raise an E_STRICT in 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
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php