Page 1 of 4

Suggestions for PHP 6

Posted: Mon Feb 23, 2009 8:13 pm
by lovelf
Hello, who should I contact to suggest features for PHP 6 before its final release?

I would like to suggest to add a way to detect if a user has Flash turned on, Javascript turned on (easily, not like the methods we can use now for this), and some other features I do not remember right now.

Maybe detecting user screen resolution with PHP instead of Javascript would be good as well.

Re: Suggestions for PHP 6

Posted: Mon Feb 23, 2009 8:19 pm
by josh
Everything in the headers you can parse yourself, why don't you release the extension and if it found enough use someday someone could phpize it

Re: Suggestions for PHP 6

Posted: Mon Feb 23, 2009 9:36 pm
by Christopher
How would you use PHP to detect Flash or screen resolution? I think you need Javascript for that.

Re: Suggestions for PHP 6

Posted: Mon Feb 23, 2009 10:16 pm
by John Cartwright
Indeed, PHP has very little contact with the client. It is up to the client to send the information to PHP.

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 2:40 am
by lovelf
But PHP gets the user agent and which language is set by the user, why couldn't it retrieve that small info too, I would find it very practical, not to use js to see if flash is activated among other things.

Screen resolution.
Is javascript enabled or not.
Is flash enabled or not.

I think that would help.

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 2:44 am
by Weirdan
lovelf wrote:But PHP gets the user agent and which language is set by the user, why couldn't it retrieve that small info too,
PHP gets user agent string 'for free' (most browsers send it automatically). Unfortunately they don't tell server automatically if they support flash (or anything else from your list).

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 5:29 pm
by VirtuosiMedia
Well, if we get to suggest things for PHP6 :) , I'd like:
  • All of the functions and classes renamed in a consistent manner.
  • All of the parameters to be in the same order (needle, haystack anyone?).
  • Validators for emails and URLs that are RFC valid.
  • Everything as an object like in JavaScript.
  • The ability to extend native functions like in JavaScript.
  • Multiple inheritance.
  • Type hinting for strings.
  • Libraries that handle compression and graphics to be included by default.
  • A really good graphing library included by default.

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 7:21 pm
by josh
MI isn't gonna happen ( diamond problem ). Not even java supports it. I think scalar hinting wouldn't be too bad of an idea but their philosophy seems to be that dynamic languages shouldn't have that kind of stuff. I'm all for making the language consistent too but at the same that would be market share suicide for them. I think the flash detection plugin could be made into an extension that used javascript, it couldn't be pure PHP obviously.

What I'd love to see is methods becoming first order citizens and improved callback support. Anyone that's done something more than trivial in jQuery / javascript is likely to agree

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 8:50 pm
by alex.barylski
easily, not like the methods we can use now for this
You mean checking in JS and AJAX'ing the details to the server? :P

It's actually pretty simple. The only inherent problem is, upon first visit, the system cannot know whether the user has it enabled/disabled so you can optionally wait until they click a link to "enter" your site or redirect them auto-magically and I'm not sure how SE's would handle that.

If your site is that dependent on JS/Flash I would suggest you reconsider your design as accessibility is probably out the window and SEO is probably not a concern for you, in which case, a redirect might be a good solution. :)

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 9:10 pm
by alex.barylski
Validators for emails and URLs that are RFC valid.
I agree with the first two, but not this...outside the scope of PHP IMHO. It's easily accomplished using regex.
Everything as an object like in JavaScript.
I believe this is required due to the fact JS is a prototypical OO model. You could emulate this in PHP by simply creating String, Integer, etc wrappers, and just use __clone(). :P
Multiple inheritance.
There are times when MI would come in real handy (ie: building a single adapter to multiple interfaces) unfortunately like singletons, I can only see them being excessively abused and thus introducing the diamond of death problem. Very fragile hierarchies, single inheritence is bad enough when people go OO crazy. :P

The better solution is to use a mix-in -- which prevents convoluted hierarchies allowed by MI -- but offers all the benfits of automated delegation and composition.
Type hinting for strings.
If you want OO strings, again I would suggest wrapping the existing string functionality in an object interface. The __toString() method can be overriden to return the string value of the object so when you print or echo the object like:

Code: Select all

 
$str = new String('This is my object string');
$str->replace('Search', 'Replace');
 
echo $str; // You will actually get the string value of the string not the object
 
I have considered many times implementing such an object (inspired by STL string class) to fully support Unicode strings but with PHP6 being Unicode compliant I think I'll just wait. :)
Libraries that handle compression and graphics to be included by default.
That would probably make sense.
# A really good graphing library included by default.
Meh...read up on extension development and get started? :lol:

I'd rather use Flash and lose the ability to embed in PDF or printer friendly media.

What I would love to see is Operator overloading.

Also (although not really appropriate -- the alternative sux) some kind of macro/pre-processing support. Caching could be used to get around extraneous processing. I have tried a few times to get M4 integrated into my build environment and it's a mega PITA -- or I just got lazy or gave up. :P

Are we done dreaming yet? :P

