88

Since it's the holiday season now and everybody's making wishes, I wonder - which language features you would wish PHP would have added? I am interested in some practical suggestions/wishes for the language. By practical I mean:

  1. Something that can be practically done (not: "I wish PHP would guess what my code means and fix bugs for me" or "I wish any code would execute under 5ms")
  2. Something that doesn't require changing PHP into another language (not: "I wish they'd drop $ signs and use space instead of braces" or "I wish PHP were compiled, statically typed and had # in it's name")
  3. Something that would not require breaking all the existing code (not: "Let's rename 500 functions and change parameter order for them")
  4. Something that does change the language or some interesting aspect of it (not: "I wish there was extension to support for XYZ protocol" or "I wish bug #12345 were finally fixed")
  5. Something that is more than a rant (not: "I wish PHP wouldn't suck so badly")

Anybody has any good wishes?

Mod edit: Stanislav Malyshev is a core PHP developer.

Macneil
  • 8,223
StasM
  • 3,377
  • 2
    I like constructors the old way better. – johnny Dec 17 '10 at 22:57
  • 9
    @Stan: Much as you'd like to avoid that kind of comment, you're going to get it anyway. The problems people have with PHP are largely in the categories of things you're ruling out in your post. [...] – Fishtoaster Dec 19 '10 at 00:56
  • 24
    [...] You're saying "How can we improve the experience of getting hit in the face without actually not hitting you in the face?" I mean, yes, getting free coffee while we're being hit in the face might be nice, it doesn't really address a lot of the underlying problems with, well, being hit in the face. So, while I hope you get some useful answers here (as there already appear to be), don't be surprised by unproductive ones. – Fishtoaster Dec 19 '10 at 00:59
  • 5
    @Fishtoaster: if PHP associates with being hit in the face for you, by all means keep away from it. You are most definitely not interested in improving it. It so happens though there are people who are. This topic is for them, not for you. I'm sure this site has a lot of topics for you too, this is just not one of them. – StasM Dec 19 '10 at 07:57
  • 5
    I'm using getting hit in the face as an example- a situation where superficial improvements aren't that important; when most people's problems are with the underlying thing. I'm not even knocking your attempt to get suggestions for those superficial improvements- I'm just pointing out why you're likely to get a few unhelpful answers, given the situation. – Fishtoaster Dec 19 '10 at 08:23
  • 3
    @Fishtoaster: I am aware of the fact that some people would rather rant than contribute. I don't think there's any "situation" here, and so far majority of the answers were useful and helpful, for which I am grateful. If somebody still uses this opportunity to vent - well, I hope he feels better after that :) – StasM Dec 19 '10 at 09:20
  • 6
    @Fishtoaster: Not everyone, surprisingly, hates PHP - I have always liked it. Very flexible and quick (to code). – Orbling Dec 19 '10 at 14:52
  • 1
    @StasM: Talking the design, PHP lacks AFAIK The Specification - you know, the great one. Doc is awesome (even if it has great holes), but there is not specification. If you take look at stackoverflow, there is many questions (concerning ie. C/C++, C#, Python, Javascript, SQL) which could be responded because there exists clear specification with (nearly) all responses. – ts01 Dec 25 '10 at 01:44
  • I tend to just use features after they exist, but this seems like a really good idea. I work at a PHP-heavy shop and have shared this link with my coworkers. – nc01 Dec 25 '10 at 04:54
  • 1
    Can people try to stick to one feature per answer, and vote on other peoples that they agree with. You can post more than one answer if you want more than one feature. I'm finding it hard to agree with some points that are point 4 in one post and point 8 in another post. – rjmunro Jan 06 '11 at 23:37
  • 3
    Does "disappearing into the void, never to be seen again" count as a feature? – Jason Lewis Jun 22 '11 at 13:43
  • 2
    Number 5 removes the only correct answer! – alternative Jun 22 '11 at 16:25
  • both these comments...hahahahah, simply brilliant. I think I cracked my rib there – Shades88 Sep 14 '12 at 09:45

63 Answers63

119

I wouldn't mind named parameters.

getData(0, 10, filter => NULL, cache => true, removeDups => true);
// instead of:
getData(0, 10, NULL, true, true);

// or how about:
img(src => 'blah.jpg', alt => 'an albino platypus', title => 'Yowza!');

Unfortunately the PHP devs shot that idea down already.

  • 1
    It's the list from 2005. Many ideas were shut down and then reborn. Actually, if a good implementation comes, there's a decent chance it'd be accepted. – StasM Dec 18 '10 at 17:21
  • 21
    It's my favorite python feature. Makes the code very self-documenting. – Benbob Dec 18 '10 at 17:21
  • Aye, this would be particularly useful, save passing an options array. – Orbling Dec 18 '10 at 17:55
  • I'd rather have a better notation for arrays or anonymous objects, although I'm not sure what would that be :) I.e. getData({ 0, 10, 'filter' => NULL }). – Michał T Dec 18 '10 at 18:29
  • I'm not sure what you find issue with. This is easy to do. make_img(array('src' => 'blah.jpg', 'alt' => 'an albino platypus', 'title' => 'Yowza!')); – Josh K Dec 18 '10 at 20:19
  • 7
    @Josh K: It's possible alright, but the 'array' call is useless garbage if you will. It only obfuscates what you are REALLY trying to do. Another option would be a shorthand syntax for arrays: make_img(['src' => 'blah.jpg', ...]); – Erik van Brakel Dec 18 '10 at 21:52
  • 2
    @Erik: That's not a bad option either, I'm saying why add this clutter to a language when you can do it already with a minor array wrapper. – Josh K Dec 18 '10 at 22:04
  • @Erik: I agree, I don't want to confuse named parameter syntax for associative array syntax. – BoltClock Dec 18 '10 at 22:57
  • 4
    @Erik: More relaxed syntax for arrays (like JavaScript's [] operator) would be an appreciated feature. – Josh K Dec 25 '10 at 20:47
  • Great idea. This would be the first step to clean up the messy syntax of the functions in the global namespace. – takeshin Dec 26 '10 at 09:28
  • 1
    I would love this feature, it's one of the really nice things I liked from Python. @josh_k: Problem with doing it that way is now you have to do all the data checking yourself. Maybe a parameter is required? Maybe alt is defined as a certain type only? Now you have to check yourself, before PHP would check for you. And any IDE's that try to do nice auto-completion stuff now don't work. – James Dec 28 '10 at 12:13
  • @JoshK Because the function signature has meaning when using named arguments. PHP (or your IDE) can then reveal any error (invalid arguments) before you run the function rather when your code runs. This is a big win for preventing bugs. It's just more semantic when it's integrated into the language. Python has this and it's certainly not a cluttered language. – Benbob Jan 11 '11 at 12:08
  • @Keyo: PHP is interpreted, not compiled. While I value (and love) a strongly typed compiled language for that very feature I think you would find it difficult to implement in PHP. I'm picking up more Django work now and I agree, named parameters are nice. I would settle for a more relaxed syntax though. – Josh K Jan 11 '11 at 14:00
  • The reasoning on that page is gold: "We don't see the real need for named parameters, as they seem to violate PHP's KISS principle." haha, what? :D – Tamás Szelei Jun 22 '11 at 13:49
93

More dereferencing:

echo something_that_returns_array()[4];

Others have mentioned named parameters, and shorter array syntax. I wouldn't mind shorter object syntax, as well.

$a1 = array(1, 2, 3, 4);
$a2 = [1, 2, 3, 4];

$b1 = (object)array('name' => 'foo');
$b2 = {'name' => 'foo'}; // or something?
  • 18
    ()[] syntax is already in trunk. Unfortunately, array shortcuts were rejected, but I hope for resurrection. – StasM Dec 18 '10 at 22:44
  • 2
    I would love this feature. Why can we have something_that_returns_object()->4, but not with arrays? – Bala Clark Dec 19 '10 at 08:22
  • @Adam: [shameless evangelism] You should check out Ruby. Has everything you mention, plus no sigils and ending semicolon. – Mladen Jablanović Dec 19 '10 at 08:49
  • 4
    Javascript like array and object notations would rock. As a front end developer that is what bothers me most in php code. – Bleep Bloop Dec 23 '10 at 00:27
  • The problem with the example ()[] syntax is that it only works if the function always returns an array with at least 5 elements in it. – DisgruntledGoat May 20 '11 at 18:41
  • 1
    @DisgruntledGoat It does, see: function something_that_returns_array() { return array( 'a', 'b', 'c', 'd', 'e' ); } – Annika Backstrom May 21 '11 at 01:55
  • 2
    @DisgruntledGoat: The problem with the ()-> syntax is, that it only works when an object is returned, to make matters worse, the object is even required have a property/method of the specified name, which, optimally, does what you hope it does, while accepting the parameters you've given it, and praying that it doesn't require any more... etc etc. – phant0m Jul 23 '11 at 23:44
  • Just in case anybody reads this: [1, 2, 3, 4] is in PHP 5.4 too. – StasM Apr 13 '12 at 19:41
72

After working with PHP for about 13 years, and heavily with JS for about 4, there are a couple things I think PHP would do well to borrow from JS:

1) shorthand notation for Arrays and Objects. I believe this may have been discussed and shot down on Internals (so I hear – I don't like to see how the sausage is made), but I really, really find that the literal notation for arrays and objects in JS is a big productivity win.

For example:

$arr     = [1,2,3,4];
$assoc   = [foo=>'bar', baz=>'boo'];
$stdobj  = {foo->'bar', baz->'boo'};

Is (IMHO) just much easier to write and cleaner than

$arr     = array(1,2,3,4); // not too bad
$assoc   = array("foo"=>'bar', baz=>'boo'); // not too bad either
$stdobj  = new stdClass; // this gets pretty rough
$stdobj->foo = 'bar';
$stdobj->baz = 'boo';

I've heard that some concern about potential confusion was raised, but really, is this any more confusing than, say, heredoc notation? At very least, making a stdClass object in PHP is verbose enough to discourage the practice, I think.

2) Being able to redefine previously-defined functions and methods would be really useful. It would particular simplify situations extending a class and instantiating the new class is either overly complex or impractical. I do think we should avoid redefinition of core/non-userspace functions and methods, though.


