Earlier quoted context omitted.
But, less than question mark and a space are not a valid XML combination. XML processing instructions cannot begin with a space. Likewise, PHP cannot run commands into the short tags, like . So, there really is no collision, it's just grandstanding.
I wonder if the XML PI spec says anything about <?= Can you have a PI start with = ? If not, the echo short tag should stay for certain.
PHP Hacking aka trying to push PHP internals forwards
21–30 of 62 posts
Re: PHP Hacking aka trying to push PHP internals forwards
#22Good to see. It's about time PHP got forked even if experimentally. It seems to me that you could fix a lot of the problems with PHP by breaking backwards compatibility.
Many of the problems and annoyances with PHP could be fixed while keeping backwards compatibility. Just a short list I can think of now: - Short array syntax. Completely optional but would clean up the language quite a bit. This has been proposed several times and shot down each for no real good reason. - Promote complex primitives into objects. With the proper interfaces it wouldn't break any old code. Once this is…
Well to be honest if you deprecate the str* and array* functions you are pretty much breaking backwards compatibility.
I'm not saying it wouldn't be a good thing but those functions are one of the defining features of PHP imho
Re: PHP Hacking aka trying to push PHP internals forwards
#23Earlier quoted context omitted.
Many of the problems and annoyances with PHP could be fixed while keeping backwards compatibility. Just a short list I can think of now: - Short array syntax. Completely optional but would clean up the language quite a bit. This has been proposed several times and shot down each for no real good reason. - Promote complex primitives into objects. With the proper interfaces it wouldn't break any old code. Once this is…
Well to be honest if you deprecate the str* and array* functions you are pretty much breaking backwards compatibility. I'm not saying it wouldn't be a good thing but those functions are one of the defining features of PHP imho
Deprecation is not the same thing as removal.
Re: PHP Hacking aka trying to push PHP internals forwards
#24Good to see. It's about time PHP got forked even if experimentally. It seems to me that you could fix a lot of the problems with PHP by breaking backwards compatibility.
Many of the problems and annoyances with PHP could be fixed while keeping backwards compatibility. Just a short list I can think of now: - Short array syntax. Completely optional but would clean up the language quite a bit. This has been proposed several times and shot down each for no real good reason. - Promote complex primitives into objects. With the proper interfaces it wouldn't break any old code. Once this is…
PHP already provides a mechanism to replace errors with exceptions (set_error_handler() and the ErrorException exception type). I do this on all my projects.
Re: PHP Hacking aka trying to push PHP internals forwards
#25I wonder if it wouldn't have been better to import the PHP source-tree first, then apply each patch one at a time/in a batch. That way applying these patches at a later date would have been easier.
Re: PHP Hacking aka trying to push PHP internals forwards
#26Earlier quoted context omitted.
Many of the problems and annoyances with PHP could be fixed while keeping backwards compatibility. Just a short list I can think of now: - Short array syntax. Completely optional but would clean up the language quite a bit. This has been proposed several times and shot down each for no real good reason. - Promote complex primitives into objects. With the proper interfaces it wouldn't break any old code. Once this is…
PHP already provides a mechanism to replace errors with exceptions (set_error_handler() and the ErrorException exception type). I do this on all my projects.
I'm aware of that method. It's not an ideal approach IMO.
Specific errors should throw specific exceptions. That way I can handle the ones I know how to handle and let the others bubble up and either completely break the app to be logged and fixed later or get handled correctly somewhere else. With ErrorException, you have to look at the contents of the error message to see if it's an error you can handle or need to rethrow.
Re: PHP Hacking aka trying to push PHP internals forwards
#27Earlier quoted context omitted.
PHP already provides a mechanism to replace errors with exceptions (set_error_handler() and the ErrorException exception type). I do this on all my projects.
I'm aware of that method. It's not an ideal approach IMO. Specific errors should throw specific exceptions. That way I can handle the ones I know how to handle and let the others bubble up and either completely break the app to be logged and fixed later or get handled correctly somewhere else. With ErrorException, you have to look at the contents of the error message to see if it's an error you can handle or need to…
If something in PHP triggers an error, there is very little to recover from. It's either a developer error or an unrecoverable problem (a file expected to exist was not found, network is down, etc). In any of my projects, I've never needed to recover from PHP ErrorException.
Re: PHP Hacking aka trying to push PHP internals forwards
#28I'm a long-time PHP user (since 1998) but I never really peered inside the discussions of the internals of PHP. Now that I'm more connected to others in the PHP world, what you see inside the mailing list for PHP internals is what I would label as obstructionism and an attitude that seems to imply that if you cannot code the requested changes yourself, don't even bother asking. Lead, follow, or get out of the way are…
> attitude that seems to imply that if you cannot code the requested changes yourself, don't even bother asking.
I think that's fair actually. The internals list is not for wish-lists; if it was it would be flooded and no useful work could be done there. The problem is that there are coded patches for some of these features (like short array syntax) but they're still not being included.
Re: PHP Hacking aka trying to push PHP internals forwards
#29Boo, deleted short tags. Why do people hate short tags again? I can't remember because <? is not valid XML so there shouldn't be any problems with mixing php and xml... hmm... I wonder ....
Personally, I'm a fan of exactly one way to do one thing.
Re: PHP Hacking aka trying to push PHP internals forwards
#30Does anyone know if there are any benchmarks about this?