EDIT | Also...I wish every method threw an exception (in addition to triggering errors -- for backwards compat) catching the error and throwing an exception is something I have considered doing (if it's even possible) but I'd prefer the core to just assume exceptional behavior as an alternative to errors.

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 9:52 pm
by Chris Corbyn
Anonymous objects...

Code: Select all

<?php
 
interface Observer {
  public function notify($message);
}
 
class Observable {
  public function addObserver(Observer $observer) {
    // .. snip ..
  }
  // .. snip ..
}
 
$o = new Observable();
 
$o->addObserver(new Observer() {
  public function notify($message) {
    echo "This observer was created inline and passes the 'instanceof Observer' test";
  }
});
 
$o->addObserver(new Observer() {
  public function notify($message) {
    echo "This observer also was created inline";
  }
});
That would come in real handy for one-time use objects such as little Matchers and EventListeners.

Accessor synthesizers...

I have no idea how this would work, but other languages find elegant solutions. I can't think of a neat way PHP could add this really... just a would be nice.

Code: Select all

<?php
 
class Something {
  private (accessors) $_foo;
  private (accessors=readonly) $_bar;
}
 
$obj = new Something();
$obj->setFoo('test');
echo $obj->getFoo(); //test
$obj->setBar('whetever'); //Error, $bar is readonly
 
Better namespaces...

At least we're getting namespaces, but we need support to import "Namespace::*" rather than class-by-class. If you're using a library like a testing framework, changes are you want to import the entire namespace.

Code: Select all

<?php
 
namespace MyPackage;
 
class A {
}
 
class B {
}

Code: Select all

<?php
 
import MyPackage::*;
 
$a = new A();
$b = new B();
Currently you need one import line for each and every class.

Re: Suggestions for PHP 6

Posted: Tue Feb 24, 2009 10:41 pm
by alex.barylski
Accessor synthesizers...

I have no idea how this would work, but other languages find elegant solutions. I can't think of a neat way PHP could add this really... just a would be nice.
If I understand correctly, then this is similar to adding the const modifier to C++ method making the function incapable of making any changes to any member variables -- functional programming?

I would actually like to see a const modifier added to PHP as a set once -- never worry again would sometimes come in handy.

There are actually quite a few useful features they could borrow from C++ -- there have been a few times I thought friend methods/classes would be handy.

I think the problem is many of these 'niceties' are compile time checks -- so having them carried out each invocation (unless they cached the results of this phase -- instead of just the parse tree) would slow execution considerably (potentially anyways -- if you used them religiously because your a paranoid developer -- I am so I am sure it would impede performance somewhat).

Are anonymous methods not like closures?

It would allow a syntactical sugar similar to something like jQuery they way you can expand the prototype of an object at runtime? That would be nice :)

EDIT | Just a quick google and the wiki:
While this is not always clarified, a closure need not be formed using an anonymous function.
Guess that answers my question :)

Re: Suggestions for PHP 6

Posted: Wed Feb 25, 2009 4:50 am
by VladSun
1. Operator overload
2. Method overload

3. Native getters and setters:

Code: Select all

class test 
{
    private $count;
 
    public $Count
    {
        set { $count = $value; }
        get { return $count; }
    }
}
4. Strict mode (like Perl "use strict;")

5. Integer values of 0 and 1 not accepted as Boolean values.

6. Try-catch blocks with a finally clause

7. etc. C++/C# features :) (e.g. http://blog.debreuil.com/archive/2004/05/05/274.aspx)

Re: Suggestions for PHP 6

Posted: Wed Feb 25, 2009 6:00 pm
by alex.barylski
Method overload
Personally I find that results in more confusing code. In a way it breaks the SRP (single responsibility principle) at the interface level, anyway. I know it's very common in C++ but like default parameters it leads to less explicit interfaces, which I am not generally a fan of.

Not strictly a bad design, but a bad practice if you subscribe to SRP and explicit interfaces.
Strict mode (like Perl "use strict;")
Interesting. Pragmas would be nice too, like macros.
Integer values of 0 and 1 not accepted as Boolean values.
== over === ???

I always use the latter now just to avoid any unexpected bugs due to inappropriate types...I hate PHP for this and so prefer a strictly typed language like C/C++.
Try-catch blocks with a finally clause
As I understand 'finally' is used as a __destruct() for exceptions -- assuming an dtor() is not invoked upon exception. WHat kind of resources would you need to release in a PHP application that the GC doesn't do you for intrinsically?

Re: Suggestions for PHP 6

Posted: Wed Feb 25, 2009 6:39 pm
by VladSun
PCSpectra wrote:== over === ???
No.
if (1) over if (true)

In other words, PHP should complain when non boolean result is used into an IF statement.
PCSpectra wrote:
Try-catch blocks with a finally clause
As I understand 'finally' is used as a __destruct() for exceptions -- assuming an dtor() is not invoked upon exception. WHat kind of resources would you need to release in a PHP application that the GC doesn't do you for intrinsically?
I had a situataion when I needed finally statement, but frankly I can't remember what was the case :) And I'm pretty sure it wasn't about anything the GC could do. (BTW there is a GC in C# also ;) )