In addition to those two, I think PHP must transparently support unicode. This is becoming more and more of a problem for developers, and the solutions currently offered in PHP are confusing and frequently non-performant. Making all standard string functionality unicode-friendly out of the box would be a massive win for PHP programmers.

Thanks for asking!

Funkatron
  • 191
  • (2) look at runkit. (3) unicode is hard, especially since most of outside world is not unicode. We'd have to either kill performance or require people to do a lot of extra work (like Java does). That's why php6 unicode effort didn't work out. – StasM Dec 18 '10 at 23:06
  • I'm aware of Runkit, but it's just not a commonly supported extension, so you can't rely on it to be in the environment. Making some of its capabilities available in the core distro would allow then to be used of by a much wider audience, and allow public/FOSS projects to take advantage. – Funkatron Dec 18 '10 at 23:19
  • 8
    As for unicode: it may be hard, but it would be massively useful (surely developing PHP itself is hard, but it provides great benefits, yes?) Perhaps a solution would be to enable transparent unicode via an extension with the understood perf tradeoff, much like XHP? Thanks again. – Funkatron Dec 18 '10 at 23:21
  • 5
    $object = (object)array("foo"=>'bar', baz=>'boo'); – mercutio Dec 19 '10 at 09:55
  • 3
    I don't see how you can see "most of the outside world is not unicode"? Are you talking about people? Or something else? Because the vast majority of people in the world (by a huge margin) speak languages that are best represented by Unicode. – Dean Harding Dec 19 '10 at 22:15
  • 1
    Definitely unicode support. Shipping any sort of globally used app is a non-starter without it. Whether the PHP devs think engineering in decent unicode support is easy or not is beside the point. People need it, and they're hacking their way around the platform's failings to do it. Delphi did it by adding another string type and making it the default, with implicit casting, and a global switch to get the old behavior back. Why can't PHP do it the same way? – Joeri Sebrechts Dec 27 '10 at 19:40
  • No 2. Oh please no. "I do think we should avoid redefinition of core/non-userspace functions and methods, though." Is that because code could become very hard to understand? (I thought it would do this, I didn't realise someone else had redefined the function!) Well, the same applies to my code & functions. This could make code so hard to follow. But Yes on the unicode. – James Dec 28 '10 at 12:18
  • Yes, being able to just put in a json and have it work would be very helpful. – Zachary K Feb 18 '11 at 13:24
  • I don't care about redefining functions, but I'd like short-hand syntax and definitely unicode – Xananax Jun 22 '11 at 05:20
48

Things I would like, as a former long-time PHP apologist:

  1. Shorter syntax for arrays. PHP arrays are one of the awesomest features of the language because of their flexibility, but it's a drag to write some_array_method($argity, array('key' => $value));. I believe this proposal was already eviscerated on the PHP mailing list unfortunately.
  2. finally support
  3. Attributes/annotations. These allow you to add custom behavior to a method in a way that allows code reuse. For example, in an MVC framework, one could define an AuthorizeAttribute that would indicate that a controller or action method requires the user to be authorized. The framework itself would be responsible for looking for the attributes and acting on them accordingly. I believe PHPUnit already uses a sort of attribute by putting them in docblock comments, which can be read using reflection, but putting actual functionality in docblock comments is certainly a hack.
  4. Shorter lambda syntax. Instead of having to write function($x){ return $x*2;}, maybe I could write $x => return $x*2, or something. This is again something just sort of makes it a drag to use this feature. For example $results = array_filter(array(1,2,3), function($a) { return $a % 2; }): vs $results = array_filter(array(1,2,3), $a => return $a % 2 ); The former just has so much more plumbing that's basically irrelevant to the actual work you're trying to accomplish.
  5. A built-in Decimal (fixed-point math) that supported math operations through the normal operators would be kind of nice, since we don't have operator overloading.
  6. MOAR MAGIC METHODS. Magic methods are great. I could see PHP adding operator overloading via magic methods (I know this will basically never happen.) But in general, they provide really great ways to hook into the language and do cool things.
48

Make PHP truly object oriented. The slap on another global function evolution of PHP needs to end.

array_merge(array_filter(array_intersect_key($arr1, $arr2), "is_int"), $arr3);

This is hard for me to read. I have to make my own mental stack and sort of compile it myself. Basically it should read in the reverse. $dog->wakeup()->bark(); is easy to read compared to bark(wakeup($dog))

$arr1->array_intersect_key($arr2)->array_filter("is_int")->array_merge($arr3);

You've made the step towards enabling object/method support now please use it in actual core PHP functions.

Let's rename 500 functions and change parameter order for them.

Shifting this functionality to methods would enable them to be renamed using some consistently. Would it break any backwards compatibility if strings and arrays had their own methods?

Benbob
  • 1,206
  • 3
    I think array not being an object type is a big mistake in PHP. Leads to all kinds of trouble. Unfortunately, it's an evolutionary thing. You can do what you want here with extension or userspace though. Would probably fit SPL well. – StasM Dec 18 '10 at 17:24
  • 3
    The same argument applies to strings. I'm just referring to the lack of methods in general. Languages like Java, Python, C# etc all have much more readable code. I guess you are looking for features, but fixing what is IMO broken would be a better pay off. – Benbob Dec 18 '10 at 17:28
  • Funny thing — if all scalar types were objects, we would get strict typing in function calls for free since function blah(MyObject $foo); will already work, and if a String class existed, then it would be no different to function handling than MyObject. – Alan Pearce Dec 20 '10 at 11:29
  • Somebody has never understood Scheme. – erjiang Dec 21 '10 at 00:52
  • 6
    No, don't be silly. It'd be dog_wake_up($dog); bark_dog($dog); – Matchu Dec 24 '10 at 18:24
  • 2
    IMHO, any new string methods should expect and emit UTF-8, and throw exceptions if the input is not valid UTF-8. This would greatly reduce the need for a major reworking of unicode support. – rjmunro Jan 06 '11 at 23:39
  • @rjmunro The best way to fix PHP is to use python or ruby. Clearly they don't take any of the criticisms on board. – Benbob Jan 07 '11 at 01:08
  • @rjmunro Or have an "encoding" parameter, with UTF-8 default. – luiscubal Jan 18 '11 at 01:45
  • 1
    @luiscubal No. An extra parameter will mean that we can't add parameters later if we invent new things to add to the function. For example, if $string=>trim() only did whitespace (like before 4.1.0), then your system would say $string=>trim('ISO-8859-1') trimmed whitespace from ISO-8859-1 strings. If we then wanted to be able to trim stuff that wasn't whitespace, we'd be unable to add the parameter for that, unless we make people specify the encoding first. We should be encouraging people to believe that any text anywhere that is not UTF-8 is wrong. – rjmunro Apr 17 '11 at 00:00
  • +1 from me, my thoughts exactly. If PHP went fully OO, it could actually be adopted by .NET developers rather than flamed by them. – Greg Jun 22 '11 at 09:41
  • @rjmunro Or PHP could implement named parameters and it would be easy to add a named encoding parameter :-) – Andrea Jun 24 '11 at 09:30
