Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
My problem with protected is that it encourages using inheritance where the derived class is not in fact a valid replacement for the base, and adding responsibilities to the derived class according to their data dependencies rather than their capabilities.
Any protected method that user code can safely use can be public. All incentives for hiding a method from external code other than aesthetics also apply to external subclasses. -
@Parzi doesn't protected mean "same as private, but visible to subclasses" (in e.g. C++)? It's not the same as public or private as I understand it
Why not! 😂
Can't wait for this to happen
As a long-time iPhone user, I am really sorry to say it but I think Apple has completed their transition to be...
in apple's blog they explained why they don't want a `protected` in swift:
https://developer.apple.com/swift/...
> It doesn’t actually offer any real protection, since a subclass can always expose “protected” API through a new public method or property."
Isn't the same thinking applies to `internal` keyword as well? Yet they allow `internal` to be there as default modifier for `class` in a package. Also I don't think `protected` is for the sole purpose of "protection", but for the cleanliness of externally visible interface, some methods are just useless to be exposed and will confuse the consumer if they don't understand internally how the class works. So it doesn't have to be 100% securely `protected` (arguably the term `protected` is a poor choice tho).
but hey, it is apple, being opinionated doesn't surprise me.
rant
swift
apple