> On Apr 7, 2017, at 10:32 AM, BJ Homer <bjho...@gmail.com> wrote:
> 
> 
> On Apr 7, 2017, at 9:23 AM, Matthew Johnson <matt...@anandabits.com 
> <mailto:matt...@anandabits.com>> wrote:
> 
>> The most common thing is to have some stored properties that are private and 
>> include a handful of fileprivate (or higher) methods that operate on these 
>> properties in the type declaration.  All members that don’t need direct 
>> access to these properties are placed in extensions specifically to prevent 
>> the direct access to stored properties which they don’t need.  This 
>> minimizes the lines of code with access to such properties.
> 
> Is there a reason this could not be implemented by putting all the sensitive 
> stored properties in a separate type from the rest of the code?

This has already been discussed extensively in the threads.  The problem with 
this approach under the current proposal is that there is no way to hide that 
type or its members from the rest of the file.  It can be extended anywhere in 
the file which means the kind of encapsulation intended by users of scoped 
access is not really available.  This is a kind of half-solution that relies on 
not extending the separate type and therefore offers a weaker guarantee while 
requiring extra boilerplate.  It is also a kind of half-solution for those who 
wanted to revert SE-0025.  

Setting aside source compatibility concerns for a brief moment, is there anyone 
who would choose this approach over reverting SE-0025, renaming the current 
modifier, or maintaining the current access modifiers?  If this is nobody’s 
first choice that should be a big cautionary sign.  It would indicate that this 
is the result of “design by committee” where nobody really likes it and it is 
at best the closest to consensus we could get.  I don’t think “this is the best 
we can do because of source compatibility” is an appropriate justification for 
accepting this kind of solution.  If source compatibility is such a paramount 
concern we should probably maintain the status quo or keep looking for a 
better, more source-compatible solution in the future (probably Swift 5).

I think one of the goals for Swift is to try and avoid that kind of decision 
making.  If I’m going to be dissatisfied with part of the language I would 
rather it be for some other reason than that SE has caused the language to 
suffer from “design by committee” kinds of flaws.

> 
> -BJ

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to