40

A language-integrated-query-engine would be great. Sort of like what is available in .NET called LINQ. It would help sort through massive arrays of data, and standardize database access, so that fewer SQL-injection attacks succeed.

Stephen
  • 2,199
  • 2
    Anything that makes parameterized queries easier gets my vote! – Dean Harding Dec 18 '10 at 14:57
  • 1
    I think the standardized database access is actually a very important benefit of something like LINQ, because I think it makes unit testing with mocks of your database objects easier (since you're mocking PHP code instead of SQL queries.) – davidtbernal Dec 18 '10 at 19:42
  • i don't think, that something like this should get into core. it would better fit into a pecl extension – aurora Jun 03 '11 at 07:21
38

Oh. Type hinting for primitives. That would be nice.

  • 1
    Although I like PHP's KISS principle (to an extend), I strongly second that. The reason is that if you want to be really defensive, you end up with the same type checking code in each setter method. We could easily drop that if the language supported it natively. – MicE Dec 18 '10 at 22:26
  • 4
    "Type hinting" was very unfortunate name, as it's not "hinting", it's strict typing. I think primitive strict typing would be out of place in dynamic language like PHP. Coercive typing (same thing that internal functions do - try strlen(123)) may be OK. – StasM Dec 18 '10 at 22:42
  • 6
    +1 for this. Type hinting (or strict typing) in function declarations would be incredibly helpful and cut down on so much if(!is_int()) crap in EACH AND EVERY method. – Phil Sturgeon Dec 21 '10 at 11:54
  • 5
    @StasM I disagree. It is perfectly with in the scope of a dynamic language to allow the user to choose to use the language in a statically typed way. And it would allow for much better error catching. You wouldn't have to use it if you didn't want to, but personally I'm fed up of having strings passed where I wanted an int and then having to search through code to figure out where the stupid string is getting passed in. Or else, type checking everything all the time. – Daniel Bingham Dec 28 '10 at 17:15
  • @Daniel IMO "better error catching" is a myth. Since without compiling you don't have static type control, the errors in runtime will stay the errors in runtime, you will just shift them around the code. On the other side, you'll add tons of type conversion errors - like "1" and 1 and 1.0 being different, and you'd have to either introduce typed variables, returns, etc. - thus converting PHP into fully statically typed language - or do three times as many checks, as you move the check form the callee to the caller. – StasM Dec 28 '10 at 19:01
  • @Daniel note also that none of the PHP's peers - Python, Perl, Ruby - have statically typed methods. Is there a reason for that? – StasM Dec 28 '10 at 19:12
  • 2
    @StasM There is absolutely no reason you would have to introduce fully statically typed variables. Yes, you would shift the errors around in your code. That would be the whole point. The error would occur at function call time instead of inside the function -- which leaves you with no idea where the error is actually occuring. As for type conversion errors, the error would occur -- yes at run time -- at the function call. Fix the problem by converting right there to the correct type. Much better than having a string appear in a function expecting an int and not knowing from where. – Daniel Bingham Dec 28 '10 at 21:33
  • 1
    @StasM And before classes were introduced, there was no other language that had them either. Was there a reason for that? This sort of argument is the worst of red herrings when it comes to language design. The whole point of innovation is that it doesn't exist yet. – Daniel Bingham Dec 28 '10 at 21:33
34

I really wish for better unicode support out of the box. Most languages move in that direction but PHP still have strange commands littered all over.

PHP strings are just plain byte arrays. Their content is non-portable as it is dependent on the current default encoding.

The same applies to the representation built by serialize. It contains a length-prefixed byte representation of the string without actually storing any encoding information.

Most PHP (string) functions have no clue about Unicode. For a detailed list including each function’s risk level, refer to: http://www.phpwact.org/php/i18n/utf-8

http://blog.ginkel.com/2010/03/php-unicode-support-or-the-lack-thereof/

  • Unicode support proved much harder than thought. That's why php6 effort was stalled. For now, we have utf-8 and I think best way to go would be to add utf-8 support for string functions, maybe as part of intl extension. – StasM Dec 18 '10 at 22:38
  • 3
    BTW, the quote is incorrect. PHP strings are byte arrays, but their content is as portable as you make them and is not dependent on "default encoding" - it's just array of bytes, you want them in utf8, put utf8, want utf16 - put utf16. phpwact.org link seems to be dead. – StasM Dec 18 '10 at 23:31
  • 1
    I would really hope that the intl extension would be enabled by default, so people that needed UTF-8 (doesn't everyone?) didn't have to fight their hosts to get the string functions to behave like expected. – Emil Stenström Dec 19 '10 at 12:19
  • Also, thanks for the clarification on strings. I've been away from PHP for a while now, so I'm a bit rusty. I've instead fought the unicode war with Python, which has similar problems as PHP does, but solves them in Python 3. Having a swedish "ö" in your name is a mess :) – Emil Stenström Dec 19 '10 at 12:20
  • This is definitely one area I would like to see an improvement in. – Nathan Osman Dec 27 '10 at 00:27
  • This has been discussed and attempted before, but turned out to be quite cumbersome so the team stopped branch development. It required a full re-write of almost all aspects of core. – Corey Ballou Jun 10 '11 at 11:57
  • I think that PHP should assume all strings are UTF-8, and any function that expects a string (not binary) should throw an exception if the UTF-8 doesn't validate. – rjmunro Jul 03 '13 at 13:38
32

Make strings object like, with built in methods to replace the inconsistently named and parametered non-object ones. e.g.

$subject->replace($search,$replace);
$string->split($separator);
$string->trim();

etc.

Edit: one more thing: These methods should always expect and emit UTF-8, except for ones specifically intended to deal with encodings. If input is invalid UTF-8, an exception should be thrown, even if the output of the function wouldn't be affected by the encoding.

rjmunro
  • 416
  • up, that's exactly what I'm aiming to. – Kemo Dec 18 '10 at 22:44
  • 1
    subject->verb(object), makes parameter order easier to remember. – Ming-Tang Dec 30 '10 at 04:09
  • +1 I played around with creating my own string class to do this kind of thing, it makes coding so much easier and you never forget the parameter ordering. – DisgruntledGoat Jan 06 '11 at 17:22
  • 2
    So what would is_object($string) return? This would either break backwards compatibility big time, or result in the introduction of really unintuitive almost-but-not-quite-objects. – Tgr Apr 16 '11 at 16:37
  • @Tgr: is_object() should be deprecated - There should be no such thing as "not an object". In the short term, it would have to be a property you can turn off on any object, and the default string constructors would turn it off. – rjmunro Apr 16 '11 at 23:50
24

1) I would love for newly instantiated objects to return "$this" so I can method chain, $user = new User('john')->setLastName('Doe')->save();

2) If you've ever used ruby, and most recently node, they have a great interactive shell (IRB). I would love for PHP to have one that was actually useful.

