Hi,
picking just a few topics out of the list:
(not that I agree with the others, but they'd need more detailed
proposals before one can properly argue)
On Mon, 2014-02-17 at 16:30 -0500, [email protected] wrote:
> > > - 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.
Even though we add more and more "type hints" we are still a dynamically
typed language, operator overloading brings little syntactic sugar for
loss of clarity.
btw. I'm probably the one who implemented operator overloading first in
PHP:
http://devzone.zend.com/299/zend-weekly-summaries-issue-222/#Heading2
Sarah has an (probably outdated) extension. pecl.php.net/operator
> > > - Remove "global" support
> >
> > Why?
> >
>
> We're trying to get rid of bad old habits, like register_globals.
> I'd include this in the list.
register_globals easily caused security issues which are hard to find,
"global" might generate "bad quality code" but is easy to find.
And, believe it or not, there are many instances where PHP is actually
used for quite short scripts. There it can be neat. I see little reason
to remove it for purism.
>
> >
> > > - 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. =)
There is another thread on error handling and I'd like to get things
cleared but what'd I'd i.e. like is some more logging style error
reporting,there are cases where execution can continue flawlessly but
the user should be noted, right now the only tool we have is E_NOTICE.
Any exception is too much.
> > > - 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.
Is the performance issue truly in code execution, not in IO operations
while searching the file? (I never benchmarked it)
> > > - 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.
We can't drop an operator and immediately use it for something else this
will freak out all tools and users. We can deprecate it over sometime
then let people forget about it and then reintroduce with new usage,
this takes a few years, though.
And still the requirement is to replace full error handling first. With
current error mechanisms there is no way to open an external resource
and manually handle the error.
> > > - 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_*.
This an certainly be improved, not that arbitrary conatainers could ever
be used with any array funtion ... not all allow all kinds of access and
cases where new containers are created (anything creating subsets etc.)
are tough to do truly in a generic way. Even C++ which isone of the most
advanced languages forgeneric programming can't do that for alot of STL
containers and operation
> > > - 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".
All possible, like always: needs a good proposal, implementation and
evaluation of costs vs benefit. Storing more meta information in memory
increases memory usage, reduces available memory per PHP process, uses
more time to parse and cleanup etc.
I' open for ideas.
> > > - Drop optional property/method visibility support (make them
> > required)
> >
> > Why?
> >
>
> Again, remove old PHP bad habits.
See comment on global above.
> >
> > > - 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.
Mind that function calls in PHP are already quite slow (and as they are
a key operation they always will be too slow till we have full inlining
+jit :-) ) each thing we add there, each branch we add, each time the
CPUs branch predictor goes wrong sums up to notable effects in that
area.
> > > - 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.
We have final.
> > > - 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.
See comment on global
> > > - 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.
>
And that starts with a good proposal ;)
> > > - 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.
I don't see how multiple tables and a more complex lookup saves
something maybe I don#t understand something without proper RFC :-)
> > > - 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.
Issue with allowing thread support is that everything has to be aware of
the existence. We punish everybody for a small benefit in few cases? PHP
isn't the only language in the world. PHP's purpose is "solving the web
problem".
> > > - Shorthand functions declaration somehow
> >
> > for what purpose?
> >
>
> Why do I need to write function if its declaration is completely different
> from properties?
This was discussed on my proposal before
https://wiki.php.net/rfc/optional-t-function
Conclusion was that many people love doing grep function. As said in
my initial mail in this thread: PHP is designed to have googleable
keywords.
> Why keep function when var is not required?
Variable declarations don't tell anything in PHP, you can leave them out
completely. Function declarations have to be looked up to understand
things. And no, "use an IDE" is not an answer - 'git grep' is nice to
search through a projects history, and when hunting for bugs in
customer's code I don't want to fire up an IDE when only havin rmeote
access.
> > > - Get rid of aliased functions
> >
> > why?
> >
>
> Again, bad habits.
see above. ;-)
> 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.
I agree that we need to break from time to time. But see the PHP 4 to
PHP 5 adoption where the only notable break was by-refvs. by-value
behavior of objects. It took years till PHP 5 had adoption. (and no, I
won't mention Python 3 or Perl 6 "success" ;) )
Successful evolution has to come with a clear purpose and is along term
process, see i.e. register_globals which took from 4.2 in 2002 were
super globals were introduced till 5.4 2012 where register_globals was
finally removed. 10 years.
PHP has a *massive* install base and most systems receive only minimal
maintenance. In many places the original developers left and only some
operations person is keeping it up ...
johannes