I know that many people talked about this over and over.
Why it’s not possible to change the old PHP API ?
The answer is always because it will make HUGE BC breaks
I’ve seen this wonderful idea about scalar objects authored by nikic
github https://github.com/nikic/scalar_objects.
This will become even more possible when PHP 7 is introduced because of
scalar types and many great features making the idea more reliable.
This makes an opportunity to replace the old API with object oriented one
preventing any kind of BC break.
But instead of using this as an extension because of some limitations like
“string”->startsWith(‘s’); the API should be bundled with the engine (not
written in PHP).
This will make the opportunity to also remove any inconsistencies in the
API behavior as well.
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.
But it’s actually really important for the future of the language may be
not so much for the existing developers (I disagree it’s). but this will
also encourage new comers to use PHP.
I’ve seen many articles encouraging new comers to learn languages like
Python or Ruby, and highly discourage them from using PHP. Also many new
projects are using languages different than PHP. (don’t tell me you haven’t
seen this)
This will be an issue the number of language users will drop significantly
over the years causing the death of the language.
I know that this is not an easy task. But this is a wonderful opportunity
to do this without BC breaks. I’m not suggesting that this should be for
PHP 7.0 because it will take a lot of work may be for any release in PHP
7.*
PHP internals around 40 people ? not really sure but I know you are very
busy with fixing bugs and you have a lot of work already if you think this
is a huge task it can be assigned to a good group of people similar to how
the amazing PHP Framework Interop Group has accomplished,
for Designing the new Object Oriented API. PHP internals will vote on the
design and implement it.
The old API should be deprecated in PHP 8.0 and removed completely in PHP
9.0 (finally)
I hope that you take this seriously and tell me if there are any
limitations that prevents this from happening.
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.
As you guessed, I don't think this is so important that we should
create a new "fake" object syntax for scalar. That's shooting a mouse
with an elephant gun.
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.As you guessed, I don't think this is so important that we should
create a new "fake" object syntax for scalar. That's shooting a mouse
with an elephant gun.
I strongly disagree here. Plenty of discussions prove both the needs and
the users willing to have such things.
However it is too late for 7.0 ;)
2015-03-21 8:25 GMT+01:00 Pierre Joye pierre.php@gmail.com:
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.As you guessed, I don't think this is so important that we should
create a new "fake" object syntax for scalar. That's shooting a mouse
with an elephant gun.
I don't think so. I like the idea and I think it's the best way to clean up
the API.
I strongly disagree here. Plenty of discussions prove both the needs and
the users willing to have such things.However it is too late for 7.0 ;)
That's not a feature that has to go into a major. It can also be introduced
into a minor.
Regards, Niklas
This shouldn't be for PHP 7.0 ofcourse it's too late. it takes a lot of
work and we don't want to get it wrong the second time :)
but in any release before PHP 8
I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.As you guessed, I don't think this is so important that we should
create a new "fake" object syntax for scalar. That's shooting a mouse
with an elephant gun.I strongly disagree here. Plenty of discussions prove both the needs and
the users willing to have such things.However it is too late for 7.0 ;)
How you don't think this is so important ? i stated this because it's so
predictable that someone will say it. Firstly why it's "fake" ? i prefer
"elegant" maybe not the PERFECT solution ? i suggest that you compare the
two choices. and what would you chose if you're a new comer.
Secondly this is extremely important to the future of the language not
only for the existing developers (if you read the email carefully i stated
why)
The old API should be deprecated in PHP 8.0 and removed completely in PHP
9.0 (finally)
WHY?
You don't HAVE to use the current API and wiping out all of the legacy
code does not seem like a 'gain'. The two can co exist.
I hope that you take this seriously and tell me if there are any
limitations that prevents this from happening.
I am currently working through a review of options to add one of those
pop-up chat functions to my framework. There are several designs
available, the majority of which as usual are charged for services, but
once one culls those from the search results one gets back to a few
where the code is ACTUALLY available open source. The problem however is
that many of these libraries are now being written to 'modern standards'
and this results in their being LESS reusable since the coding style
makes them incompatible even with one another. I have managed to find
ONE option which looks like it may be portable enough to convert to an
installable package to work with the rest of my framework. Just have to
convert every file from a single line of code back to something with a
real layout so I can use it. A 120000 character long line works with
PHP, but is just as unreadable as some of the new coding styles!
YES some old code needs culling ... but equally there is just as much
bad new code. Both have their place. Mind you in 10 years time I'll
probably be dead and some one else will have to re-write the entire code
base :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
De : Nathan wesley [mailto:nathan.o.wesley@gmail.com]
The old API should be deprecated in PHP 8.0 and removed completely in PHP
9.0 (finally)
That's totally unrealistic. The old API will remain forever (well, we'll examine the case again in 20 years...).
I had planned to propose something for 7.0 but I didn't have enough time.
I hope that you take this seriously and tell me if there are any
limitations that prevents this from happening.
I think that, while attractive, using the same syntax for object methods and scalar 'pseudo-'methods is too ambiguous. We just need to solve two issues : intuitive order of arguments and nested call readability. We don't need to implement the whole OO stuff for scalars. Except this detail, no limitation IMO.
Regards
François
I think that, while attractive, using the same syntax for object methods
and scalar 'pseudo-'methods is too ambiguous. We just need to solve two
issues : intuitive order of arguments and nested call readability. We don't
need to implement the whole OO stuff for scalars. Except this detail, no
limitation IMO.
if you're going to write API for string manipulation for example you want
it either Object Oriented or procedural style. because the API should be
fluent method chaining etc. you don't want to stop the chain and wrap it
with a function call. (just my opinion) these things needs to be discussed
if the internals are willing to do it. it will happen !
i'm completely sure the many developers will support the new API and all of
them are willing to help.
i wrote some code imagining that we have the new API. PHP will just be so
beautiful it will be a HUGE success.
Regards
De : Nathan wesley [mailto:nathan.o.wesley@gmail.com]
if you're going to write API for string manipulation for example you want it either Object Oriented or procedural style.
because the API should be fluent method chaining etc. you don't want to stop the chain and wrap it with a function call.
(just my opinion) these things needs to be discussed if the internals are willing to do it. it will happen !
What I meant is that we need a syntax that allows unambiguous parameter order and chained calls but we probably shouldn't use the '->' operator for scalars. The main reason is that it would make code harder to understand, but there are other reasons (like function receiving object arguments).
Regards
François
Hi Nathan,
On Sat, Mar 21, 2015 at 1:01 PM, Nathan wesley nathan.o.wesley@gmail.com
wrote:
I know that many people talked about this over and over.
Why it’s not possible to change the old PHP API ?
The answer is always because it will make HUGE BC breaksI’ve seen this wonderful idea about scalar objects authored by nikic
github https://github.com/nikic/scalar_objects.This will become even more possible when PHP 7 is introduced because of
scalar types and many great features making the idea more reliable.This makes an opportunity to replace the old API with object oriented one
preventing any kind of BC break.But instead of using this as an extension because of some limitations like
“string”->startsWith(‘s’); the API should be bundled with the engine (not
written in PHP).This will make the opportunity to also remove any inconsistencies in the
API behavior as well.I know that many people here will say that it’s not that important
developers get used to this API and many tutorials based on it.But it’s actually really important for the future of the language may be
not so much for the existing developers (I disagree it’s). but this will
also encourage new comers to use PHP.I’ve seen many articles encouraging new comers to learn languages like
Python or Ruby, and highly discourage them from using PHP. Also many new
projects are using languages different than PHP. (don’t tell me you haven’t
seen this)This will be an issue the number of language users will drop significantly
over the years causing the death of the language.I know that this is not an easy task. But this is a wonderful opportunity
to do this without BC breaks. I’m not suggesting that this should be for
PHP 7.0 because it will take a lot of work may be for any release in PHP
7.*PHP internals around 40 people ? not really sure but I know you are very
busy with fixing bugs and you have a lot of work already if you think this
is a huge task it can be assigned to a good group of people similar to how
the amazing PHP Framework Interop Group has accomplished,for Designing the new Object Oriented API. PHP internals will vote on the
design and implement it.The old API should be deprecated in PHP 8.0 and removed completely in PHP
9.0 (finally)I hope that you take this seriously and tell me if there are any
limitations that prevents this from happening.
I don't think almost all of old API will not be removed. "Replace"
wouldn't work
well as it breaks apps unnecessarily.
What we can do is "Provide new API and improve old API, while keeping
compatibility as much as possible".
Anyway, we are better to decide how PHP internal is going to use namespace
ASAP. It gives us a lot freedom for introducing new API while keeping
compatibility.
I fully agree that consistency is very important. Let's be consistent as
much as possible.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
This makes an opportunity to replace the old API with object oriented one
preventing any kind of BC break.But instead of using this as an extension because of some limitations like
“string”->startsWith(‘s’); the API should be bundled with the engine (not
written in PHP).
This is the problem with all these proposals. Instead of taking the
gradual road of making a beautiful API in extension, having it accepted
(I'm taking the optimistic scenario), popular and then merged into the
engine, it's always "let's redo the whole engine from scratch". That's
why these things haven't gone beyond talk for years.
This will make the opportunity to also remove any inconsistencies in the
API behavior as well.
You write "remove inconsistencies", I read "break all existing code".
I’ve seen many articles encouraging new comers to learn languages like
Python or Ruby, and highly discourage them from using PHP. Also many new
projects are using languages different than PHP. (don’t tell me you haven’t
seen this)
I've seen a lot of silly stuff on the Internet, so what? It's a free
medium, anyone can write anything. That doesn't mean it carries any
weight by the fact of writing.
The old API should be deprecated in PHP 8.0 and removed completely in PHP
9.0 (finally)
Which means no code written in PHP would work in PHP 9.0. Why then call
it PHP? Call it something else.
BTW, if you look at Java, some methods deprecated in Java 2 are still
around in Java 8. Java didn't die from it. Why people are so zealous to
break things that work?
Stas Malyshev
smalyshev@gmail.com
Hi!
This makes an opportunity to replace the old API with object oriented one
preventing any kind of BC break.But instead of using this as an extension because of some limitations
like
“string”->startsWith(‘s’); the API should be bundled with the engine (not
written in PHP).This is the problem with all these proposals. Instead of taking the
gradual road of making a beautiful API in extension, having it accepted
(I'm taking the optimistic scenario), popular and then merged into the
engine, it's always "let's redo the whole engine from scratch". That's
why these things haven't gone beyond talk for years.
I didn't say that you should redo the whole engine from scratch this is not
possible of course taking the FIRST step would be great
when i talked about 'extension' i mentioned the limitations. but i meant
the API shouldn't be written in user land code that's all
it can start as an extension and gradually support these limitations when
more people start to use it.
This will make the opportunity to also remove any inconsistencies in the
API behavior as well.You write "remove inconsistencies", I read "break all existing code".
you didn't get my point. i mean't the new API shouldn't behave the same as
the old one there are some behavioural inconsistencies shouldn't be
introduced in the new one. the old API won't be touched at all. no breaking
for existing code. that's the point of this proposal
I’ve seen many articles encouraging new comers to learn languages like
Python or Ruby, and highly discourage them from using PHP. Also many new
projects are using languages different than PHP. (don’t tell me you
haven’t
seen this)I've seen a lot of silly stuff on the Internet, so what? It's a free
medium, anyone can write anything. That doesn't mean it carries any
weight by the fact of writing.
When the vast majority agree that's a problem (it carries weight). it's
just too common.
famous articles written about it like "PHP fractal of bad design" and "php
sadness" a lot more
i highly doubt that you didn't read one of these.
i like PHP i care about it. it's future is important you "the internals"
will decide what will happen
many years from now. and you have a good opportunity to get this right.
even if someone managed to
do all of these things and submit an RFC you will vote on it. only you can
decide i hope you chose the
right thing.
The old API should be deprecated in PHP 8.0 and removed completely in PHP
9.0 (finally)Which means no code written in PHP would work in PHP 9.0. Why then call
it PHP? Call it something else.
You just agreed on disagreeing :) this is 20 years until PHP 9 comes out.
PHP 7 is not yet released. you can
argue about it when we get to this point in time. maybe the need for
removal can be predicted by the adoption of the new API. the old mysql
extension was also used everywhere.
BTW, if you look at Java, some methods deprecated in Java 2 are still
around in Java 8. Java didn't die from it. Why people are so zealous to
break things that work?
i didn't mention any break or things. also many languages are different
from they were 20 years from now. languages keep evolving. you may not see
this as a breaking change 20 years from now imo
Thanks for taking the time replying to this
Regards
Hi!
famous articles written about it like "PHP fractal of bad design" and
That article. Which is from what I remember last time reading it was
about 75% like "why I need to look in the manual instead of language
being magically exactly the way I imagine it should be without any
basis?". And another 20% like "why PHP is not my favorite language? How
dare they take decisions that I don't agree with?" Yeah, some people
have opinions.
i highly doubt that you didn't read one of these.
I did read these and then some. As I said, people write a lot of stuff.
Just because some guy somewhere wrote "php sucks" doesn't mean we should
do massive changes. PHP is not ideal, it has its warts, but bringing up
"people on the internet write that php sucks" each time change is
discussed is useless. The change should be proven on its own merits, not
on merit of some guy on the internet saying php sucks.
i didn't mention any break or things. also many languages are different
Yes you did. You just proposed removing large part of PHP API. That
would break things, there can be no confusion about it. If you propose
additional API, that's fine - but before there's any talk about
removing stuff, you should have the existing already overwhelmingly
popular API in your hand.
from they were 20 years from now. languages keep evolving. you may not
see this as a breaking change 20 years from now imo
Then let's talk about it in 20 years. No point talking about it now. Now
we should talk about what we can do now - i.e. making better API.
--
Stas Malyshev
smalyshev@gmail.com
i didn't mention any break or things. also many languages are different
Yes you did. You just proposed removing large part of PHP API. That
would break things, there can be no confusion about it.
I just agree with you. we shouldn't :) the old API will stay no one
will ever remove it.
If you propose
additional API, that's fine - but before there's any talk about
removing stuff, you should have the existing already overwhelmingly
popular API in your hand.
exactly i propose additional Object oriented API (not touching BC, no
breaking)
i suppose you agree with this and that's excellent. (i'm ready to help if
you like)
but you have much more experience with the engine and i hope you folks do it
in the near future. this will be very important for the future of PHP.
i am just waiting the YES it will happen. and that's enough for me.
Thank you for taking the time replying to this. it's highly appreciated.
Best Regards