3) Traits/Mixins, but I hear those are on the way.

4) I want to second the short array $myArray = ['my', 'array'];

5) Consistent naming/order (i.e. needle haystack)

  • I hate having to create a create() method that does nothing special just to work around #1! – Alan Pearce Dec 20 '10 at 11:30
  • I do the same but, using late static binding and an object superclass, that way every class that extends my superclass has the method, e.g.: SomceClass extends SuperObject{}; SomeClass::create()->somemethod(); – dukeofgaming Dec 21 '10 at 02:23
  • Have a look at https://github.com/philsturgeon/php-ps It's only a start but with some help it could be pretty useful. – Phil Sturgeon Dec 21 '10 at 11:52
  • 1
    There's also a PEAR package that offers an interactive shell for coding out quick experiments in PHP - available at http://pear.php.net/package/PHP_Shell – kguest Dec 25 '10 at 22:55
  • (new Foo())->bar() is part of 5.4. 3) and 4) are too. – StasM Apr 13 '12 at 19:44
20

1) please get rid of includes(). References to other files should be references, and not actually place the contents of one source code file into another. Far too many PHP programmers use includes() as a type of function call rather than a means to reference a library. This leads to all sorts of ambiguity in variable state and unstable code. Replace this with a Perl-like 'use' command.

