2008/11/5 Lukas Kahwe Smith <[EMAIL PROTECTED]>: > > 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
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 STDOUT and STDERR defined even if > we go for 2) or 3)? > > regards, > Lukas Kahwe Smith > [EMAIL PROTECTED] > > > > -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
