my take on PHP 6, part 2 View as Markdown

Pierre Joye wrote:

Warnings? Both?), make errors not so damn expensive and fix @ to be much

more lean-and-mean than it is now.

Kill it could be an option too. I see the need of @ as a design failure.

Is ICU an indication of how this should be handled as well. Being able to
switch exceptions off in intl demonstrates that they may not be necessary.

a library which is built around supporting exceptions can work, but
currently we have a bunch of code (both in the core and in userland), which
doesn't support that.
errors can support the execution of the execution, which means allowing to
have return values, or emiting multiple errors from the same call, with
exceptions you can't do that, as the execution will jump to the next catch
block (or to the global exception handler).
I don't think I have seen any proposal so far which would solve these
issues, yet people still talking about like replacing the current error
handling infrastructure with exceptions would be a viable alternative.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

- Native ctype support (no, not the current supported one. Look for its
support in Python)

Not an engine feature. feel free to provide an extension API, eventually
might be bundled. (and enabled by default / force)

the ctype equivilent in php would be a more robust and accessible FFI

http://pecl.php.net/package/ffi

I think the goal here would be to expose lib's and be able to
dynamically-ish (program via php) an interface to a library without
having to write an extension.

- With better opcache and ctype, also add better `dl()`, completely
removing the need to have so many extensions in core

Better dl is not trivial due to operating system restrictions. With
major refactoring we might improve this a bit, but things which come to
mind cause major breakage in APIs for quite little effect ... I thought
a while about this in regards to composer etc.

I think the idea here is to be able to have per-project extension
dependencies, as you said, with composer. This would be ideal in a way
for the ecosystem to vet extensions before inclusion in core. But
currently, unless you own the system, extensions are extremely
inaccessible to gain any real momentum.

-ralph

Hi Johannes,

Answers inline, but before anything, thanks a lot for spending time in at
least willing to read/answer these suggestions.

On Mon, Feb 17, 2014 at 1:18 PM, Johannes Schlüter
johannes@schlueters.dewrote:

Hi,

My suggestion back in 2011 was to rewrite Zend Engine to accommodate a
few
things that people are considering as must-haves nowadays. Based on
history, each ZE is rewritten after every 5 years (1996 - 2001 for ZE1,
2001 - 2005 for ZE2), which hints we may be in a need to reevaluate
current
code and plan support for next 5 years.

ZE2 is not a rewrite. PHP 5.1 or 5.2, not sure, had a completely new
executor,aside from that there mostly were extensions.

A couple of things to motivate:

• Native Unicode support

Complicated one, see other threads.

Completely agree. Discussed with Pierre some time ago about possibly fixing
these by using C++ in core and reusing libs such as ICU easily.

• Make opcode cache native

What does that mean? What's the expected benefit over opcache?

It is opcache, which for me is opcode cache. Maybe I use a wrong
terminology, but Pierre already covered what I was meaning on his ideas
page.

• Better garbage collector

In what sense?

Dealing with resources seems to not free all resources, such as PDO
ResultSets, Filesystem, etc.
I never really bothered to track this down, but all issues I've experienced
are related to resources.

Another point I wanted to see covered was the ability to have Strong and
Weak references natively. I know Etienne created the WeakRef PECL extension
~2y ago, but I've never seen any sign of possible integration into core and
re-usability for certain parts/functions that could.

• Add basic support for interceptors (preConstruct, postDestroy,
  aroundInvoke)

This can be added by extensions if needed.

Completely agree, but that would be extremely hard to use without a clean
way of defining class metadata.

• Operator overloading, allowing things like Comparable interface

No. Please not.

Why not?
Right now we already support some, such as $arrGrouped = $array1 + $array2;
which already provides a nice and clean understanding of code flow. I do
see a variety of usages to classes that could benefit from these.

• Attempt to simplify language operators/keywords/symbols

A part of PHP's design is to have keywords which can be googled for,
short operators, notations make it harder if one stumbles over unknown
constructs. Any precise examples?