2) please provide an out of the box method of compiling a PHP application into a single distributable bytecode file or executable. This will greatly enhance the appeal of PHP as a commercial development language. This should be a basic component of the language. Dont worry about the html files used for an application's GUI because...

3) please get rid of the ability to embed PHP tags into HTML. Or at least provide a 'no embed' mode. This is an absolute mess and encourages bad design by mixing application logic and presentation together. Developers should be using templates for display and not slapping PHP files together and hoping for the best.

Signed,

GrandmasterB

ps: dont listen to what others here say, I've been nice all year

GrandmasterB
  • 39,224
  • 2 is kind of hard. Look at hiphop (https://github.com/facebook/hiphop-php) though - it shows some promise. – StasM Dec 17 '10 at 21:58
  • 37
    1). Includes are great. Everything has includes. 2). This is good. 3) Templating is PHP's strongest feature. Forcing you to use some other templating bullshit would be a very bad move. – Josh K Dec 17 '10 at 22:46
  • @Josh K: I agree, why bother moving to another form of templating? I think HTML-based code should be limited to loop-constructors, and quick echoes, using the ternary-if rather than any code where necessary. If people choose to use more complex code inline, that is there own lookout. Otherwise you end up with design elements in the code, which is much worse. – Orbling Dec 18 '10 at 14:09
  • 8
    I like (1) and (2), but (3) seems like a retrograde step. PHP gives you the templating power, it's up to you whether you use it wisely or not. – geekbrit Dec 18 '10 at 19:23
  • 11
    3 makes no sense - embedding tags is necessary for any V in MVC frameworks. – Alex Dec 18 '10 at 23:05
  • Bundling a whole application is not as easy as you think and I think in many cases would be impossible to do automatically without sweeping changes to how PHP works. – Michał T Dec 20 '10 at 15:09
  • 9
    I read this answer as "Dear Santa, please make PHP not be PHP." – Stephen Dec 21 '10 at 22:50
  • (2) are you asking for something more than phar or an extension to phar? http://php.net/manual/en/book.phar.php – Wil Moore III Jan 03 '11 at 07:40
  • 1
    3 is right out, as PHP is a templating language. – Andrew Jan 28 '11 at 14:50
  • 1
    Umm, for naysayer's on 3... I agree that it necessary for the language, however - It would be nice if I could have pure php script files. Such as when I'm writing a class file or something, I don't want to risk sending content before the headers are sent. – tylermac Jun 24 '11 at 19:19
