Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41675
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.159 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=CvpJU35cZD3+FfG/5HRb4XEZHknuQs2op9bvIK+55melFWZsDsrfqUPHh6I6kt6XEX
         mx2rsW88GBMpoCvOfN0RQeRH680vwQK3CeCQFyR5g3Lh3Nxy8ZjbZvOSWv5FD2NktsPC
         nXG122Dsgv/61v6+QcTom9oGUpdLOxA0y33NU=
Message-ID: <2dedb8a0811041540i3b7fbacfm48597f40d1508590@mail.gmail.com>
Date: Wed, 5 Nov 2008 00:40:31 +0100
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: "=?ISO-8859-1?Q?\"_\"Johannes_Schl=FCter_\"\"?=" <johannes@php.net>, 
	"PHP Development" <internals@lists.php.net>
In-Reply-To: <2DBE2668-D4D1-4DF8-8242-3BCFDD4CFE8E@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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>
	 <2DBE2668-D4D1-4DF8-8242-3BCFDD4CFE8E@pooteeweet.org>
Subject: Re: [PHP-DEV] Resource constants
From: kalle.php@gmail.com ("Kalle Sommer Nielsen")

2008/11/5 Lukas Kahwe Smith <mls@pooteeweet.org>:
>
> 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 put
>>>>>>> an
>>>>>>> deprecation notice on it (5.3) and remove it HEAD. I personally vot=
e
>>>>>>> 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, especial=
ly
>>>> 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 deprecat=
e
>>>> 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 discussi=
on.
>
> as the following google code search shows the "feature" is used:
> http://www.google.com/codesearch?hl=3Den&lr=3D&q=3Dlang%3Aphp+define.*(fo=
pen|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 way,
> while 2) does not seem like something people really need constants for. s=
o
> 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
> mls@pooteeweet.org
>
>
>
>



--=20
Kalle Sommer Nielsen