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]) {
On Sat, 2007-11-17 at 18:03 -0800, Stanislav Malyshev 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.
Concept of inserting assembly code is in C
2007/11/17, Sam Barrow [EMAIL PROTECTED]:
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
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.
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
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
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
2007/11/17, Rasmus Lerdorf [EMAIL PROTECTED]:
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
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
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
On Fri, 2007-11-16 at 15:53 -0500, Sam Barrow wrote:
I am trying to develop a patch for personal use to enable custom
superglobals.
I seemed to
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:
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
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
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
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
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.
On Fri, 2007-11-16 at 17:23 -0700, Michael
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
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
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
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
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
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
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?
On Fri, 2007-11-16 at 20:26 -0700, Michael McGlothlin wrote:
So the idea now is to inappropriately force everything to be
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
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
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
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.
On Fri, 2007-11-16 at 22:34 -0500, Sean Coates wrote:
So the idea now is to inappropriately force everything
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
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.
On
$_GLOBALS
Don't meant to be too pedantic, but if anyone's looking for this in
the archives, it's $GLOBALS, not $_GLOBALS.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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.
On Fri, 2007-11-16 at 23:54
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
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.
On Sat, 2007-11-17 at 01:01 -0500, Sam Barrow wrote:
As i said you guys do have a point. But when you say leave custom
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
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
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.
On Fri, 2007-11-16 at 22:18 -0800, Rasmus Lerdorf wrote:
Sam Barrow wrote:
Just to make sure you understand me correctly, these are not
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,
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
On Sat, 2007-11-17 at 01:40 -0500, 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
On Saturday 17 November 2007, Sam Barrow wrote:
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
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.
On Fri, 2007-11-16 at 22:47 -0800, Rasmus Lerdorf wrote:
Sam Barrow wrote:
I don't understand, people keep telling me this can
42 matches
Mail list logo