18

An ini directive to E_ERROR on undefined constants, rather than assume it's a string with E_NOTICE.

14

Normalize the global namespace with a well thought-out naming convention that makes sense to new-comers!

To quote our beloved Jeff Atwood: PHP sucks but it doesn't matter!

  • 1
    I agree in principle, but have no idea how to do it in practice :) – StasM Dec 18 '10 at 22:47
  • 3
    @StasM: I imagine the first step would be to make the new versions of libraries namespaced and allow programmers (via ini settings) to disable the currently global libraries. I would think a compatibility pack would be in order for older versions, but shouldn't be very difficult to write. – Michał T Dec 20 '10 at 15:15
13

Strings should be objects

Kemo
  • 111
13

1) Shorter array/object syntax, a la JavaScript (as previously mentioned)

2) Allow const variables to allow the result of a calculation like define() does.

3) Chaining directly from the constructor: new User()->name('Ryan');

4) Array dereferencing: something_that_returns_array()[4];

5) Expanded SPL support. SPL does a decent job of reimagining string and array functions (among other things) as objects. Expanding SPL could solve a lot of gripes about the language being so janky.

6) Using ArrayObject() should be as transparent as using array(). You should be able to do things like array_filter($array_object_instance) without doing array_filter($array_object_instance->getArrayCopy()). Even better, of course, would be $array_object_instance->filter().

