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
<[email protected]>wrote:
> Hi,
>
> On Mon, 2014-02-17 at 12:08 -0500, [email protected] wrote:
>
> > 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: [email protected]
GTalk: guilhermeblanco
Toronto - ON/Canada