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
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.
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
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.
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.phpjohannes
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.
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.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.phpjohannes
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.
--
Michael McGlothlin
Southwest Plumbing Supply
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
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 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.
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
Stanislav Malyshev wrote:
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.
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.
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:
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.
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.
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:
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.
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.
2007/11/17, Sam Barrow sam@sambarrow.com:
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.
I disagree. A new tool is only more trouble if there's already a more
elegant way to solve the problem. If you ever worked on a big project which
uses perl for some parts of the processing, you'll know what I mean. There
can't be any actual teamwork if every damn perl programmer writes the same
code in a different way. And don't even try imposing some coding convention,
they will just argue for days which and why is the more elegant way to code
anything, even a damn if branch!
2007/11/17, Sam Barrow sam@sambarrow.com:
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.
I highly recommend reading Murphy's Law. There is a whole section on
software development that will enlighten you.
2007/11/17, Sam Barrow sam@sambarrow.com:
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.
I have a specially crafted bat that's only for teaching coders that they
should not use globals in C/C++ (specially C++). I ordered another one for
PHP coders, but had to send it back to be adjusted (compatibility problems
with PHP5).
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
There is a good reason, and exactly for things that PHP has as
superglobals. Because these variables - system variables - are unique
and well-known.
We have to balance between cases where some dangerous functionality can
be useful, and cases where some useful functionality can be dangerous.
For superglobals, user-defined ones have danger far outweight the
usefulness, and we have a number of good and working alternatives, so
the case seems to be clear.
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.
We do not (at least I do not :) refuse things just because we like to be
purists and torture developers. There's a good reason for that, and I
believe it was explained in the emails in this thread.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.
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
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?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.
--
Michael McGlothlin
Southwest Plumbing Supply
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.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.phpjohannes
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.
--
Michael McGlothlin
Southwest Plumbing Supply
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
So the idea now is to inappropriately force everything to be a class?
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
--
Michael McGlothlin
Southwest Plumbing Supply
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
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.
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
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
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:
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
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.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
--
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
As i said you guys do have a point. But when you say leave custom
superglobals to runkit, you might as well leave them to my patch.
You have to specifically declare superglobals, just like in runkit. No
difference between this and using runkit except ease of use.
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.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
--
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
Just to make sure you understand me correctly, these are not at all
undeclared globals (as you said). You have to specifically turn on the
variables you want to be superglobals.
As i said you guys do have a point. But when you say leave custom
superglobals to runkit, you might as well leave them to my patch.You have to specifically declare superglobals, just like in runkit. No
difference between this and using runkit except ease of use.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.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
--
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
Sam Barrow wrote:
Just to make sure you understand me correctly, these are not at all
undeclared globals (as you said). You have to specifically turn on the
variables you want to be superglobals.
They are undeclared in the individual functions where they are used.
You can declare them all you want in your part of a large project, but
the fact is that they end up in the superglobal namespace and developer
#2 working on another part of the code has no idea that you made up your
own superglobal and what used to be a function-local variable in his
code suddenly isn't anymore.
-Rasmus
True. What if we created a php.ini directive that defaulted to off that
would determine the ability to declare superglobals,
"allow_superglobals" or something.
Sam Barrow wrote:
Just to make sure you understand me correctly, these are not at all
undeclared globals (as you said). You have to specifically turn on the
variables you want to be superglobals.They are undeclared in the individual functions where they are used.
You can declare them all you want in your part of a large project, but
the fact is that they end up in the superglobal namespace and developer
#2 working on another part of the code has no idea that you made up your
own superglobal and what used to be a function-local variable in his
code suddenly isn't anymore.-Rasmus
True. What if we created a php.ini directive that defaulted to off that
would determine the ability to declare superglobals,
"allow_superglobals" or something.
Does your code live in a bubble? Allowance of of arbitrary super global
definitions would open a can of local variable clobbering worms.
A php.ini directive won't make this reality any more palatable.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
I don't understand, people keep telling me this can cause problems so
it's trash. Really? Functions and variables can cause problems too. Not
to mention user input. Programming is not easy, but the more flexible it
is the better. I think it's up to the programmer to keep track of his
variables, rather than us limiting his functionality, just incase he
makes a mistake.
Any programmer can write bad code and it won't work. If he uses
superglobals he should understand that he needs to document them, it's
that simple. If that's too difficult, don't create a superglobal then,
great.
And if this isn't good enough, fine. Require an underscore for
superglobals to differentiate them even more. I'll write the code
myself, no problem.
True. What if we created a php.ini directive that defaulted to off that
would determine the ability to declare superglobals,
"allow_superglobals" or something.Does your code live in a bubble? Allowance of of arbitrary super global
definitions would open a can of local variable clobbering worms.A php.ini directive won't make this reality any more palatable.
Cheers,
Rob............................................................
SwarmBuy.com - http://www.swarmbuy.comLeveraging the buying power of the masses!...........................................................
Sam Barrow wrote:
I don't understand, people keep telling me this can cause problems so
it's trash. Really? Functions and variables can cause problems too. Not
to mention user input. Programming is not easy, but the more flexible it
is the better. I think it's up to the programmer to keep track of his
variables, rather than us limiting his functionality, just incase he
makes a mistake.Any programmer can write bad code and it won't work. If he uses
superglobals he should understand that he needs to document them, it's
that simple. If that's too difficult, don't create a superglobal then,
great.And if this isn't good enough, fine. Require an underscore for
superglobals to differentiate them even more. I'll write the code
myself, no problem.
We simply don't think this flexibility makes up for the potential
confusion it can cause. It isn't solving something that can't be done,
it is just changing a minor syntax and concept which has been in place
for the past 12 years of PHP. To be completely blunt, this change has
no chance of making it into PHP. If you want it, you will have to
maintain your own patch.
-Rasmus
Ok forget it if anyone wants the patch just send me an email. By the way
i didn't mention it also includes a function that retrieves the list of
current superglobals.
Sam Barrow wrote:
I don't understand, people keep telling me this can cause problems so
it's trash. Really? Functions and variables can cause problems too. Not
to mention user input. Programming is not easy, but the more flexible it
is the better. I think it's up to the programmer to keep track of his
variables, rather than us limiting his functionality, just incase he
makes a mistake.Any programmer can write bad code and it won't work. If he uses
superglobals he should understand that he needs to document them, it's
that simple. If that's too difficult, don't create a superglobal then,
great.And if this isn't good enough, fine. Require an underscore for
superglobals to differentiate them even more. I'll write the code
myself, no problem.We simply don't think this flexibility makes up for the potential
confusion it can cause. It isn't solving something that can't be done,
it is just changing a minor syntax and concept which has been in place
for the past 12 years of PHP. To be completely blunt, this change has
no chance of making it into PHP. If you want it, you will have to
maintain your own patch.-Rasmus
I don't understand, people keep telling me this can cause problems so
it's trash. Really? Functions and variables can cause problems too. Not
to mention user input. Programming is not easy, but the more flexible it
is the better. I think it's up to the programmer to keep track of his
variables, rather than us limiting his functionality, just incase he
makes a mistake.Any programmer can write bad code and it won't work. If he uses
superglobals he should understand that he needs to document them, it's
that simple. If that's too difficult, don't create a superglobal then,
great.And if this isn't good enough, fine. Require an underscore for
superglobals to differentiate them even more. I'll write the code
myself, no problem.
This isn't the same issue as functions and classes residing in the same
global namespace. This is a problem with a single declaration affecting
variables having the same name in EVERY scoping context.
If you redefine a function --> ERROR
If you redefine a class --> ERROR
If you define a super global named $cfg -->
NO ERROR, NO WARNING, NO NOTICE
GLOBAL CLOBBERING of ALL variables names $cfg in global scope,
local function scope, class method scope.
That's one hell of a problem to track down to save a few lazy people
some keystrokes that in their naivety they think is for the greater
good.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
I don't understand, people keep telling me this can cause problems so
it's trash. Really? Functions and variables can cause problems too. Not
That's the core of the misunderstanding - your superglobals proposal has
much higher potential for causing problems than "functions and
variables" in general. It is born to cause trouble, so to say :) This is
the important point - not all features are created equal, some of them
are more trouble-prone than other.
And given that I personally don't see a lot of welcoming cheers on the
list, I say the chance of it happening in core PHP is quite low.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
As i said you guys do have a point. But when you say leave custom
superglobals to runkit, you might as well leave them to my patch.You have to specifically declare superglobals, just like in runkit. No
difference between this and using runkit except ease of use.
Exactly. I don't want it to be easy for incompetent programmers to write code
that is physically impossible for me to maintain, because I will inherit it
and I will lose hair trying to figure out why the frel this variable is doing
something weird in random cases.
I see it in a similar light as register_globals. Yes, one can write secure
code with register_globals on. But it's so much easier to write code that
isn't a nightmare to maintain if you start with it off. We should not be
making it easy for programmers to write unmaintainable code. Writing code
that is going to make me want to kill the programmer who wrote it should be
difficult, not easy. :-)
--
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
You have to specifically declare superglobals, just like in runkit. No
difference between this and using runkit except ease of use.
As you noticed, runkit is not a standard module of PHP. And for a good
reason - runkit it's for doing things that you are not supposed to do
with PHP, but since you feel so confident you know what you are doing,
here's an extension for you. Superglobals belong exactly to this area.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
$_GLOBALS
Don't meant to be too pedantic, but if anyone's looking for this in
the archives, it's $GLOBALS, not $_GLOBALS.
S
2007/11/17, Rasmus Lerdorf rasmus@lerdorf.com:
Trust me, you will grumble a lot more at that.
I agree, This is usually not a problem when you are the only person
that looks at a very small amount of code, but later when app gets
bigger it becomes and unmanteniable mess and I dont want the language
to contribute more problems.
This suggestion is a bad thing(tm) ;-)
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.
Concept of inserting assembly code is in C and C++ too. That doesn't
mean it's a good idea to add it to PHP. C and C++ are low-level
languages that were designed for giving people "enough rope". PHP is not
so.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.Concept of inserting assembly code is in C and C++ too. That doesn't
mean it's a good idea to add it to PHP. C and C++ are low-level
languages that were designed for giving people "enough rope". PHP is not
so.
I didn't notice Sam's above post abut C and C++ before. Unlike PHP, C
and C++ require you declare your variables. Any locally declared
variables have precedence over globally defined variables and so there's
only risk of confusion if you forget to declare your local variable.
This clearly puts usefulness of C/C++ globals and PHP globals in
different arenas.
Cheers,
Rob.
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
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?
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
--
Michael McGlothlin
Southwest Plumbing Supply
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.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.phpjohannes
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.
--
Michael McGlothlin
Southwest Plumbing Supply
Sam Barrow wrote:
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 ;
I don't get why you can't just use a Registry pattern here. Having a
simpleRegistry object that you can throw data into and pull out of not only
allows you to keep your global space clean, but allows you to encapsulate
your "global" data and access it via a simple interface. Sure, it might be a
few extra keystrokes to type something akin to: Registry::get('var1'); but,
personally, I think the trade-off is well worth it.
simple example class:
class Registry {
protect function __construct() {} // no instantiation - static class
static protected $data = array();
static public function get($name) {
return (isset(self::$data[$name]) ? self::$data[$name] : null);
}
static public function set($name, value) {
self::$data[$name] = $value;
}
}
summary: why "fix" what ain't really broke...?
Cheers!,
--
Carl
Not a bad idea, however in my case (don't know about others) I have very
deep arrays i use for my configuration. This would be more of a pain to
use with these get and set functions. Also, the performance would
probably be worse than just directly accessing the variable.
Good point about not fixing what's not broken, but I think in this
context it couldn't hurt to fix it. I have already fixed it, my patch is
already written and I will continue testing it but I haven't come across
any problems using it.
Sam Barrow wrote:
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 ;
I don't get why you can't just use a Registry pattern here. Having a
simpleRegistry object that you can throw data into and pull out of not only
allows you to keep your global space clean, but allows you to encapsulate
your "global" data and access it via a simple interface. Sure, it might be a
few extra keystrokes to type something akin to: Registry::get('var1'); but,
personally, I think the trade-off is well worth it.simple example class:
class Registry {
protect function __construct() {} // no instantiation - static class
static protected $data = array();static public function get($name) { return (isset(self::$data[$name]) ? self::$data[$name] : null); } static public function set($name, value) { self::$data[$name] = $value; }}
summary: why "fix" what ain't really broke...?
Cheers!,
--
Carl
Off the cuff, may have a bug or two, but you get the idea:
function get_config() {
static $config;
if (empty($config)) {
// Something to load the configuration here.
}
$params = func_get_args();
$return = $config;
foreach ($params as $param) {
if (isset($return[$param]) {
$return = $return[$param];
}
else {
trigger_error(...);
}
}
return $return;
}
$bob = get_config('thing', 'silly', 'bob');
No, not as fast as global $config;, but more self-documenting and therefore
easier to maintain and the difference is smaller than the cost of one SQL
query.
Human cycles cost more than CPU cycles.
Not a bad idea, however in my case (don't know about others) I have very
deep arrays i use for my configuration. This would be more of a pain to
use with these get and set functions. Also, the performance would
probably be worse than just directly accessing the variable.Good point about not fixing what's not broken, but I think in this
context it couldn't hurt to fix it. I have already fixed it, my patch is
already written and I will continue testing it but I haven't come across
any problems using it.Sam Barrow wrote:
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 ;
I don't get why you can't just use a Registry pattern here. Having a
simpleRegistry object that you can throw data into and pull out of not
only allows you to keep your global space clean, but allows you to
encapsulate your "global" data and access it via a simple interface.
Sure, it might be a few extra keystrokes to type something akin to:
Registry::get('var1'); but, personally, I think the trade-off is well
worth it.simple example class:
class Registry {
protect function __construct() {} // no instantiation - static class
static protected $data = array();static public function get($name) { return (isset(self::$data[$name]) ? self::$data[$name] : null); } static public function set($name, value) { self::$data[$name] = $value; }}
summary: why "fix" what ain't really broke...?
Cheers!,
--
Carl
--
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
If i were to implement some type of patch, could i define a php constant
to indicate the patch has been applied while staying within the php
naming conventions? If so, what should i prefix with?
If i were to implement some type of patch, could i define a php constant
to indicate the patch has been applied while staying within the php
naming conventions? If so, what should i prefix with?
I don't think we have any standard for third-party engine functionality
detection. Since you add a function there, maybe you could do just with
function_exists("get_my_superglobals")?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com