7) Full-on Unicode would be nice.

8) Stop doing weird automatic type conversions. For example, you should not be able to echo a SimpleXMLElement object without first explicitly typecasting it as a string. Or at least, throw something when it happens (e.g., in strict mode, or whatever mode error_reporting(-1) is).

9) Support for either multiple threads, or some sort of evented/asynchronous callbacks. This matters most when trying to upload large files via cURL. Instead of old-skool threads, something like Apple's Grand Central Dispatch would be nice. Or even something JavaScript-like where you can make async requests and define callbacks.

10) Consistent naming/order (i.e. needle haystack) would be nice, but I think this could be better solved with SPL.

11) An officially supported interactive PHP shell, like IRB. Facebook has one called phpsh that was written in Python, but it lacks the polish I would like to see.

12) For the Reflection API, add support for (a) docblock comments on constants (global & class), and (b) support for parsing PHPDoc-like comments into a sensible data structure. There's a PECL package called "docblock" that attempts to do this, but it doesn't appear that the author got very far.

EDIT: 13) I would also love to see the ability to use ! and ? in function names -- like Ruby can.

  • i agree, that arrayobject should be supported for the array_* functions. but what would be the expected result for something like "array_merge" if you consider subclasses of arrayobject. would you only be allowed to merge instances of the same class and what would array_merge return? a php array or an instance of arrayobject (respectively it's subclass)? – aurora Jun 03 '11 at 07:24
  • I would argue that since the data internally is an array, and ArrayObject wraps that with functionality, then even subclasses of ArrayObject would still be working with arrays internally. I would expect to be able to merge another standard array or ArrayObject (or subclass). As far as what it would return, I would argue that it should also return a new ArrayObject, but follow the precedent that simplexml_load_string() set where you can specify the name of the class that the result should be an instance of. – Ryan Parman Jun 10 '11 at 21:27
12

I would like to see a legit method of creating/defining CONSTANT arrays. There are a few hackish ways to simulate this kind of functionality but it would be nice if it was just a straight up feature of PHP. It would be nice if you could create an array in a way that is similar to Java's "final" declaration.

I created a login system that is very quick to setup. All you have to do is change the contents of an array in a text file to specify the fields you want for user information. Using a swath of for loops it handles everything from form generation and input sensitization, to database calls but it is all dependent on this original array.

The file with the array is locked down with permissions but once the array is moving around in the ether it is mutable. Although I feel the system is pretty secure I don't like leaving anything to chance. A method to finalize arrays would be nice for a situation like this.

New Idea!!

Ohhh, I thought of something else I would really really like in php. I would like some kind of system to control php file operations and directory operations similar to the way .htaccess works.

The .phpaccess file should trigger some kind same domain/same origin policy.

For example, If I were hosting many sites with virtual hosts I could have a .phpaccess file in a directory that would tell php to check the orgin of any scripts being executed which are trying to operate on my protected directory. If the script did not come from that directory or its sub-directories then the file operations / or socket operations will be denied.

I think a system like this would make virtual hosting a much safer environment. If you could place one of these at the top of each virtual host it would lessen the chance of someone finding a way to sneak in from a neighboring virtual host.

Also if it would be good to have a method of securing it in the inverse of this manner. ie, restricting the reach of scripts in a single directory to that directory.

Its the yin and the yang ya know!

Dave B.
  • 81
  • +1 for final. To clarify: final means that the value of a variable can be set at runtime (unlike constants, which have to be constant expressions), but can only be set once. See also C#'s readonly. – davidtbernal Dec 18 '10 at 19:45
  • 1
    there's a proposal for getters/setters for trunk that would supercede readonly, etc. Immutable arrays though probably would be hard to do. – StasM Dec 18 '10 at 22:45
  • Re phpaccess, PHP already has a "safe mode" that does what you describe. – DisgruntledGoat Jan 06 '11 at 17:24
12

1) Array comprehension in the style of Python list comprehension:

