Re: [PHP-DEV] Resource constants

2008-11-04 Thread Lukas Kahwe Smith


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.)


regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resource constants

2008-11-04 Thread 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 [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=enlr=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

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]




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resource constants

2008-11-04 Thread Cristian Rodríguez
Lukas Kahwe Smith escribió:

 Also should there be some other way to get STDOUT and STDERR defined

I assume we are talking about userland constants right ?


-- 
Good, Fast, Cheap: Pick any two (you can't have all three).

Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research  Development
http://www.opensuse.org/




signature.asc
Description: OpenPGP digital signature


Re: [PHP-DEV] Resource constants

2008-11-04 Thread Kalle Sommer Nielsen
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=enlr=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



Re: [PHP-DEV] Resource constants

2008-11-04 Thread Kalle Sommer Nielsen
2008/11/5 Cristian Rodríguez [EMAIL PROTECTED]:
 Lukas Kahwe Smith escribió:

 Also should there be some other way to get STDOUT and STDERR defined

 I assume we are talking about userland constants right ?

Yes, userland constants defined with define().



 --
 Good, Fast, Cheap: Pick any two (you can't have all three).

 Cristian Rodríguez R.
 Platform/OpenSUSE - Core Services
 SUSE LINUX Products GmbH
 Research  Development
 http://www.opensuse.org/






-- 
Kalle Sommer Nielsen

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resource constants

2008-10-27 Thread Lukas Kahwe Smith


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?).


regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resource constants

2008-10-27 Thread Kalle Sommer Nielsen
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. :)

 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



Re: [PHP-DEV] Resource constants

2008-10-27 Thread Cristian Rodríguez

 At any rate I am very sure I never stumbled over code defining a
 constant with a ressource. 

I did stumble over such thing ;)

Not a very good idea to support ressources,
 especially given the obvious WTF's this causes (as you rightly pointed
 out). 

http://stuff.cristianrodriguez.net/patches/define-no-resources-5_3.patch

 However I am not
 sure about removing this though,

Why not ? it is documented that it only scalar values are accepted, the
code does other thing though =) objects that can be casted to string
also work without warning..


-- 
A computer is like an Old Testament god, with a lot of rules and no
mercy. 

Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Products GmbH
Research  Development
http://www.opensuse.org/




signature.asc
Description: OpenPGP digital signature


[PHP-DEV] Resource constants

2008-10-26 Thread Kalle Sommer Nielsen
Gday internals

Today I felt over a topic while looking at some documentation bugs,
and as the title says its the Resource constants. From what I could
understand by asking Felipe and reading over some bug reports and such
then resource constants aren't really supported. I had a play around
with it and rand into some WTF's I wanted to get information on so I
can upgrade the documentation for this.

Its possible to use resource constants and they work all perfect for
the quick overview I did of them, but the following things might
confuse our users:

Issue #1:
?php
define('FP', fopen('/home/kalle/myfile.txt', 'r'));

// ...

fclose(FP);
?

The value of FP is not an Resource of unknown, which is logical enough
from when working with variables. However when you're working with
variables you might do:
?php
fclose($fp);
$fp = NULL;
?

So the value is unset, so we're sure the resource is closed, however
since constants are constants the value will remain that Unknown
resource, so to check if the resource still is of that type we want
(when checking if the resource is active) we need to have a
conditional with a call to get_resource_type() and then match it for
that type we now wanted to check if it was. I belive if that was
changed to NULL it would solve some wondering when debugging your
application.


Issue #2:
?php
$fp = fopen('/home/kalle/myfile.txt', 'r');
define('FP', $fp);

// ...
?

Now which should we close using fclose? Calling fclose on the variable
will NOT close the connection, however calling it on the constant will
close it and change it to resource unknown as well as the variable.
Which also may leed to confusion between people who does that. (I'd
like to let people do whatever they want, and not let us deside how to
design the code, so either this is a bug or because its not really
supported). This might be a reference issue or something similar, I
didn't look much into the cause of this.


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.


References:
http://bugs.php.net/bug.php?id=45982
http://bugs.php.net/bug.php?id=46348
http://google.com/codesearch?hl=pt-BRlr=q=lang%3Aphp+define%5C%28%5B%5E%2C%5D%2B%2C%5Cs%2A%28mysqli%3F%7Cpg%29_connect%5C%28sbtn=Pesquisar


-- 
Kalle Sommer Nielsen

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resource constants

2008-10-26 Thread Johannes Schlüter
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.

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 ... :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Resource constants

2008-10-26 Thread Kalle Sommer Nielsen
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().


 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





-- 
Kalle Sommer Nielsen

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php