Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41671
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error)
Cc: Kalle Sommer Nielsen <kalle.php@gmail.com>,
 =?ISO-8859-1?Q?=22\=22Johannes_Schl=FCter\=22=22?= <johannes@php.net>,
 "PHP Development" <internals@lists.php.net>
Message-ID: <2DBE2668-D4D1-4DF8-8242-3BCFDD4CFE8E@pooteeweet.org>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <E00E8962-57F6-49AB-A454-E34B91863FAB@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 5 Nov 2008 00:10:45 +0100
References: <2dedb8a0810260632k53529eafma4f760afaf4f5a8@mail.gmail.com> <1225031033.6991.5.camel@goldfinger.johannes.nop> <2dedb8a0810262216l38c08e8bub7604a64d6603805@mail.gmail.com> <0DB6F005-EC2D-4D51-8C56-5FCA6017611B@pooteeweet.org> <2dedb8a0810270026r6dc193cat55a66feda08c3485@mail.gmail.com> <E00E8962-57F6-49AB-A454-E34B91863FAB@pooteeweet.org>
Subject: Re: [PHP-DEV] Resource constants
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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 <mls@pooteeweet.org>:
>>>
>>> On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
>>>
>>>> 2008/10/26 Johannes Schl=FCter <johannes@php.net>:
>>>>>
>>>>> On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote:
>>>>>>
>>>>>> So, I propose its either being a "supported" feature, or simply =20=

>>>>>> put an
>>>>>> deprecation notice on it (5.3) and remove it HEAD. I personally =20=

>>>>>> vote
>>>>>> for the last option, as I don't think resources should be =20
>>>>>> constants as
>>>>>> they do not have the constant value even though they do on some =20=

>>>>>> level.
>>>>>
>>>>> I recently discussed the same issue on IRC, (due to #45982) we =20
>>>>> can't get
>>>>> rid of resources in constants completely as we need that for =20
>>>>> STDIN,
>>>>> STDOU, STDERR constants.
>>>>
>>>> Yes I know, but still I think we should either making it a =20
>>>> supported
>>>> feature or restrict registering resources on define().
>>>
>>>
>>> Huh, I wasnt even aware that define() supports anything but scalar =20=

>>> values.
>>> At any rate I am very sure I never stumbled over code defining a =20
>>> constant
>>> with a ressource. Not a very good idea to support ressources, =20
>>> especially
>>> given the obvious WTF's this causes (as you rightly pointed out). =20=

>>> So I see
>>> that an E_DEPRECATED would make sense. However I am not sure about =20=

>>> removing
>>> this though, which would make the E_DEPRECATED a bit odd (why =20
>>> 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 =20=

> its currently not documented (though oddly it still discourages =20
> users to not do something that is not said to work "Only scalar data =20=

> (boolean, integer, float and string) can be contained in constants. =20=

> Do not define resource constants.")


ok i guess i was too quick with my call .. but i stirred up some =20
discussion.

as the following google code search shows the "feature" is used:
http://www.google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Aphp+define.*(fop=
en|=20
mysql_connect)\(&sbtn=3DSearch

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 =20
way, while 2) does not seem like something people really need =20
constants for. so imho i still think we should deprecate it .. but =20
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 =20
even if we go for 2) or 3)?

regards,
Lukas Kahwe Smith
mls@pooteeweet.org