$newlist = array($x->something for $x in $oldlist);

//with short array syntax:
$newlist = [$x->something for $x in $oldlist];

2) Short array syntax

$newlist = [1,2,3,4,...];

3) Make empty() not consider the string '0' as true

sfrench
  • 131
  • 2
    I think for (1) something cooked from iterator & closure would be better. – StasM Dec 18 '10 at 23:02
  • +1 IMHO, this should be included in all languages, as well as iterators. They're just way to useful not to have. – Evan Plaice Jan 12 '11 at 15:30
  • empty() is the logical opposite of if ($x), so it makes sense that empty('0') is true, because if ('0') is false. The only difference is, empty() doesn't throw a notice if the variable isn't set. – Andrew Jan 28 '11 at 14:55
11

My two biggest wishes as a hardcore PHP programmer:

  1. Support finally. It's a big mess to fictionally get around this through flags or similar means.
  2. I would LOVE to see support on C#'s syntax for getters and setters. When you have lots of getters and setters a simple syntax such as C#'s is a great performance booster instead of doing it the Java way and writing getter and setter methods. Magic methods are awesome in cases where you want to create members dynamically (for instance, if you want to give a template renderer some variables to use), but are no good for normal properties on which you would like the IDE to autocomplete, know their types, and so on. this would help make code smaller and still as readable and easy to use.
Johnco
  • 121
  • 1
  • unfortunately, it's hard to do, but definitely a good todo item 2. http://wiki.php.net/rfc/propertygetsetsyntax
  • – StasM Dec 18 '10 at 22:59
  • @StasM: how about doing it via anotations? Something along the lines of:
    /** @get getFoo; @set setFoo; */ private $foo;
    – Michał T Dec 20 '10 at 16:16