Re: Non-nullable properties

On 16 July 2018 19:42:49 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote: >Hi! > >> I agree with you. If someone really wants to have an "uninitialized" >field >> on purpose, they should do that using the correct type declaration, >i.e.: >> >> ?MyType $myNullable = null; >> >> When this was started I asked if it was possible to check types right >after >> object has been constructed, but they said it was inefficient to do >so. >> If this is still true, then I'm ok with checking on first access >instead. I >> don't want even more overhead from runtime type checking. >> This is definitely not as bad as the "billion dollar mistake" though. >The >> error still happens, but in a different place. > >In Java, avoiding these kinds of errors - when the property is not >initialized - is almost trivial, and that's not what "billion dollar >mistake" is about. Lack of initialization for a final value (which is a >frequent case with property values) is detected by the compiler, and >most IDEs/analysis tools would alert of lack of initialization for >non-final value too. The problem is with usage on null as a >substitution >for no value/error/unknown value and this value bleeding out into parts >of the code that don't know how to handle this situation. Fair enough. To avoid us getting sidetracked, I retract my mistaken comparison to the "billion dollar mistake". It felt like a cute reference to include, but it didn't really help explain my point. However, I stand by my opinion that introducing an error-on-access state for properties will lead to more problems than it solves, and that if we can't guarantee non-nullable properties are actually non-null, then we shouldn't allow them at all. Regards, -- Rowan Collins [IMSoP]