[PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
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.
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
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)
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
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 On Sat, Mar 21, 2015 at 10:25 AM, Pierre Joye wrote: > > On Mar 21, 2015 2:15 PM, "Levi Morrison" wrote: > > > > > 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 ;) > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > >
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
> > 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
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
> > 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
Re: [PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API
> > > 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
