pplusplus:faq
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Next revisionBoth sides next revision | ||
pplusplus:faq [2019/08/12 11:54] – jasny | pplusplus:faq [2019/08/12 12:09] – Move 'concerns' into a separate document, revert dynamic/weak/strong changes - "strict" means strong and static typing zeev | ||
---|---|---|---|
Line 83: | Line 83: | ||
There' | There' | ||
- | - **Stick with loose (aka weak) dynamic PHP**. | + | - **Stick with dynamic PHP**. |
- | - **Evolve towards | + | - **Evolve towards |
- **Fork the codebase**. | - **Fork the codebase**. | ||
- **Come up with some creative solution to cater to both audiences**. | - **Come up with some creative solution to cater to both audiences**. | ||
Line 115: | Line 115: | ||
==== What are the general concerns? | ==== What are the general concerns? | ||
- | === The dialect won't be limited to loose vs strict === | + | Arnold Daniels compiled |
- | + | ||
- | Progression of PHP may halt as any substantial changes are be opted to be done in P++ only. With the '' | + | |
- | + | ||
- | === Semantics should not be changed based on a flag === | + | |
- | + | ||
- | In [[https://externals.io/ | + | |
- | + | ||
- | < | + | |
- | + | ||
- | < | + | |
- | " | + | |
- | </ | + | |
- | or: | + | |
- | + | ||
- | <code php> | + | |
- | " | + | |
- | </ | + | |
- | Anything else will bring confusion. | + | |
- | + | ||
- | —Claude | + | |
- | </ | + | |
- | + | ||
- | === Converting PHP code to P++ code is not trivial === | + | |
- | + | ||
- | For applications that do not rely on implicit typecasting, | + | |
- | + | ||
- | The concern is that the syntax of PHP and P++ will grow apart to such an extent, that converting | + | |
- | + | ||
- | === PHP tooling will not support P++ === | + | |
- | + | ||
- | There are a lot of tools available for PHP developers, like IDEs, testing frameworks, etc. Supporting both PHP and P++ requires effort from maintainers of those tools. Those maintainers might choose not to invest the time for support until P++ has a substantial user base. On the other hand, devs might choose not to P++ until it has proper tooling support. | + | |
- | + | ||
- | === It's not possible to do a cleanup without breaking PHP compatibility === | + | |
- | + | ||
- | < | + | |
- | + | ||
- | Andi | + | |
- | </ | + | |
- | + | ||
- | Removing things like references, array() and the global namespace for functions would make it impossible to use PHP functions from P++. | + | |
- | + | ||
- | === Compatibility would only be one way === | + | |
- | + | ||
- | Introducing new data structures that only exist in P++, could make it impossible for PHP library to use P++ libraries. | + | |
- | + | ||
- | === P++ would have to do branding from scratch === | + | |
- | + | ||
- | < | + | |
- | to find P++ in Google? How are users searching for things with PHP and P++? | + | |
- | What's the documentation going to look like for two languages that share so | + | |
- | much? Specifically from a marketing POV splitting up the language into two | + | |
- | makes no sense at all. Given PHP has no unified marketing message or a | + | |
- | dedicated department it is much better to use the existing brand, with all | + | |
- | its positive and negative perception and just keep rolling with it. | + | |
- | + | ||
- | A strategy to change the security or any other perception of PHP is solely | + | |
- | a marketing, teaching and persistence issue. As you say the language is | + | |
- | already the fastest dynamic language with the best runtime. But " | + | |
- | over" with 0 brand name and perception is much harder problem than changing | + | |
- | the existing brand, and its not at all technical challenge. | + | |
- | + | ||
- | Benjamin | + | |
- | </ | + | |
- | + | ||
- | === The popularity of Python doesn' | + | |
- | + | ||
- | < | + | |
- | + | ||
- | Peter</ | + | |
- | + | ||
- | The popularity of Python is rapidly increasing at the cost of the popularity of PHP. Python is praised with simplicity. However, is uncertain to what extent the popularity is related to simplicity, and specifically typing, and to which is this related to better libraries (both core libs and user libs). | + | |
- | + | ||
- | === Is a new dialect really necessary? === | + | |
- | + | ||
- | < | + | |
- | want basically impossible. The BC crowd is just being unreasonable and only | + | |
- | the tech that evolves realistically survives. You cannot have the BC cake | + | |
- | and eat it, at some point you have to upgrade and update your application | + | |
- | code. | + | |
- | + | ||
- | The " | + | |
- | are so impatient - there is Go, NodeJS with it's JavaScript/ | + | |
- | etc. Right now PHP does has somewhat of a plan and direction it is going, | + | |
- | it is going at a decent pace - not too slow, not too fast. | + | |
- | + | ||
- | Arvīds Godjuks | + | |
- | </ | + | |
- | + | ||
- | As an alternative, | + | |
- | + | ||
- | New and more strict data structures could be introduced. Attempts for this have been made through the [[http:// | + | |
- | + | ||
- | Functionality that's being deprecated and removed or unbundled is rarely used. The removal of '' | + | |
- | + | ||
- | < | + | |
- | + | ||
- | Sara</ | + | |
- | + | ||
- | New feature and new core functions (like a new string library) would not break backward compatibility. | + |
pplusplus/faq.txt · Last modified: 2019/08/14 13:47 by zeev