Closed posxposy closed 4 years ago
We could go for this, as long as null
is still accepted and does not generate a deprecation warning. We could replace null
by this
in official documentation (and still state that null
is no longer the spec, although accepted for backward compatibility)
Why this
over private
or protected
?
Why this over private or protected?
private
in Haxe may be confusing because private
field can be modified by child classes. While null
access means "truly private" when only the owner can modify that field.
protected
in other world is mean the same what private
in Haxe do, so it is may be confusing too :)
private
in Haxe may be confusing becauseprivate
field can be modified by child classes. Whilenull
access means "truly private" when only the owner can modify that field.
I don't think that's true. But @ncannasse had some other argument against private
. Something about mixing visibility and access modifiers.
I don't think that's true.
Oh damn :D
I'm against making such small changes to property syntax. It already is a mess and allowing more keywords only makes it even more of a mess. I also don't find this
more intuitive than null
, so in both cases it's a matter of remembering the right keyword.
I would leave the current property syntax alone and focus on introducing an entirely different alternative akin to C#.
... which I just noticed is also being suggested in #63.
This has been rejected by votes from @ncannasse, @nadako, @RealyUniqueName, @jdonaldson and @simn for the reasons previously stated.
It's a bit confusing to use
null
as a private access modifier.this
is much more understandable and gives as a context about who can modify the current field.Example:
Rendered version
Thanks!