# Resource constants - Thread: https://externals.io/message/41381 - Original archive: https://news-web.php.net/php.internals/41381 - Started by Kalle Sommer Nielsen on 2008-10-26T13:32:57+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #41381 — Kalle Sommer Nielsen — 2008-10-26T13:32:57+00:00 URL: https://externals.io/message/41381#41381 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: 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: 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: 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-BR&lr=&q=lang%3Aphp+define%5C%28%5B%5E%2C%5D%2B%2C%5Cs%2A%28mysqli%3F%7Cpg%29_connect%5C%28&sbtn=Pesquisar -- Kalle Sommer Nielsen --- ## #41383 — johannes@php.net — 2008-10-26T14:23:53+00:00 URL: https://externals.io/message/41381#41383 · In reply to: #41381 > 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 --- ## #41417 — Kalle Sommer Nielsen — 2008-10-27T05:16:20+00:00 URL: https://externals.io/message/41381#41417 · In reply to: #41383 2008/10/26 Johannes Schlüter : > > > […] > > 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 --- ## #41420 — Lukas Kahwe Smith — 2008-10-27T07:20:16+00:00 URL: https://externals.io/message/41381#41420 · In reply to: #41417 > 2008/10/26 Johannes Schlüter : > > […] > > 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 mls@pooteeweet.org --- ## #41423 — Kalle Sommer Nielsen — 2008-10-27T07:26:42+00:00 URL: https://externals.io/message/41381#41423 · In reply to: #41420 2008/10/27 Lukas Kahwe Smith : > > > > > […] > > > 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 > mls@pooteeweet.org > > > > -- Kalle Sommer Nielsen --- ## #41453 — crrodriguez@suse.de — 2008-10-27T13:25:20+00:00 URL: https://externals.io/message/41381#41453 · In reply to: #41420 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/ --- ## #41667 — Lukas Kahwe Smith — 2008-11-04T22:02:31+00:00 URL: https://externals.io/message/41381#41667 · In reply to: #41423 > 2008/10/27 Lukas Kahwe Smith : > > […] > > `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 mls@pooteeweet.org --- ## #41671 — Lukas Kahwe Smith — 2008-11-04T23:10:45+00:00 URL: https://externals.io/message/41381#41671 · In reply to: #41667 > > > > > […] > > > 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=en&lr=&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 mls@pooteeweet.org --- ## #41673 — crrodriguez@suse.de — 2008-11-04T23:25:27+00:00 URL: https://externals.io/message/41381#41673 · In reply to: #41671 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/ --- ## #41675 — Kalle Sommer Nielsen — 2008-11-04T23:40:31+00:00 URL: https://externals.io/message/41381#41675 · In reply to: #41671 2008/11/5 Lukas Kahwe Smith : > > > > > […] > > > 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=en&lr=&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 > mls@pooteeweet.org > > > > -- Kalle Sommer Nielsen --- ## #41676 — Kalle Sommer Nielsen — 2008-11-04T23:40:53+00:00 URL: https://externals.io/message/41381#41676 · In reply to: #41673 2008/11/5 Cristian Rodríguez : > Lukas Kahwe Smith escribió: > > > […] > > 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