I mentioned that before here, but I wrote down an EBNF grammar of PHP and
it is damn scary.
Similarly, other languages are fighting to reduce huge parsing time needed
by simplifying their grammar. One good example was Java EE6 which had ~200
grammar rules and now they're down to ~50. That hugely simplifies the
language and parsing/compiling time.

• Native ctype support (no, not the current supported one. Look for
  its
  support in Python)

Not an engine feature. feel free to provide an extension API, eventually
might be bundled. (and enabled by default / force)

Hm... interesting point. I haven't thought from this perspective, it may be
doable.
Still, I don't see this working smoothly without a good organization of now
root level functions into encapsulated namespaces/classes/functions. I also
would require some work around exceptions too.
So far the only attempt close to this I saw was:
http://pecl.php.net/package/ffi

• With better opcache and ctype, also add better dl(), completely
  removing the need to have so many extensions in core

Better dl is not trivial due to operating system restrictions. With
major refactoring we might improve this a bit, but things which come to
mind cause major breakage in APIs for quite little effect ... I thought
a while about this in regards to composer etc.

I'd argue we barely need dl() if we can make ctype always enable then.

• Remove "global" support

Why?

We're trying to get rid of bad old habits, like register_globals.
I'd include this in the list.

• Errors to exceptions

Complicated one, not all errors we have can a) be recovered and b) are
actual errors. Needs a good concept (see also other thread)

a) UnrecoverableException would fix that
b) FatalErrorException

These ones could be uncatchable and done.
I'm probably not the only one in here trying to push this forward. =)

• Consistent exception messages

Feel free to go through it and propose something, that's quite abstract.

I can try, for sure. But one thing that keeps needling my head when I
mention this is always BC compatibility.

• Scalar type hinting
• Named Parameters
• Annotations

See other threads.

Ya, ya, I know... probably since 2010 =)

• Default class resolution/loading (aka. Native PSR-0 support)

Again nothing related to the engine, if that is implemented in an
internal function for spl or such it might be added. Shouldn't be too
complex (except that user-space implementations are simpler to debug for
users if something goes wrong)

You missed slow in here, that's the actual point of coding internally.
I'd also note that you're completely right and it should be part of SPL,
for example.

• Remove error suppression (@ operator)

Unless error handling is revamped this is needed.

If we address this, my first vote would be to use @ for annotations as part
of other thread's discussion.

• C# style mutators and accessors

See RFC.

Saw it... afaik implementation was not ideal and that was exactly why it
was a tough vote.
Maybe someone with better internals understanding helping it would get
better backing?

• Comparable interface

See other thread.

• Collection, Map, Set, List, Bag

collection is a generic term, not sure what you mean. A PHP array is a
map. We have lists in SPL. A bag (multiset/multimap) can be emulated in
a nested array ... if there is need SPL could be extended.

Collection is a generic term, agreed. you should read it as an interface
here.
Classes should then tie in as long as it respects the interface.
The main point of working on this is exactly to address native support from
part of functions such as array_*.

• Namespace visibility
• Namespace Variables
• Namespace Reflection API

for the later we'd indeed have to refactor the engine in a way to have
more overhead from namespaces. This might also be needed in casethe
others are requested ... might need details.

That is a tough one.
ReflectionAPI: Right now we store class name grouping the namespaces as
string. There's no way, for example to retrieve loaded classes inside of
same namespace. It also have no understanding about "use"s inside of a
namespace. I know this is not available after it gets compiled, but
there're so many headaches (have a look at AnnotationsParser inside of
Doctrine) to get this taken into consideration.
Variables: Private/protected variables and methods/functions... I do see a
lot of work needed around here. We could have a private function inside of
a namespace that could help dealing with an specific operation internally
and not being exposed to everyone.
Visibility: We could, for example, create private or protected classes for
a strategy and have only one public API to execute an operation instead of
"free and open for all".

• Drop optional property/method visibility support (make them
  required)

