Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41423
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.152 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=xV5Kfrv+LKEa5cC0gcq9MYvj7xVkEA5MBdQC0rJcdnXRgPBOrWoMC8/l0KUnnHN5yx
         PQVOuUQi0iv9lbd+WS2nSOQq5YwiCDZq6oriGRV9JOUYP8KPeJIDJEwpnuChAIPazm/V
         Pn7mnD5LFCX/eE9KeMWki7d9q/KtGlSNQCEhA=
Message-ID: <2dedb8a0810270026r6dc193cat55a66feda08c3485@mail.gmail.com>
Date: Mon, 27 Oct 2008 08:26:42 +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: <0DB6F005-EC2D-4D51-8C56-5FCA6017611B@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>
Subject: Re: [PHP-DEV] Resource constants
From: kalle.php@gmail.com ("Kalle Sommer Nielsen")

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 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 ge=
t
>>> 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 se=
e
> that an E_DEPRECATED would make sense. However I am not sure about removi=
ng
> this though, which would make the E_DEPRECATED a bit odd (why deprecate i=
f
> 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
>
>
>
>



--=20
Kalle Sommer Nielsen