Idea for PHP Enhancement: register_global s_manual

[127.0.0.1]

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration default.

What this does is enable 3 new explicit variable declaration mechanisms
with the same syntax as the existing static and global mechanisms.

They would be httpget, httppost and session, so for example:

httpget $user_id;
httppost $credit_card;
session $really_importa nt_stuff;

Each of these declaration lines would effectively enable
register_global s for one specific variable in one particular method
(GET, POST or session).

Creative suggestions, comments would be welcome.

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[Tom Lee]

This sounds like syntactic sugar for something like:

$user_id = $_GET['user_id'];
$credit_card = $_POST['credit_card'];
$really_importa nt_stuff = $_SESSION['really_importa nt_stuff'];

Admittedly, the last example is a bit long, but is that often a problem?

Is there some way to explode elements of an array into the local
namespace of a method?

Still, with all due respect, I can't see the reasoning to this other
than saving a few key strokes.

What's the rationale to this idea? What problem does it solve? Is it
really a problem?

Kind Regards,
Tom L

127.0.0.1 wrote:

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration default.

What this does is enable 3 new explicit variable declaration mechanisms
with the same syntax as the existing static and global mechanisms.

They would be httpget, httppost and session, so for example:

httpget $user_id;
httppost $credit_card;
session $really_importa nt_stuff;

Each of these declaration lines would effectively enable
register_global s for one specific variable in one particular method
(GET, POST or session).

Creative suggestions, comments would be welcome.

[127.0.0.1]

Tom Lee wrote:

This sounds like syntactic sugar for something like:

$really_importa nt_stuff = $_SESSION['really_importa nt_stuff'];

Not quite, it also adds the

$_SESSION['really_importa nt_stuff'] = $really_importa nt_stuff;

at the appropriate point in an exit routine which no longer needs to be
written.

Someone obviously thought register_global s was a good idea - and it is,
get rid of the carte-blanche approach and it is a great idea.

And anything above machine language is all syntactic sugar anyhow ...
why is that a problem ?

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[Justin Koivisto]

127.0.0.1 wrote:

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration default.

What this does is enable 3 new explicit variable declaration mechanisms
with the same syntax as the existing static and global mechanisms.

They would be httpget, httppost and session, so for example:

httpget $user_id;
httppost $credit_card;
session $really_importa nt_stuff;

Each of these declaration lines would effectively enable
register_global s for one specific variable in one particular method
(GET, POST or session).

Creative suggestions, comments would be welcome.

IMHO, get rid of regist_globals altogether. ;P

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

[Paulus Magnus]

"127.0.0.1" <newsgroup(at)c r*********@veri sign-sux-ijlkl.com> wrote in
message news:s3******** ************@ne ws-server.bigpond. net.au...

With all the problems with having register_global s = on, I propose the
following idea:

We define register_global s_manual = on as a new configuration default.

What this does is enable 3 new explicit variable declaration mechanisms
with the same syntax as the existing static and global mechanisms.

They would be httpget, httppost and session, so for example:

httpget $user_id;
httppost $credit_card;
session $really_importa nt_stuff;

Each of these declaration lines would effectively enable
register_global s for one specific variable in one particular method
(GET, POST or session).

Creative suggestions, comments would be welcome.

As much inconvenience as register_global s has caused me personally, I do
believe the world is a safer place because of it being changed. A
programming language often provides shortcuts for programmers and they
partly attract us to that language due to the speed at which we can develop
our applications. However, over time these shortcuts often lead to security
issues or lead us into bad programming style. If the tools to write bad,
insecure code are not there we're less likely to do it.

Paulus

[Tom Lee]

127.0.0.1 wrote:

Tom Lee wrote:

This sounds like syntactic sugar for something like:

$really_impor tant_stuff = $_SESSION['really_importa nt_stuff'];

Not quite, it also adds the

$_SESSION['really_importa nt_stuff'] = $really_importa nt_stuff;

at the appropriate point in an exit routine which no longer needs to be
written.

References?

$really_importa nt_stuff =& $_SESSION['really_importa nt_stuff'];

Should accomplish the same thing.
Someone obviously thought register_global s was a good idea - and it is,
get rid of the carte-blanche approach and it is a great idea.

I think a better approach would be namespace based - ala something like:
httpsession::re ally_important_ stuff;

The current PHP way of doing it is rather similar: it's a hack using
arrays to emulate namespaces.

And PHP 5 won't change the fact that there's no real namespaces in PHP.
How sad.

But I digress.
And anything above machine language is all syntactic sugar anyhow ...
why is that a problem ?

It's not so much about why it's a problem as it is about why it's necessary.

IMO, it's not. At least, not for a minor version upgrade. Maybe PHP 5,
but that feature set is largely set in stone afaik.

And even then I think namespaces are a better way to go about it.
There's a greatly reduced chance of variable naming getting in the way.
And as I said, PHP currently (sorta) implements this approach with arrays.

I agree that there's probably nicer ways to go about it syntactically,
but on the level that it's merely saving a few key strokes? I'd rather
take my chances avoiding namespace collisions, thanks.

[127.0.0.1]

Justin Koivisto wrote:

IMHO, get rid of regist_globals altogether. ;P

Why ?

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[127.0.0.1]

Paulus Magnus wrote:

As much inconvenience as register_global s has caused me personally, I
do believe the world is a safer place because of it being changed.

So - any comments on the concept of a modified register_global s ability
?

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>

[Justin Koivisto]

127.0.0.1 wrote:

Justin Koivisto wrote:

IMHO, get rid of regist_globals altogether. ;P

Why ?

Then the facility to be sloppy isn't available. Force everyone to be a
little better coder. Besides, if you _really_ waned to, you can alwas do
something like extract($_REQUE ST) to have (I think) the same effect.
Therefore, in order to be sloppy, you have to go out and try to do it. :P

I used to do everything with register_global s on, and quickly learned
that it's a nightmare to debug when you happen to be using the same
variable name via POST and GET requests. Add that in with having the
variable also stored with COOKIES and a database, and you can see why it
causes more problems - you are never quite sure where the value came from.

My $.02

--
Justin Koivisto - sp**@koivi.com
PHP POSTERS: Please use comp.lang.php for PHP related questions,
alt.php* groups are not recommended.

[127.0.0.1]

Tom Lee wrote:

I think a better approach would be namespace based - ala something
like: httpsession::re ally_important_ stuff;
Then it would be pointless ... if we have to use XXXX<varname>XX XX,
then XXXX might as well be $_SESSION, as httpsession:: ... i'm trying
to come up with a secure version of register_global s...

And anything above machine language is all syntactic sugar anyhow
... why is that a problem ?

It's not so much about why it's a problem as it is about why it's
necessary.

IMO, it's not.

Well - after 7 years of web programming Delphi/IIS, I'm finding PHP
session handling in conjunction with templating a real problem.

I agree that there's probably nicer ways to go about it
syntactically, but on the level that it's merely saving a few key
strokes?

It isn't about saving keystrokes - it is about enabling some
functionality.. .

--
Spam:newsgroup( at)cr*********@ verisign-sux-klj.com
EMail:<01100011 001011100110001 001110101011100 10011010110
110010101000000 011000110111001 001100001011110 10011011100
110000101110010 001011100110001 101101111011011 0100100000>