Why?

Again, remove old PHP bad habits.

• Polymorphism (aka. method overloading)

Hard to do in a dynamic language in an efficient way. will slow down
each and every function call unless somebody has a good idea. Till then
we prefer extra cost for the implementor in the few times this is
needed.

Because PHP is loosely typed, yes, it would require to traverse/check which
method to call.
Some compilers I wrote in the past century did a trick to resolve at
runtime creating a delegator during compilation.
To simplify resolution, I used a hash table based on argument types to find
the right method.

• Virtual methods

what should this be in the context of PHP? From a C++ sense all PHP
methods are virtual.

That is exactly the point. Everything can be overwritten.
There's no way to enforce a public method that it can't be overloaded by a
subclass.

• pecl_http into core (considering better dl() item isn't accepted)

might be interesting.

• Previous item would lead to complete removal of superglobals

Why that? To break every single PHP script out there?

Again, let's get rid of bad habits.

• Normalize overall current/future design for the language (why
  __toString, __wakeup, __sleep vs. Jsonable or Serializable
  interfaces?)

any proposal keeping a viable BC way?

This is not an actual clear decision.
Language is far from being consistent, and without agreeing on a single
resolution to a problem leads to more and more confusion. Why is there a
__toString instead of a Stringable? Why is this then valid for Jsonable and
not to __toJson()? Or __clone instead of Cloneable?
That's a resolution that needs to be achieved and agreed by everybody.

• Primitive types (enhance SplInt et al. and make them native, with
  actual <type>_* required methods and discard nice to have ones)
• Add valuable to these primitive types (oh, and make the default
  parameter ordering. Not everyone would love to keep using named
  parameters
  over and over)
• Make native functions support Spl* instances (ie.: substr(new
  SplString('foobar'), 0, 3)) as a beginning to remove overall functions
  support
• "Strict" variable types (relies on previous 2: type hinting, type
  inference, type casting, return types. Quotes were added because they
  would
  be inferred, not declared. That would force assignments to validate
  types,
  such as $a =1; $a=false; would throw an exception because you're
  changing
  variable type)

See old discussions on type hints etc.

Ya, ya... I know.

• Remove functions from global namespace

Why?

To reduce overhead if you don't need.
Let's assume I have a file that only deals with strings. Why do I need all
array functions in the function hash table if I don't need them?
By organizing them into proper namespaces and also supporting some concept
I mentioned earlier like ctypes, we could significantly reduce memory
footprint.

• Threads support (no, don't tell me about pthreads extension)

for what purpose? We should imo rather focus on async operations. Doing
complex operations in parallel on a loaded web frontend doesn't seem
right, rather send tasks to backend services. Threading also adds quite
some complexity hurting single threaded scripts.

CLI scripts. Not everything done in PHP is web frontend.
I do agree we should also invest time in async support, but threads are not
irrelevant completely.

• Shorthand functions declaration somehow

for what purpose?

Why do I need to write function if its declaration is completely different
from properties?
Why keep function when var is not required?

• Get rid of aliased functions

why?

Again, bad habits.

• Basically apply Poka-Yoke principle to the language. There should be
  only one way of doing a given action

This is a great goal. Not trivial if one wants to allow evolution.

Please mind: Compatibility is a feature. Not only for past users but
also helps to ensure new users that their investment won't be lost on
the next version. There are tons of legacy code and tons of lines being
created every second which will be legacy a second later. We can break
things where needed, but breaking just to be "cleaner" causes lots of
pain.

Piling up tons of compatibility since PHP 4 only makes things harder and
harder to evolve.
Sometimes we need to break BC. One step back, 100 forward.
I agree that there're tons of legacy code. I work on massive ones too dated
over 10yrs. This doesn't mean language can't move forward because of them.

Of course BC breaks should be carefully planned. I think PHP6 is a good
point in PHP's lifetime to group all BC breakages ever considered and done
in a single shot.

johannes

--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada