# A remark about PHP's Vision and new things. - Thread: https://externals.io/message/64809 - Original archive: https://news-web.php.net/php.internals/64809 - Started by Nate Tuganov on 2013-01-10T09:17:45+00:00 - Messages: 20 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #64809 — Nate Tuganov — 2013-01-10T09:17:45+00:00 URL: https://externals.io/message/64809#64809 Hello, Well, I've been reading internals for years and never replied. But I think this time I have to share my thoughts. First of all I understand Rasmus and Stas position on holding PHP as simple as it is. It's great and in the same way it's wrong. As Anthony mentioned PHP evolves, and PHP is being used not only by designers who want to create a simple corp site which by the way move to Rails, but mostly by thousands of web agencies, developers and senior developers who constantly using different languages and technologies. We have Ruby with all the sugar it gives, we have Java with all enterprise mess it has. And we have PHP. I don't think I need to advocate OOP here, and I agree with Rasmus that we need to stay simple. But we don't need to copy all those things from Java for example, even Java world has Play! Framework which is great and gives simpleness to the developer. We all know how annotations are being used by Symfony or Doctrine and I don't think we need to create all the mess it has in Java world. We all know the problems it give, why not to eliminate it and create a new, PHP's vision of things. Right now all discussions are being held like we will never implement annotations because we need to copy it from Enterprise Java. But we don't need Java annotations, we need our own. Constantly decline great futures just because some designer wouldn't understand it is wrong by all means. PHP is great for web development, let's stick to it. Give us a chance to create frameworks, which can use Annotations, DI, IoC, Factories, Decorators and all others patterns to allow regular designer to create a simple site with few lines of code. -- Kind Regards, Ignat Tuganov Chief Information Officer Office Phone: +7 (812) 640-8022 E-Mail \ Gtalk: it@cloudmill.ru CloudMill LLC 191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia --- ## #64810 — Pierre Joye — 2013-01-10T09:21:52+00:00 URL: https://externals.io/message/64809#64810 · In reply to: #64809 > PHP is great for web development, let's stick to it. Give us a chance to > create frameworks, which can use Annotations, DI, IoC, Factories, > Decorators and all others patterns to allow regular designer to create a > simple site with few lines of code. That's exactly what annotations are for. Avoid writing the same code over and over, define behavior using annotation. I strongly suggest to anyone following the (too many) threads about annotations to try the C# annotation and see what it allows. It goes really far and greatly simplify developments and implementations of web services (by all meaning of this word). And I very strongly recommend it to anyone who never used or tried annotation, it will help us to move further and move out of the current rhetoric (both sides). -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #64815 — Ferenc Kovacs — 2013-01-10T12:11:47+00:00 URL: https://externals.io/message/64809#64815 · In reply to: #64809 > Hello, > > Well, I've been reading internals for years and never replied. But I think > this time I have to share my thoughts. > > First of all I understand Rasmus and Stas position on holding PHP as simple > as it is. It's great and in the same way it's wrong. As Anthony mentioned > PHP evolves, and PHP is being used not only by designers who want to create > a simple corp site which by the way move to Rails, but mostly by thousands > of web agencies, developers and senior developers who constantly using > different languages and technologies. We have Ruby with all the sugar it > gives, we have Java with all enterprise mess it has. And we have PHP. > > I don't think I need to advocate OOP here, and I agree with Rasmus that we > need to stay simple. But we don't need to copy all those things from Java > for example, even Java world has Play! Framework which is great and gives > simpleness to the developer. We all know how annotations are being used by > Symfony or Doctrine and I don't think we need to create all the mess it has > in Java world. We all know the problems it give, why not to eliminate it > and create a new, PHP's vision of things. Right now all discussions are > being held like we will never implement annotations because we need to copy > it from Enterprise Java. But we don't need Java annotations, we need our > own. Constantly decline great futures just because some designer wouldn't > understand it is wrong by all means. > > PHP is great for web development, let's stick to it. Give us a chance to > create frameworks, which can use Annotations, DI, IoC, Factories, > Decorators and all others patterns to allow regular designer to create a > simple site with few lines of code. > > -- > Kind Regards, > > Ignat Tuganov > Chief Information Officer > > Office Phone: +7 (812) 640-8022 > > E-Mail \ Gtalk: it@cloudmill.ru > > CloudMill LLC > 191015, 3 K Furazhnyi Lane, office #317, Saint-Petersburg, Russia > hi, another thing to keep in mind: most PHP frameworks out there has a faster development cycle and less of an userbase than us(as every PHP framework user is a PHP user ofc.), so if they make a bad design decision it is usually easier for them to fix it and it has less of an impact and they have more people with the ability to fix up any technical problems, as it is reasonably easy to find somebody with the neccessary skills and knowledge required to fix the problem. of course now that we introduced the new release process, hopefully we will have faster release cycles, and some of the popular frameworks started planning/introducing LTS releases with longer support cycle. but still, we have to be careful about what do we introduce to the language, because we have to support it for at least like minor 3 releases( we introduce it in 7.2, deprecate it in 7.3 and remove it in 8.0 for example). back in the early symfony days using Singletons everywhere seemed like a good idea, currently the general consensus is that it is an anti-pattern, and only in a handful of use-cases is it a good idea using it. similar thing happened with ORMs, first ORM meant pretty much using the activerecord pattern, now the general consensus seems to be to use the data mapper pattern instead. if we too eager to include new hip stuff, it can happen that we will get stuck with a half-baked solution which we have to support years after that the cool guys already moved to something else. the other thing that I mentioned is the difference between the required skills needed to fix up bad implementations: there aren't that many people familiar with the php-internals (and this isn't the easier skill to pick up, as we somehow lack in quality documentation on the internals part), even less people are familiar with the parser, ZendEngine, and APC. just some of the recent examples: - traits was a nice RFC, complete patch, has an active author, years of discussion, and it still needed a huge amount of work/refact to make it play nicely with some edge-cases and with APC. (kudos to Stefan and Dmitiry) - the finally feature: it was almost completely rewritten after the RFC with the initial patch was voted and accepted (kudos to Laruence and Dmitry) - introducing generators also needed some love (a few segfaults in edge-cases AFAIR and making it work together with finally kudos to Nikita and Dmitry). So I think the current problems are the following: - users won't migrate to new php version until some of the top pecl exts having issues with the new version (apc was a really obvious showstopper for the php5.4 adoptation for example). - currently voting is more about wanting the feature or not, and not about wanting/accepting the feature with the current implementation. this can result in situations when something is accepted and merged, but it has to be fixed/maintained, and that sucks when the work happens to require the help of those who voted no based on their understanding on the problems of the proposed rfc/patch. - we don't have enough QA exposure, so some of the problems will only surface after the first final release (the implementation problems of traits for example). - there are key areas where we lack active people (ZE, APC, etc.). - the previous (nonexistent) release process made us really slow on fixing/removing things: http://blog.roshambo.org/a-brief-unofficial-history-about-register_globals-in-php/(it was removed in 5.4.0 which was released 2012 Marc 01.) It took more than 10 years to remove it since the time it was first accepted as a bad decision to include. - the new release process allows/mandates planned and faster release cycles, but it also means that we can only remove features in major version jumps, which would either result in more frequent major feature bumps or long gaps between times when we can remove features. - and yeah, I think that php means a lot of different things to a lot of different people, so most of the times there can and will be arguments whether or not it is a good idea or the 'php way' to include something. but as long as we resolve those conflicts in civil manners and not using some kind of fallacy (or making intentionally confusing/incomplete RFCs and pushing through them the voting) it should be fine. Sorry for the wall-of-text: 'If I Had More Time, I Would Have Written a Shorter Letter' -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #64824 — Stas Malyshev — 2013-01-10T20:36:04+00:00 URL: https://externals.io/message/64809#64824 · In reply to: #64810 Hi! > I strongly suggest to anyone following the (too many) threads about > annotations to try the C# annotation and see what it allows. It goes As far as I can see, C# annotations rely on two very important things: 1. Compiler support. Compiler really knows a lot about what annotations do. 2. Extensive library support. Annotations themselves are just passive metadata, what makes them work is .net framework that uses them. This means to make annotations as useful in PHP we would have to have substantial support in the engine (including bytecode caching provisions, etc.) and some libraries that require very latest-and-greatest version of PHP. Another thing is that we're not having some features that are used extensively in C# annotations, main being named parameters support. I am saying this not to oppose the idea of annotations or the idea of looking into C# and other languages (actually, I think anybody who talks about it should look at least into what C# and Java do with it - and also what Python does, which is completely different direction, just to know other options). I'm just saying porting this to PHP may be less than straightforward. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64843 — guilhermeblanco@gmail.com — 2013-01-11T03:49:24+00:00 URL: https://externals.io/message/64809#64843 · In reply to: #64824 Stas, I totally agree and Pierrick and I faced all these problems during the creation of patch. If PHP doesn't all have support required for a given feature, let's just not only discuss feature, but also the required support too. Named parameters is a great example. I'd also name another one, ReflectionNamespace; namespaces are converted to strings and attached to their classes during compile time and you can never reflect over them to grab for example their names. I even mentioned to Andi back in 2010 that ZE gets re-written every 5 years. That happened in 2000, 2005 and we're now hitting walls because of "monster" changes required to implement feature A or B. Maybe it's time to consider a rewrite again? Cheers, On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote: > Hi! > > > […] > > As far as I can see, C# annotations rely on two very important things: > 1. Compiler support. Compiler really knows a lot about what annotations do. > 2. Extensive library support. Annotations themselves are just passive > metadata, what makes them work is .net framework that uses them. > > This means to make annotations as useful in PHP we would have to have > substantial support in the engine (including bytecode caching > provisions, etc.) and some libraries that require very > latest-and-greatest version of PHP. > > Another thing is that we're not having some features that are used > extensively in C# annotations, main being named parameters support. > > I am saying this not to oppose the idea of annotations or the idea of > looking into C# and other languages (actually, I think anybody who talks > about it should look at least into what C# and Java do with it - and > also what Python does, which is completely different direction, just to > know other options). I'm just saying porting this to PHP may be less > than straightforward. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #64845 — Clint Priest — 2013-01-11T04:06:39+00:00 URL: https://externals.io/message/64809#64845 · In reply to: #64843 Oooh, a rewrite? Can we write it in an object oriented language this time? Please? Pretty Please??? :D > Stas, > > I totally agree and Pierrick and I faced all these problems during the > creation of patch. > If PHP doesn't all have support required for a given feature, let's just > not only discuss feature, but also the required support too. Named > parameters is a great example. I'd also name another one, > ReflectionNamespace; namespaces are converted to strings and attached to > their classes during compile time and you can never reflect over them to > grab for example their names. > I even mentioned to Andi back in 2010 that ZE gets re-written every 5 > years. That happened in 2000, 2005 and we're now hitting walls because of > "monster" changes required to implement feature A or B. Maybe it's time to > consider a rewrite again? > > Cheers, > > > On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote: > > > […] > -- -Clint --- ## #64846 — dukeofgaming — 2013-01-11T04:13:14+00:00 URL: https://externals.io/message/64809#64846 · In reply to: #64843 Hi, I suggest you start defining action items in the RFC. After reading what Stas and others say, this looks like too big a task to discuss in itself, so it should be definitely be broken down. You will probably find that as it is broken down, actual development support will surface by itself. Regards, David On Thu, Jan 10, 2013 at 9:49 PM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > Stas, > > I totally agree and Pierrick and I faced all these problems during the > creation of patch. > If PHP doesn't all have support required for a given feature, let's just > not only discuss feature, but also the required support too. Named > parameters is a great example. I'd also name another one, > ReflectionNamespace; namespaces are converted to strings and attached to > their classes during compile time and you can never reflect over them to > grab for example their names. > I even mentioned to Andi back in 2010 that ZE gets re-written every 5 > years. That happened in 2000, 2005 and we're now hitting walls because of > "monster" changes required to implement feature A or B. Maybe it's time to > consider a rewrite again? > > Cheers, > > > On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev > […] > > > […] > do. > > […] > > > -- > Guilherme Blanco > MSN: guilhermeblanco@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada --- ## #64848 — Pierre Joye — 2013-01-11T06:35:09+00:00 URL: https://externals.io/message/64809#64848 · In reply to: #64845 No. C++ is horrible. Very good read: http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > Oooh, a rewrite? Can we write it in an object oriented language this > time? Please? Pretty Please??? > > :D > > > > Stas, > > I totally agree and Pierrick and I faced all these problems during the > creation of patch. > If PHP doesn't all have support required for a given feature, let's just > not only discuss feature, but also the required support too. Named > parameters is a great example. I'd also name another one, > ReflectionNamespace; namespaces are converted to strings and attached to > their classes during compile time and you can never reflect over them to > grab for example their names. > I even mentioned to Andi back in 2010 that ZE gets re-written every 5 > years. That happened in 2000, 2005 and we're now hitting walls because of > "monster" changes required to implement feature A or B. Maybe it's time to > consider a rewrite again? > > Cheers, > > > On Thu, Jan 10, 2013 at 3:36 PM, Stas Malyshev wrote: > > > Hi! > > > I strongly suggest to anyone following the (too many) threads about > annotations to try the C# annotation and see what it allows. It goes > > > As far as I can see, C# annotations rely on two very important things: > 1. Compiler support. Compiler really knows a lot about what annotations do. > 2. Extensive library support. Annotations themselves are just passive > metadata, what makes them work is .net framework that uses them. > > This means to make annotations as useful in PHP we would have to have > substantial support in the engine (including bytecode caching > provisions, etc.) and some libraries that require very > latest-and-greatest version of PHP. > > Another thing is that we're not having some features that are used > extensively in C# annotations, main being named parameters support. > > I am saying this not to oppose the idea of annotations or the idea of > looking into C# and other languages (actually, I think anybody who talks > about it should look at least into what C# and Java do with it - and > also what Python does, which is completely different direction, just to > know other options). I'm just saying porting this to PHP may be less > than straightforward. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > > > -- > -Clint --- ## #64849 — Stas Malyshev — 2013-01-11T06:45:21+00:00 URL: https://externals.io/message/64809#64849 · In reply to: #64843 Hi! > parameters is a great example. I'd also name another one, > ReflectionNamespace; namespaces are converted to strings and attached to > their classes during compile time and you can never reflect over them to > grab for example their names. I still can't understand why you need ReflectionNamespace. Namespaces are just strings. If you have class name \Foo\bar\Baz, \Foo is namespace, \Foo\bar is namespace, and both can be created by splitting class name. For me, it's like asking for runtime support for #define in C - I don't even understand how such thing can be working. Can you explain what you mean here? > I even mentioned to Andi back in 2010 that ZE gets re-written every 5 > years. That happened in 2000, 2005 and we're now hitting walls because > of "monster" changes required to implement feature A or B. Maybe it's > time to consider a rewrite again? Rewrite of what? With what purpose? And who will be doing it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64852 — Lars Strojny — 2013-01-11T07:38:51+00:00 URL: https://externals.io/message/64809#64852 · In reply to: #64824 Hi Stas, I think you hit a nail here. Am 10.01.2013 um 21:36 schrieb Stas Malyshev : > Another thing is that we're not having some features that are used > extensively in C# annotations, main being named parameters support. To make sure we are not providing a somewhat cumbersome implementation, let’s start tackling named parameters first. It’s another long standing feature. We will most likely need named parameters for convenient annotations anyway. We have an (really old) RFC for that: https://wiki.php.net/rfc/namedparameters. cu, Lars --- ## #64863 — Clint Priest — 2013-01-11T15:32:09+00:00 URL: https://externals.io/message/64809#64863 · In reply to: #64848 It's a pretty decent read, but the major point that his article about the virtues of C misses a huge mark. Software written in C, when they become of sufficient size become completely impossible to keep track of. A function that is related to a zend_function struct could be placed anywhere, in any file and can be named in any way. Finding it is like looking for a needle in a haystack, then you add macros. When I first started with working with the php-core I was doing everything wrong because it's a big mess, that's what happens with C, it has no organization requirements whatsoever and unless everyone who is working on the project is highly organized in the same fashion it will become a disorganized mess. Sure, C++ adds a lot of things that *can* overly complicate things but at the very least it requires organization, something that most projects sorely need. Even so, C++ is not the only object oriented language out there. -Clint > No. C++ is horrible. Very good read: > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > > > > […] -- -Clint --- ## #64864 — Arvids Godjuks — 2013-01-11T15:46:49+00:00 URL: https://externals.io/message/64809#64864 · In reply to: #64863 2013/1/11 Clint Priest > .... > Even so, C++ is not the only object oriented language out there. > > -Clint I could not resist the urge to suggest D as an option :) Sorry for this troll attempt. Well, there is Quercus out there in the wild, they did it. Sure a total rewrite will give opportunity to correct many questionable choices and bad implementations. But is it really feasible? Arvids. --- ## #64866 — Stas Malyshev — 2013-01-11T19:17:34+00:00 URL: https://externals.io/message/64809#64866 · In reply to: #64863 Hi! > A function that is related to a zend_function struct could be placed > anywhere, in any file and can be named in any way. Finding it is like > looking for a needle in a haystack, then you add macros. You can do macros in C++ too, and you can have detached functions too. And it is perfectly possible to make mess with classes, I have seen it many times. Thinking that the language would somehow make you write good code is an illusion. It can help you or fail to help you, but it can never make you. C has tools to help you, though some of them aren't as powerful as I would wish for, it still has them. > When I first started with working with the php-core I was doing > everything wrong because it's a big mess, that's what happens with C, it It has nothing to do with C. Thinking that if PHP core was written in you would instantly get what's going on after 3 minutes looking in the code is, again, an illusion. PHP core is complex, because it does complex things. It also somewhat messy as any organic growth project becomes after 15 years. Nothing has anything to do with the language. You don't need C++ to not put new zend_hash functions into zend_compile.c. You just need common sense and knowledge how the project works. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #64868 — Levi Morrison — 2013-01-11T20:54:42+00:00 URL: https://externals.io/message/64809#64868 · In reply to: #64845 I would definitely vote "No" on object oriented. I'd vote for C++ but SOLELY because templates. I'd stay away from classes as they generally hurt performance. Sorry for the off-topic comment :) > Oooh, a rewrite? Can we write it in an object oriented language this time? > Please? Pretty Please??? > > :D > > > > > […] > > -- > -Clint --- ## #64869 — Clint Priest — 2013-01-11T21:46:44+00:00 URL: https://externals.io/message/64809#64869 · In reply to: #64866 > Hi! > > > […] > You can do macros in C++ too, and you can have detached functions too. > And it is perfectly possible to make mess with classes, I have seen it > many times. Thinking that the language would somehow make you write good > code is an illusion. It can help you or fail to help you, but it can > never make you. C has tools to help you, though some of them aren't as > powerful as I would wish for, it still has them. > > > […] > It has nothing to do with C. Thinking that if PHP core was written in > you would instantly get what's going on > after 3 minutes looking in the code is, again, an illusion. PHP core is > complex, because it does complex things. It also somewhat messy as any > organic growth project becomes after 15 years. Nothing has anything to > do with the language. You don't need C++ to not put new zend_hash > functions into zend_compile.c. You just need common sense and knowledge > how the project works. That's true, but you can't put a method on a ZendHash class without defining it within the class definition. I forget that C++ does let you actually implement that function outside of the class definition, but it's not a method of the class if it's not in the class definition. I've gotten too use to the way PHP does it where all of the code for the class is within the class definition it's-self, not quite the same as C++. Can we re-write PHP with PHP? ;) -- -Clint --- ## #64875 — Levi Morrison — 2013-01-12T05:35:57+00:00 URL: https://externals.io/message/64809#64875 · In reply to: #64869 > Can we re-write PHP with PHP? ;) Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP --- ## #64876 — Clint Priest — 2013-01-12T05:57:01+00:00 URL: https://externals.io/message/64809#64876 · In reply to: #64875 That is seriously funny.... > > […] > > Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP --- ## #64889 — guilhermeblanco@gmail.com — 2013-01-12T15:58:38+00:00 URL: https://externals.io/message/64809#64889 · In reply to: #64876 Not really insane. PHPPHP is very powerful. Imagine someone that have no idea about C but would love to propose something. Just fork the project, add the desired support in PHP and propose here. I guarantee it'll be easier to understand the caveats and the final patch easily. Cheers, > That is seriously funny.... > > On Jan 11, 2013, at 11:35 PM, Levi Morrison > wrote: > > > […] > https://github.com/ircmaxell/PHPPHP > > […] > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #64890 — Anthony Ferrara — 2013-01-12T16:08:05+00:00 URL: https://externals.io/message/64809#64890 · In reply to: #64889 In a semi-joke but oddly real concept. I get that the language proposals (c++) are half jokes. But if we're going down that road, why don't we consider rpython and building on top of HippyVM that's already partially built... It would have a number of advantages over C: 1. It compiles to C, so should generate portable code. 2. Can support JIT compilation for better performance 3. Has proven its performance already (even without JIT) 4. It's a higher level language with memory management (no need to worry about frees and the like) 5. It gives us all our nice OOP features (which can make certain tasks FAR easier). A not-so-serious, but half-serious idea... Anthony On Sat, Jan 12, 2013 at 10:58 AM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > Not really insane. > > PHPPHP is very powerful. Imagine someone that have no idea about C but > would love to propose something. > Just fork the project, add the desired support in PHP and propose here. I > guarantee it'll be easier to understand the caveats and the final patch > easily. > > Cheers, > > > On Sat, Jan 12, 2013 at 12:57 AM, Clint Priest > wrote: > > > […] > > > -- > Guilherme Blanco > MSN: guilhermeblanco@hotmail.com > GTalk: guilhermeblanco > Toronto - ON/Canada --- ## #64897 — Yahav Gindi Bar — 2013-01-12T16:50:51+00:00 URL: https://externals.io/message/64809#64897 · In reply to: #64875 On Sat, Jan 12, 2013 at 7:35 AM, Levi Morrison wrote: > > […] > > Anthony and Nikita are already on it: https://github.com/ircmaxell/PHPPHP > > -- > > > > Just wished to express my respect for Anthony and Nikita for creating such a awesome and cool project ! :) I'll fork and start investigate it as soon as I'll get some free time and will be happy to contribute!