# RFD: PDO::FETCH_2D or a hierarchical FETCH_ASSOC - Thread: https://externals.io/message/33178 - Original archive: https://news-web.php.net/php.internals/33178 - Started by Hans-Peter Oeri on 2007-11-16T14:25:40+00:00 - Messages: 47 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/33178.md?page=2 - 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 --- ## #33178 — Hans-Peter Oeri — 2007-11-16T14:25:40+00:00 URL: https://externals.io/message/33178#33178 Hi! I'm surely not the only one that ran into the problem of queries returning several columns with identical names. I didn't find anything about my following suggestion in the archives - if however, I'm only warming up old cheese, please ignore/bash me ;) As I see, there is an connection attribute ATTR_FETCH_TABLE_NAMES that - depending on driver support - qualifies column names: column 'a' on table 'b' => $result['b.a'] Given support for that attribute, a FETCH_ASSOC returns a one-dimensional array with qualified column names. However, I don't consider this solution as good as it could be... E.g. it's rather hard to extract the values from a specific table (short of running over the whole index array). There is useful information "hidden" in the text... I therefore suggest a fetch mode that returns TWO-DIMENSIONAL arrays, the first dimension being the table/relation name, the second the column identification: column 'a' on table 'b' => $result['b']['a'] Such a solution would ease a lot of my 'framework' tasks. Open questions/ideas: - columns not originating from a table? Those could be entered in the first hierarchy (possibility of conflict with table names): $result['computed_value'] or in sort of a 'pseudo table' like '0' or 'unknown' (possibility of conflict by that pseudo name): $result['unknown']['computed_value'] - separate fetch mode or mode modification flag? There could be uses for a modified FETCH_BOTH as well, with column numbers all on first level plus hierarchical FETCH_2D. - what about a hybrid fetch? There could be uses for sort of a hybrid fetch, which would result in FETCH_ASSOC (each column name only once, first level) plus FETCH_2D (all columns hierarchically). To reduce memory consumption, the "doubly represented" columns could share a Z_VAL reference. Compatibility issues: - A quick glance only reveals fetchColumn and getColumnMeta as obvious compatibility issues. Should they be enhanced to not only accept column numbers, but textual column identifiers as well... - A hybrid mode (see above) that works 1:1 with existing code plus offers the advantages of hierarchical access would only be feasible with 'hidden' keys. I don't think that's necessary. What do you think? HPO --- ## #33179 — Sam Barrow — 2007-11-16T20:53:11+00:00 URL: https://externals.io/message/33178#33179 · In reply to: #33178 I am trying to develop a patch for personal use to enable custom superglobals. I seemed to have had it working, but am I allowed to specify superglobals in my script, or do they have to be specified in an ini file or statically in the PHP code? I created a superglobal keyword and a function that calls zend_register_auto_global upon the use of this keyword, but it doesn't work. It calls zend_register_auto_global correctly and passes the variable name and length of the variable name, but when i try to access the variable inside a function in my PHP script, it is undefined. However I am able to hard code my superglobal into the PHP source files and it works. Is there some type of restriction on setting superglobals at runtime, or does the structure of the PHP interpreter not allow this, or am I doing something wrong? Thanks in advanced for your help. --- ## #33180 — Hans-Peter Oeri — 2007-11-16T21:37:25+00:00 URL: https://externals.io/message/33178#33180 · In reply to: #33179 Hi! Sam Barrow wrote: > I am trying to develop a patch for personal use to enable custom > superglobals. I may have missed your point. But does the pecl extension "runkit" not fulfill your desires? HPO --- ## #33181 — johannes@php.net — 2007-11-16T21:58:05+00:00 URL: https://externals.io/message/33178#33181 · In reply to: #33179 Hi Sam, you could use pecl/runkit for registering your own super globals. See example 2071 on http://de3.php.net/manual/en/ref.runkit.php johannes > I am trying to develop a patch for personal use to enable custom > superglobals. > > I seemed to have had it working, but am I allowed to specify > superglobals in my script, or do they have to be specified in an ini > file or statically in the PHP code? > > I created a superglobal keyword and a function that calls > zend_register_auto_global upon the use of this keyword, but it doesn't > work. It calls zend_register_auto_global correctly and passes the > variable name and length of the variable name, but when i try to access > the variable inside a function in my PHP script, it is undefined. > However I am able to hard code my superglobal into the PHP source files > and it works. > > Is there some type of restriction on setting superglobals at runtime, or > does the structure of the PHP interpreter not allow this, or am I doing > something wrong? > > Thanks in advanced for your help. --- ## #33182 — Sam Barrow — 2007-11-16T22:10:14+00:00 URL: https://externals.io/message/33178#33182 · In reply to: #33181 Thanks everyone, I knew this, but I didn't want to use runkit because it is a beta, and i don't want all that other stuff, just superglobals. Also, runkit only allows you to use php.ini, but my patch allows you to specify superglobals in your script with the keyword "superglobal" by saying: superglobal $var1, $var2 ; Thanks for your help though, if anyone else is interested in the patch send me a message. This isn't something the developers would want to implement I assume, but it would be useful if they would, at a very small cost too (the patch probably under 50 lines, very simple code too). If anyone would like the patch to be implemented in CVS, let me know. > Hi Sam, > > you could use pecl/runkit for registering your own super globals. See > example 2071 on http://de3.php.net/manual/en/ref.runkit.php > > johannes > > > > […] --- ## #33183 — Michael McGlothlin — 2007-11-17T00:23:58+00:00 URL: https://externals.io/message/33178#33183 · In reply to: #33182 I think the superglobal keyword is a great idea. I have a custom class that implements a custom interface to memcache with a MySQL backend for data that drops out of memcache or is to big to be stored easily in memcache. I get annoyed at needing to include a global statement in every place I want to use memcache. > Thanks everyone, I knew this, but I didn't want to use runkit because it > is a beta, and i don't want all that other stuff, just superglobals. > Also, runkit only allows you to use php.ini, but my patch allows you to > specify superglobals in your script with the keyword "superglobal" by > saying: > > superglobal $var1, $var2 ; > > Thanks for your help though, if anyone else is interested in the patch > send me a message. > > This isn't something the developers would want to implement I assume, > but it would be useful if they would, at a very small cost too (the > patch probably under 50 lines, very simple code too). If anyone would > like the patch to be implemented in CVS, let me know. > > > > > […] > > -- Michael McGlothlin Southwest Plumbing Supply --- ## #33184 — Stanislav Malyshev — 2007-11-17T00:28:19+00:00 URL: https://externals.io/message/33178#33184 · In reply to: #33183 > I think the superglobal keyword is a great idea. I have a custom class > that implements a custom interface to memcache with a MySQL backend for > data that drops out of memcache or is to big to be stored easily in > memcache. I get annoyed at needing to include a global statement in > every place I want to use memcache. I don't think it's a good idea. Superglobals are special for a reason - if everybody would just add stuff into global space and make it superglobal because they can't type a couple of keystrokes, it would be a mess. Just declare a class and use statics or singletons. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33185 — Sam Barrow — 2007-11-17T00:31:34+00:00 URL: https://externals.io/message/33178#33185 · In reply to: #33183 Yes, and in even larger scale applications it can become even more useful. I have a web framework I'm working on, it's about 9,500 lines of code now with hundreds of functions/classes. Every function/method has to specify global for my 3 universal variables which contain large arrays of configuration information. With this, I can say "superglobal $mod, $sec, $cfg" in my root include file, and not worry about it again. > I think the superglobal keyword is a great idea. I have a custom class > that implements a custom interface to memcache with a MySQL backend for > data that drops out of memcache or is to big to be stored easily in > memcache. I get annoyed at needing to include a global statement in > every place I want to use memcache. > > […] > > > -- > Michael McGlothlin > Southwest Plumbing Supply --- ## #33186 — Sam Barrow — 2007-11-17T00:38:31+00:00 URL: https://externals.io/message/33178#33186 · In reply to: #33184 Well this is very common with PHP, it's very flexible and it's easy for a bad programmer to create chaotic code and get away with it, but this can happen with many features of PHP. For serious developers however, this could prove to be very useful when used appropriately. People will do what they will and make sloppy programs, but that's completely up to them. No point in holding stuff back from people who could benefit from it just to protect inexperienced them from their own sloppiness. You know what I mean? > > […] > > I don't think it's a good idea. Superglobals are special for a reason - > if everybody would just add stuff into global space and make it > superglobal because they can't type a couple of keystrokes, it would be > a mess. Just declare a class and use statics or singletons. --- ## #33187 — Sam Barrow — 2007-11-17T00:41:34+00:00 URL: https://externals.io/message/33178#33187 · In reply to: #33183 If anyone wants the patch, you can get it from my blog at http://www.sambarrow.com/. Keep in mind however I only tried it with PHP 5.3, I don't know if it will work on 5.2, as I am trying to transition to 5.3 completely because it has namespaces. > I think the superglobal keyword is a great idea. I have a custom class > that implements a custom interface to memcache with a MySQL backend for > data that drops out of memcache or is to big to be stored easily in > memcache. I get annoyed at needing to include a global statement in > every place I want to use memcache. > > […] > > > -- > Michael McGlothlin > Southwest Plumbing Supply --- ## #33188 — Sean Coates — 2007-11-17T01:36:50+00:00 URL: https://externals.io/message/33178#33188 · In reply to: #33185 > Yes, and in even larger scale applications it can become even more > useful. I have a web framework I'm working on, it's about 9,500 > lines of > code now with hundreds of functions/classes. Every function/method has > to specify global for my 3 universal variables which contain large > arrays of configuration information. With this, I can say "superglobal > $mod, $sec, $cfg" in my root include file, and not worry about it > again. class Config { const FOO = "Bar"; } function oink() { if (Config::FOO == 'Bar') { echo "OINK"; } } etc. IMO, you really don't need more superglobals. S --- ## #33191 — Stanislav Malyshev — 2007-11-17T02:00:25+00:00 URL: https://externals.io/message/33178#33191 · In reply to: #33186 > Well this is very common with PHP, it's very flexible and it's easy for > a bad programmer to create chaotic code and get away with it, but this > can happen with many features of PHP. For serious developers however, Right. This is why I don't think it's a good idea to add one more feature with very high potential for abuse. Code that changes behaviour of unrelated other code is usually very bad idea - think about what happens if some of your functions somewhere among 10K lines of code used $cfg as local variable and then you added $cfg as superglobal. > them. No point in holding stuff back from people who could benefit from > it just to protect inexperienced them from their own sloppiness. You > know what I mean? Yes, there is a point in not implementing features that would promote bad coding and unnecessary surprises for the users. Especially when the same function can be achieved with existing functionality in a much better way. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #33192 — Michael McGlothlin — 2007-11-17T02:09:15+00:00 URL: https://externals.io/message/33178#33192 · In reply to: #33186 PHP needs more options for both tighter and looser control of variables. I could use an extra superglobal here and there but I also suggested recently, without response, a way to make variables local to a chunk of code without it needing to be a function. Both would be useful in the right conditions - conditions that come up quite often in large programs. > Well this is very common with PHP, it's very flexible and it's easy for > a bad programmer to create chaotic code and get away with it, but this > can happen with many features of PHP. For serious developers however, > this could prove to be very useful when used appropriately. People will > do what they will and make sloppy programs, but that's completely up to > them. No point in holding stuff back from people who could benefit from > it just to protect inexperienced them from their own sloppiness. You > know what I mean? > > > > > […] > > -- Michael McGlothlin Southwest Plumbing Supply --- ## #33193 — Michael McGlothlin — 2007-11-17T03:26:07+00:00 URL: https://externals.io/message/33178#33193 · In reply to: #33188 So the idea now is to inappropriately force everything to be a class? > > […] > > class Config { > const FOO = "Bar"; > } > > function oink() { > if (Config::FOO == 'Bar') { > echo "OINK"; > } > } > > etc. > IMO, you really don't need more superglobals. > > S -- Michael McGlothlin Southwest Plumbing Supply --- ## #33194 — Sean Coates — 2007-11-17T03:34:03+00:00 URL: https://externals.io/message/33178#33194 · In reply to: #33193 > So the idea now is to inappropriately force everything to be a class? > > […] It is appropriate. That's how it was designed. Obviously superglobals were not designed to be user-definable. If configuration is defined in a class, then as a maintainer, you can easily determine where the data was defined (unless you do things are even less appropriate), but simply looking up the class. Globals (and superglobals) can be defined _anywhere_. This makes them a maintenance nightmare, and a very inappropriate place to store data such as configuration information. S --- ## #33195 — Michael McGlothlin — 2007-11-17T03:44:37+00:00 URL: https://externals.io/message/33178#33195 · In reply to: #33191 Stanislav Malyshev wrote: > > […] > > Right. This is why I don't think it's a good idea to add one more > feature with very high potential for abuse. Code that changes > behaviour of unrelated other code is usually very bad idea - think > about what happens if some of your functions somewhere among 10K lines > of code used $cfg as local variable and then you added $cfg as > superglobal. > > > […] > > Yes, there is a point in not implementing features that would promote > bad coding and unnecessary surprises for the users. Especially when > the same function can be achieved with existing functionality in a > much better way. This assumes there is never a good reason for a super global which makes me wonder why PHP has super globals at all then? What if, because I use it so often and want to differentiate it, it just works better for me to make it a super global? I could always name it with the standard $_ naming scheme so as to not run into accidental use. I don't often use globals but when I do it's usually because it's something I'll use a lot. It doesn't benefit code readability to have the same thing repeated hundreds of times. It's not a big issue but I do like the idea of making super globals easy to do. All this forcefulness of writing pristine code from the people that teach people that it's okay to inline their HTML, Javascript, CSS, SQL, and who knows what else into their PHP? Talk about a recipe for disaster. Oh well, at least you didn't refuse to add a switch statement like Python. --- ## #33196 — Sam Barrow — 2007-11-17T03:57:19+00:00 URL: https://externals.io/message/33178#33196 · In reply to: #33193 I agree, I wouldn't want to create a class just for one variable to be in it. It works, yes, but it's just not the clean way to do things. Why not allow maximum flexibility? > So the idea now is to inappropriately force everything to be a class? > > […] > > > -- > Michael McGlothlin > Southwest Plumbing Supply --- ## #33197 — Sam Barrow — 2007-11-17T04:06:36+00:00 URL: https://externals.io/message/33178#33197 · In reply to: #33191 However, if you're a programmer with a 10,000 line application, are you going to just forget that you've used your $cfg variable a hundred times, and accidentally make a new one? And the error is detectable. Maybe all superglobals could be required to start with an underscore, like _GET and _POST, to decrease confusion. I personally don't think this would be necessary, but it is a compromise. But what you're saying applies to the php superglobals too, what if someone makes a variable called _GET? It will have the same problem. And you can say, yeah but _GET is an obscure name, to that I would say we can require superglobals to start with underscores or something. But regardless, if someone specifies a superglobal it's on them to remember, it's not our job to protect a sloppy programmer who does stupid things in his coding. This feature would maybe be a disadvantage to a couple people who abuse the flexibility we give them, but it would benefit many more people. Flexibility does not hurt anyone except the people who abuse it. If they're going to make mistakes like this, they're going to make mistakes regardless. We don't have to hold back new features and flexibiltiy in order to prevent a couple of people from messing up. If everyone went by this logic then PHP would not even have functions, because people might use them wrongly. > > […] > > Right. This is why I don't think it's a good idea to add one more > feature with very high potential for abuse. Code that changes behaviour > of unrelated other code is usually very bad idea - think about what > happens if some of your functions somewhere among 10K lines of code used > $cfg as local variable and then you added $cfg as superglobal. > > > […] > > Yes, there is a point in not implementing features that would promote > bad coding and unnecessary surprises for the users. Especially when the > same function can be achieved with existing functionality in a much > better way. > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com --- ## #33198 — Sam Barrow — 2007-11-17T04:08:32+00:00 URL: https://externals.io/message/33178#33198 · In reply to: #33195 That's a good point too, usually when globals are used at all they are used in numerous functions It's very rare to see a variable that's used as a global in one or two functions. > This assumes there is never a good reason for a super global which makes > me wonder why PHP has super globals at all then? What if, because I use > it so often and want to differentiate it, it just works better for me to > make it a super global? I could always name it with the standard $_ > naming scheme so as to not run into accidental use. I don't often use > globals but when I do it's usually because it's something I'll use a > lot. It doesn't benefit code readability to have the same thing repeated > hundreds of times. It's not a big issue but I do like the idea of making > super globals easy to do. > Stanislav Malyshev wrote: > > […] > This assumes there is never a good reason for a super global which makes > me wonder why PHP has super globals at all then? What if, because I use > it so often and want to differentiate it, it just works better for me to > make it a super global? I could always name it with the standard $_ > naming scheme so as to not run into accidental use. I don't often use > globals but when I do it's usually because it's something I'll use a > lot. It doesn't benefit code readability to have the same thing repeated > hundreds of times. It's not a big issue but I do like the idea of making > super globals easy to do. > > All this forcefulness of writing pristine code from the people that > teach people that it's okay to inline their HTML, Javascript, CSS, SQL, > and who knows what else into their PHP? Talk about a recipe for > disaster. Oh well, at least you didn't refuse to add a switch statement > like Python. --- ## #33199 — Sam Barrow — 2007-11-17T04:09:00+00:00 URL: https://externals.io/message/33178#33199 · In reply to: #33195 But why not have maximum flexibility? A language should provide as many tools to the user as possible, a tool doesn't hurt. If you don't want to do it, don't, who cares? But an extra tool never hurts in any situation, real life or a programming language. Any language and any features of a language can be abused horribly by someone who doesn't know what they're doing. > Stanislav Malyshev wrote: > > […] > This assumes there is never a good reason for a super global which makes > me wonder why PHP has super globals at all then? What if, because I use > it so often and want to differentiate it, it just works better for me to > make it a super global? I could always name it with the standard $_ > naming scheme so as to not run into accidental use. I don't often use > globals but when I do it's usually because it's something I'll use a > lot. It doesn't benefit code readability to have the same thing repeated > hundreds of times. It's not a big issue but I do like the idea of making > super globals easy to do. > > All this forcefulness of writing pristine code from the people that > teach people that it's okay to inline their HTML, Javascript, CSS, SQL, > and who knows what else into their PHP? Talk about a recipe for > disaster. Oh well, at least you didn't refuse to add a switch statement > like Python. --- ## #33200 — Sam Barrow — 2007-11-17T04:18:36+00:00 URL: https://externals.io/message/33178#33200 · In reply to: #33194 You say that superglobals were not designed to be user defined, think about it, the concept of a superglobal is present in C and C++, two of the maturest and strictest languages around. > > […] > > It is appropriate. That's how it was designed. Obviously superglobals > were not designed to be user-definable. > > If configuration is defined in a class, then as a maintainer, you can > easily determine where the data was defined (unless you do things are > even less appropriate), but simply looking up the class. > > Globals (and superglobals) can be defined _anywhere_. This makes them > a maintenance nightmare, and a very inappropriate place to store data > such as configuration information. > > S --- ## #33201 — Rasmus Lerdorf — 2007-11-17T04:34:00+00:00 URL: https://externals.io/message/33178#33201 · In reply to: #33200 Sam Barrow wrote: > You say that superglobals were not designed to be user defined, think > about it, the concept of a superglobal is present in C and C++, two of > the maturest and strictest languages around. The concept of having to declare your globals is unique to PHP, true. It is one of the oldest features in PHP too. So, a little history... Back in 1989 I spent at least a month chasing a bug at a company in Canada called Bell Northern Research. It was a weird crash bug in a rather complicated system. It was mostly written in C and after pouring through reams and reams of code printouts day after day, I finally found that it was due to a side effect of some obscure function overwriting a global variable that was used in a completely different area of the code. That particular feature of the C language was not popular with me for a long time after that, and when it came time to work out function scoping of variables in PHP, I made sure to not make that same mistake. And yes, because PHP is a web language and there are common aspects of a web request that many functions will need to act on, it makes sense to have a finite number of clearly labeled global arrays like _GET, _POST, etc. And later on, being able to access any global via $_GLOBALS was added, but again, it is a very descriptive name and not likely to result in someone mistaking it for something else and ending up with strange side effects. I am definitely not in favor of destroying what I consider a rather good design decision just to avoid a couple of keystrokes here and there. So yes, you will have to keep adding "global $cfg;" to your functions, or accessing it via $_GLOBALS['cfg'], and when you forget, it won't work. And yes, you will grumble a bit at that, but that is nothing compared to trying to find a bug caused by a global side effect in someone else's code. Trust me, you will grumble a lot more at that. -Rasmus --- ## #33202 — Sam Barrow — 2007-11-17T04:39:54+00:00 URL: https://externals.io/message/33178#33202 · In reply to: #33201 I disagree, although you do have a very good point. But simple logic flaws can cause huge bugs regardless, whether it would be because of a superglobal or any other programmer error. Although you have a point, the only place where we disagree is that I think the benefits outweigh the risks. > Sam Barrow wrote: > > […] > > The concept of having to declare your globals is unique to PHP, true. > It is one of the oldest features in PHP too. So, a little history... > > Back in 1989 I spent at least a month chasing a bug at a company in > Canada called Bell Northern Research. It was a weird crash bug in a > rather complicated system. It was mostly written in C and after pouring > through reams and reams of code printouts day after day, I finally found > that it was due to a side effect of some obscure function overwriting a > global variable that was used in a completely different area of the > code. That particular feature of the C language was not popular with me > for a long time after that, and when it came time to work out function > scoping of variables in PHP, I made sure to not make that same mistake. > > And yes, because PHP is a web language and there are common aspects of a > web request that many functions will need to act on, it makes sense to > have a finite number of clearly labeled global arrays like _GET, _POST, > etc. And later on, being able to access any global via $_GLOBALS was > added, but again, it is a very descriptive name and not likely to result > in someone mistaking it for something else and ending up with strange > side effects. > > I am definitely not in favor of destroying what I consider a rather good > design decision just to avoid a couple of keystrokes here and there. So > yes, you will have to keep adding "global $cfg;" to your functions, or > accessing it via $_GLOBALS['cfg'], and when you forget, it won't work. > And yes, you will grumble a bit at that, but that is nothing compared to > trying to find a bug caused by a global side effect in someone else's > code. Trust me, you will grumble a lot more at that. > > -Rasmus --- ## #33203 — Sean Coates — 2007-11-17T05:23:23+00:00 URL: https://externals.io/message/33178#33203 · In reply to: #33201 > $_GLOBALS Don't meant to be too pedantic, but if anyone's looking for this in the archives, it's $GLOBALS, not $_GLOBALS. S --- ## #33204 — Larry Garfield — 2007-11-17T05:54:34+00:00 URL: https://externals.io/message/33178#33204 · In reply to: #33202 As a predecessor of mine at work devised not one but two systems that used global variables as their primary means of internal communication, and I got to sit next to the guy who had to debug and maintain both of them for a year before finally going insane and quitting, I have to agree with Rasmus. Typing "global" isn't just an extra six characters. It's being polite to the people who will have to maintain your code after you're gone. Undeclared globals are a form of extreme sadism, no matter how much documentation you think you've provided. Declared globals are merely ordinary, run-of-the-mill sadism. :-) I don't see a benefit in the first place. Singletons, collector functions, or as a last resort the global keyword are all viable alternatives. Leave extra superglobals to runkit where such weird edge cases belong. > I disagree, although you do have a very good point. But simple logic > flaws can cause huge bugs regardless, whether it would be because of a > superglobal or any other programmer error. Although you have a point, > the only place where we disagree is that I think the benefits outweigh > the risks. > > > > […] -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson --- Next page: https://externals.io/message/33178.md?page=2