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 ca
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 runk
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
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 t
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, rat
On Sat, 2007-11-17 at 01:21 -0500, Sam Barrow wrote:
> 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
definit
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
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?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
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 yo
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 fixin
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
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
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 -0600
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 Rasm
$_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
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 Fri
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 o
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
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
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 a
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,
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
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
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 de
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 globa
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 condi
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 ver
We actually had spoken of that on irc a few times and a while ago, the
answer I got back was basically, "If you want java, use java"...
On Nov 16, 2007 8:40 PM, Cristian Rodriguez <[EMAIL PROTECTED]> wrote:
> 2007/11/15, Sam Barrow <[EMAIL PROTECTED]>:
> >
> > I found a patch by Derick online to a
2007/11/15, Sam Barrow <[EMAIL PROTECTED]>:
>
> I found a patch by Derick online to allow for scalar type hinting, and
> made it work with the newest snapshot of PHP 5.3.
IIRC Hannes had a patch to implement this the right way, but
unfortunately it has not been merged.
.
Hopefully he can publish a
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 configu
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 McGlothl
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 w
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 configurati
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 wa
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 wa
I think it's a good idea and would be useful in unix-world too (we
have a hell-lot of compilers and versions these days)
On 11/16/07, Steph Fox <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This is just a suggestion at this stage, I'd like to test the waters with it
> before writing a patch.
>
> Apropo
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:
superg
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
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: http://www.p
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
On 16.11.2007 11:26, Stanislav Malyshev wrote:
>> logistics, and then it struck me that it might be useful for _everybody_
>> to have compiler info (make/version) as part of the string returned from
>> php -v, probably alongside the build date. We could then sanely ask for
>> that information as
Hello Stanislav,
same here. Especially since phpinfo can be accessed very easy from command
line too: php -i
marcus
Friday, November 16, 2007, 9:26:59 AM, you wrote:
>> logistics, and then it struck me that it might be useful for _everybody_
>> to have compiler info (make/version) as part
Hi
Sending a reminder for CVS id request that i had sent earlier. I haven't
heard any thing on this. Please provide an CVS id so that i can commit my
testcases.
Thank you,
Regards
Dharma
Lorenzo Alberton wrote:
I talked to Christopher Jones (of Oracle fame) and Lorenzo (MDB2
maintainer). Its clear that the only named parameter supporting
database I know does not support dash inside named parameters. Its
also dangerous since it means that whitespace typos could have
serious
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 attribu
Hi all,
This is just a suggestion at this stage, I'd like to test the waters with it
before writing a patch.
Apropos the VS discussion, I was thinking about suffixing the PHP version
number in these 'beta builds', to help with the ensuing QA logistics, and
then it struck me that it might be
I want to contribute translating the documentation to Portuguese, as well as
submitting patches or new built-in functions
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Johannes,
I talked to Christopher Jones (of Oracle fame) and Lorenzo (MDB2
maintainer). Its clear that the only named parameter supporting
database I know does not support dash inside named parameters. Its
also dangerous since it means that whitespace typos could have
serious hard to spot
Lukas,
On Wed, 2007-11-14 at 16:49 +0100, Lukas Kahwe Smith wrote:
> On 01.11.2007, at 00:56, Lorenzo Alberton wrote:
>
> > Lukas Kahwe Smith wrote:
> >> I talked to Christopher Jones (of Oracle fame) and Lorenzo (MDB2
> >> maintainer). Its clear that the only named parameter supporting
> >>
logistics, and then it struck me that it might be useful for _everybody_
to have compiler info (make/version) as part of the string returned from
php -v, probably alongside the build date. We could then sanely ask for
that information as part of PHP bug reports.
I don't think it belongs to php
50 matches
Mail list logo
