Hi! > I am not sure what you're implying by "some people have no appreciation > of the usefulness of"... I am well aware of NULL's use cases. I am also > well aware that the general zeitgeist in the language development > community is that they're dangerous; the designer of the first language
I would like to note in general that following the latest fashion in academic development is not always a good idea for PHP. It's fine when you experiment with academic languages, but when you have language that a) focused on simplicity and low entrance barrier and b) is in production use by millions and has 20 years of existing practices, libraries and habits, we have to be a bit more wary, I think. I am *not* saying we should not improve, or ignore academic developments, I am saying that we should be careful with not jumping to the idea-of-the-day bandwagon too fast, before it is clear it is good and necessary for PHP. As an example, I don't see how exactly eliminating null would be good for PHP, or doing *anything* with null for that matter. > to have them calls them a "billion dollar mistake", many languages > actively avoid having NULL in favor of something deliberately more > structured. NULLs are a very common cause of avoidable fatal errors in > many languages (including PHP). NULLs are rude to users of your API, as > it balloons the error handling code they need to deal with. I think this description is misleading in a way. Nulls are immediate causes of many errors, technically, in a meaning that "if I find null where I expected to have DB connection, I get an error" - but this is only a technical cause. The *real* cause is the failure to check whether your attempt to connect to the database succeeded, or that you have proper DB configuration, or such, and null is just a symptom of that error - and that error is not automagically fixed by having some other object instead of null. You have to actually design and write code for it, there's no replacement for it. So declaring null "cause of all evils" is ignoring the real causes and blaming immediate technical cause instead, and it would not be helpful. It is true that for some languages with more complex type systems it is possible to largely get rid of nulls by using those complex types and ensure type system controls for all checks at least to be present (note that doesn't guarantee proper function either, since no type system can ensure you handle the case of missing DB connection properly, it just can ensure you have a branch for it). But that requires much more complex and involved type system that PHP has - or, in my opinion, should have. > I am on record and will continue to be on record that null is *usually* > wrong. I consider that position entirely justified, as does the > academic CS community. I am also now on record suggesting that we use > union types to allow type-or-null returns/parameters, which you're > welcome to quote me on. :-) I think this position is way too narrow, simplistic and detached from real language use towards abstract academic purity. There are tons of causes where using null is completely fine and exactly what is needed. I also think union types is a great and unnecessary complication of the language and in order to do them properly we'd need lots of facilities PHP does not have (like type pattern matching and static compilation) and I am not sure it should have - ones looking for Haskell know where to find it. And there are a lot of cases where failing on null is exactly what one needs - if it doesn't work, just fail and let somebody come and check what is going on. If your database died, your DB-bound code is not going to fix it. With or without nulls - it has to just fail and wait for somebody to fix it. There's no need to overcomplicate that. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
