Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.158 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=YKSqgrDdIArzC24yfzyP9KLQjcMfX7Bsaw7CaDnVcJVFI22x0/sSaPsku+N10GP7QB
         blc8Vb07QjeUuwPDQM3c4XBOkPLSLtOCr6dbiDfYgcWVPBwrxb3vRsieFiH2C9vzQkeA
         9UgOpLTaaJatQzMT7scihMpCSiIE6AH1VeUn0=
Message-ID: <2dedb8a0810262216l38c08e8bub7604a64d6603805@mail.gmail.com>
Date: Mon, 27 Oct 2008 06:16:20 +0100
To: "=?ISO-8859-1?Q?Johannes_Schl=FCter?=" <johannes@php.net>
Cc: "PHP Development" <internals@lists.php.net>, 
	"Lukas Kahwe Smith" <mls@pooteeweet.org>
In-Reply-To: <1225031033.6991.5.camel@goldfinger.johannes.nop>
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>
Subject: Re: [PHP-DEV] Resource constants
From: kalle.php@gmail.com ("Kalle Sommer Nielsen")

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 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().

>
> We might still block users from doing but I don't see real benefit from
> doing that - I think it's ok to have undocumented features ... :-)

I would rather not have so many undocumented features in the manual as
possible, even though they can be buggy like ticks for Windows
threaded webservers ;)

>
> johannes
>
>



--=20
Kalle Sommer Nielsen