Jump to content

Recommended Posts

Something they should seriously consider adding: a parse error if 'global' is used within class code, and a warning if it's used anywhere else.  It's the latter half of 2012, yet I still see 'global' used frequently both here and on Stack Overflow.  Ridiculous.

 

While i don't disagree with you at all, i fear half of the web would explode!  Look at the fallout from GoDaddy's hosting services' recent changes.  If there are websites out there relying on software source last updated 10 years ago, how can ye hath faith phasing global out would accomplish much at all.  :confused:

 

Sometimes a bit of pain is necessary to make positive change.

 

Besides, like I said, in most cases (procedural code) it would merely produce a "Are you SURE you want to do it like that?" warning, which could be turned off via php.ini.  It would only result in an error within class code because if you're merrily blowing apart encapsulation with a global, you're doing it wrong anyway.  I don't see why the language itself should be complicit in such foolishness.

  • Replies 123
  • Created
  • Last Reply

Top Posters In This Topic

I don't see why the language itself should be complicit in such foolishness.

 

I have mixed feelings about this. Global is one of very many things that you can use wrongly in PHP. Should the language enforce good practices for everything? If not, why is Global so special?

I was looking through the RFC's the other day and spotted the loop+else one.

 

Very little discussion happend for this particular RFC, so whether it has a good chance of being introduced or not is up in the air. That said, the lack of discussion is telling; useful things usually get more chatter.

 

Have Ruby/C# style object properties gotten the go-ahead yet?

 

Not yet, and this particular horse has been running for some time.  Comments on the idea are positive, with very few dissenting voices.  There have been lots of minor tweaks as particular implementation details get hammered out.  The outlook is positive for this one, but no vote has been held nor any code committed.

 

Something they should seriously consider adding: a parse error if 'global' is used within class code, and a warning if it's used anywhere else.  It's the latter half of 2012, yet I still see 'global' used frequently both here and on Stack Overflow.  Ridiculous.

 

I may have to bear the brunt of your scoffing, but will continue to use global regularly.  So long as @global is made to work, I'd accept your suggestion. :shy:

 

I don't see why the language itself should be complicit in such foolishness.

 

I have mixed feelings about this. Global is one of very many things that you can use wrongly in PHP. Should the language enforce good practices for everything? If not, why is Global so special?

 

To me, 'global' is special because it isn't necessary at all, and is a direct cause of brittle code.  To me, it falls close to other such language 'features' as register globals and magic quotes.

Jeeze, you'd have a hard time with a language such as Perl or Bash then huh?

 

Could be.  I used Perl once, about 10 years ago, but didn't like it (it was a rush job by a college instructor, so he glossed over a lot, leading to a lot of "Huh?" moments).  Never used Bash.

In both Bash and Perl you have to declare variables as local within functions (and some other constructs), otherwise, they are global by default.

That seems to be how every newbie thinks variable scope works, so maybe they're onto something there :-P

In both Bash and Perl you have to declare variables as local within functions (and some other constructs), otherwise, they are global by default.

 

Huh.  So, do they not have function parameters?

 

They do. This is a JavaScript example, which works on the same principle:

var foo = 'bar';

function a()
{
    console.log(foo);
}

a(); // foo

...

function a()
{
    var foo = 'bar';
}

a();

console.log(foo); // undefined

In both Bash and Perl you have to declare variables as local within functions (and some other constructs), otherwise, they are global by default.

 

Huh.  So, do they not have function parameters?

 

They do. This is a JavaScript example, which works on the same principle:

var foo = 'bar';

function a()
{
    console.log(foo);
}

a(); // foo

...

function a()
{
    var foo = 'bar';
}

a();

console.log(foo); // undefined

 

Okay, but in JavaScript, you can combat that a bit by forcing scope, either by an object literal or self-invoking anonymous function.  Do Perl or Bash have any such mechanisms?

Eh, I'm a little rusty on my Perl, but you can use my, local, and our modifiers to change scope. I don't think any of these change how a function sees outside variables, but it changes the way packages see outside variables.

 

EDIT: And, those modifiers change how the program sees variables declared in the function.

sub a {
    $foo = 'bar'; // this is global
}

...

sub a {
    my $foo = 'bar'; // this is not global
}

  • 2 weeks later...

http://forums.phpfreaks.com/index.php?topic=365312.0

 

As in this, I think they should add a  parameter to be set true or FALSE while using in_array to specify a string match.  Let's say I don't want to find the whole array, just to match a particular string or whatever.

 

Pyscho already posted a fix to it, but would be a plausible idea for PHP6.  Would be helpful as well.

 

Cheers

 

No.

 

Indeed.

 

I am a little torn over how I feel about it being its own function. Granted, it might be useful some time. But, I think the PHP core library is already saturated enough with edge-case functions, so I would probably vote against it.

A quote of mine from the post in question

. . . why would you expect a function to do something it was not designed to do because YOU have a particular need? There are functions to do "key" things and then it's up to the programmer to put on his thinking cap and write some logical code.

 

If there was a built-in function for everything it would be impossible to find what you needed - even with a manual. Besides, what fun would programming be if all you were doing was looking up functions instead of really creating something that takes skill. Some people are simply not built to be programmers. But, that's OK, I suck at design.

Well Id say PHP 6 needs to make Array and String as objects by default. For Arrays, numeric arrays are accessed using the square bracket notation($array[0], $array[1]), while for associative arrays the ->operator should be used($array->field1, $array->field2). Also I am surprised no one on php rfc has ever suggested inner/nested classes, which is kinda surprising seeing how even static class was brought up a while ago. Anyone interested in making a push for inner/nested class?

http://forums.phpfreaks.com/index.php?topic=365312.0

 

As in this, I think they should add a  parameter to be set true or FALSE while using in_array to specify a string match.  Let's say I don't want to find the whole array, just to match a particular string or whatever.

 

Pyscho already posted a fix to it, but would be a plausible idea for PHP6.  Would be helpful as well.

 

Cheers

 

 

In_array already qupports a third argument.

I would say this is a retarded topic since PHP6 has been canned and they are moving straight to PHP10.

 

Apparently they are going to do a reboot, nice FU to all those haters. They are going to call it: NotRuby.

 

 

PS: and they are going to make all arguments of all functions/methods random (optional becomes mandatory, and more fun stuff like that).

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.