On 3/19/2016 5:04 AM, Larry Garfield wrote: > On 03/18/2016 03:49 PM, Fleshgrinder wrote: >> First a general note on the complete nullability first: It is not up to >> us as language designers to decide whether it is good practice to use >> nullable properties or not. It is supported by many systems since ages >> (e.g. SQL where nullable fields are also not recommended but heck they >> are useful) and it is common practice in PHP. Hence, there must be >> support for it. That does not mean that it is endorsed in any way by us, >> it is just there for people who need it for the same reasons they needed >> it in the past 20 or so years. > > At the risk of a small tangent, I cannot agree at all here. The whole > point of language design is to make decisions regarding what "good > practices" to encourage, enforce, or disallow. Some languages disallow > mutable variables (despite them being useful). Some languages disallow > global variables (despite them being occasionally useful). Some > languages disallow NULLs (despite them having use cases in many > languages). Those are all viable and reasonable decisions for a > language designer to make in various circumstances; to say that it's > "not up to us as language designers" to make such decisions is to > abdicate our responsibility as language designers. > > There may well be good arguments to allow property nullability. There's > also good arguments against it. We'll decide one way or another. But > "we shouldn't take a position at all" is worse than taking a position, > because that implicitly does take a position (allowing it), while > pretending that we didn't. Basically it means lying to ourselves about > it, which is never the right answer. > > Design is about making deliberate, informed decisions. Let's make a > deliberate, informed decision. > > To help with the informed part, can anyone speak to how other languages > handle null-typed properties? I believe Java allows everything to be > NULL (which sucks), but I'm not sure about other modern languages. Can > anyone speak to that? (I'd be particularly interested in Python, Go, > and Rust, but any language you can speak to definitively would be > valuable to know about. Javascript and Ruby are, AFAIK, insufficiently > typed for the question to apply.) > > --Larry Garfield >
Nope Larry, you are actually totally right and I am completely wrong. I played around with the current implementation at https://3v4l.org/ and some PHP voodoo that is required to work around missing access modifiers for proper information hiding and I could not find a situation where nullability was actually required nor beneficial at all. I simply was still stuck in the beginning of the discussion where it was asked in regards to invalid state after the construction and if properties are allowed to be *void* (I call it now *void* to avoid my own confusion with *null*) or not. Hence, I mixed that up and came to completely wrong conclusions and a desperate argumentation towards language design. I actually feel ashamed right now because that is truly what language design is about and I was preaching that in other threads. :P Properties need the ability to be void even after construction and it is up to the object to keep track and ensure state. Nullability is imho not necessary at all. So we are all in line here. Only topics left (for me) are special features (*mysqli_result::fetch_object* and *PDOStatement::fetchObject*) and references. I see solutions (summarized in other messages of mine) to all of them but I do not see them being implemented or even thought about. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
