Previous discussions have covered the probability that strict typing and dynamic typing can't coexist, because strict typing ends up pushing itself further up the call tree. An ini setting to change from one to the other will not solve that problem. Not sure that it says anything about enums, but strict vs. dynamic typing is a hot topic that probably won't get any agreement here. The previous discussions are just too recent, and it's not likely anyone has changed their mind.
On Thu, Feb 23, 2012 at 12:21 PM, Kris Craig <kris.cr...@gmail.com> wrote: > Hmm I think Stas makes a good point. One of the allures of PHP, > particularly for web developers without any programming experience, is its > flexibility. Strict typing would certainly negate that. > > If I may be so bold, should we perhaps expand the scope of this discussion > to address the larger question of whether or not strict typing should be > introduced into PHP, and if so, in what form and to what extent? It seems > to me that we must answer that question before we can answer the enum one. > > Specifically, these are the questions that come to mind: > > 1. Is strict typing something that we should seriously consider > implementing at some point in the foreseeable future? > 2. If "yes", should it be an "always on" type of thing or a toggleable > thing? > 3. If toggleable, should this be defined at the config level, the script > level, or both? > 4. Depending on your answers to 1 - 3, what would be the advantages to > this approach? > 5. Depending on your answers to 1 - 3, what would be the disadvantages > to this approach? > > If y'all wouldn't mind humoring me, would you be willing to send your > answers to these questions in your next reply? I think it would help us to > bring some objective clarity to this issue as well as guage what the > current consensus is, if there is one. > > > As such, here are the answers that come to my mind: > > 1. Yes, I think the idea has enough merit for further consideration. > 2. Definitely toggleable! It would probably have to be "off" by default > for the sake of backwards compatibility. > 3. I'm not sure, but my inclination would be both. Perhaps an INI value > that can easily be set at the script level, similar to > max_execution_time. > 4. Advantages: > - Strictly-typed code is much easier to read and follow. > - Programmers experienced in other languages like C# and Java would > find PHP much more appealing. > - It would allow for much more simplified code with fewer sanity > checks at the script-level. > - For example, I've been working on a Drupal-based project that > was written by another person (it's work-related so I'm distorting > the > details so as not to breach the NDA). This person had the > annoying habit > of "sending" variables (JSON-encoded/decoded from a remote > hub that he also > wrote) with inconsistent types. For example, the "progress" > key could be a > multidimensional array, a string, NULL, a boolean, and in one > rare case > even an object pointer. But MOST of the time, it's an array, > and the way > the architecture is setup, there's no way to anticipate what > type it will > be except to test for it. So, rather than simply being able > to check for > something like, $progress["percent"], I instead have to do a > ton of sanity > checks to first make sure it's the type of variable I'm > looking for at any > particular moment. > - Frequently requested features, like enums, would no longer be > impractical. > - Seasoned PHP developers who want to venture into compiled > programming languages could first enable strict typing as a > stepping stone, > reducing the learning curve. > 5. Disadvantages: > - It would probably be a fairly large undertaking to implement. > - This could result in a sort of pseudo-parallel set of languages > emerging within PHP core, since some things, like enums, would > presumably > be dependent upon strict typing being enabled. > - Though it would allow for simpler, easier to follow code, it > probably(?) wouldn't actually add any practical functionality in > terms of > what PHP can actually *do* that it doesn't have already in other > forms. > > Those are my thoughts. It's too early for me to draw any conclusions on > whether this should be implemented or not. I'd like to see what the rest > of you have to say on the subject. > > If you wouldn't mind jumping through my hoops and answering the above > questions as I just did, I think that would help us all to quantify this > from different angles and arrive at a much clearer understanding as to the > implications involved. =) > > --Kris > > > On Thu, Feb 23, 2012 at 10:34 AM, Stas Malyshev <smalys...@sugarcrm.com > >wrote: > > > Hi! > > > > > > If you're going to go that far, why not make a flyweight enum type? > >> (Basically what's described here: > http://c2.com/cgi/wiki?**FlyweightEnum< > http://c2.com/cgi/wiki?FlyweightEnum> > >> )... > >> > >> Right now, it's a hack to get typing in place to let you pass an > >> integer where a class is defined (the public function foo(MyEnum > >> $enum) bit). If you used a flyweight, you could literally type-hint. > >> > > > > Again, it looks like you are trying to introduce strict typing into PHP. > I > > do not think it's a good idea, for the reasons I described at length in > > previous discussions, but you're free to try. > > However, I don't see how changing the language to make it easier to do > > partial backdoor strict typing is a good idea. Bringing Java as an > example > > only supports this point. > > > > -- > > Stanislav Malyshev, Software Architect > > SugarCRM: http://www.sugarcrm.com/ > > (408)454-6900 ext. 227 > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
