> On 17 Oct 2016, at 19:47, Jonathan Hull <jh...@gbis.com> wrote:
> First, let me say, thank you for your feedback.  Just because I am arguing 
> against others' points does not mean that I don’t appreciate those points.
>> On Oct 17, 2016, at 12:37 AM, Rien <r...@balancingrock.nl> wrote:
>> -1.
>> If an API designer wants to allow access to a “hidden’ member, he should be 
>> in control of that access.
> This seems to be one of the biggest internal arguments within the swift 
> community.  Who is in control of the use of frameworks?  The author or the 
> user?
> I am trying to plot a middle path here which gives both a fair amount of 
> control.  I think that is part of why this proposal has been so unpopular, it 
> is a compromise between both extremes, and everyone hates a compromise.  
> Someone else just had the opinion that we should make everything public and 
> note in the documentation what should and should not be used.
> And as I said before, API like UIGestureRecognizer's is currently impossible 
> to create solely in Swift.  There is a hole in Swift’s access system which we 
> will have to fix sometime during this phase.  I think a lot of people think 
> that submodules will magically solve all of our problems, (I want them too) 
> but the core issue here will remain (just with a little less frequency), and 
> we will be forced to go back to the drawing board in 6mo to a year. I am 
> hoping to prevent that.
>> The proposed chance simply opens up access completely and leads to API 
>> vulnerability.
> No, it only opens up access to API explicitly marked with ‘hidden’.  That is, 
> the framework author is explicitly saying: This API should only be used for 
> subclassing/extension (but they also realize it can be accessed).  The user 
> of that API has to explicitly acknowledge that intention by writing ‘import 
> hidden’.  API marked private or internal will not be opened beyond it’s scope 
> in any case.
> As I said in another email, a potential further compromise would be to make 
> ‘hidden’ a separate axis, and allow things like ‘internal hidden’, where 
> access can only be opened up within the module.  Would that solve your issues 
> with the proposal?
> I started out closer to your position, wanting more targeted permissions, but 
> I ultimately realized that this would be good enough for real world use.
>> (I am in favour of a “friend” solution, in which the API designer explicitly 
>> allows access to identified members of the API users.)
> But what happens when you need to be a friend and you don’t own the API?  I 
> get the thinking behind friend classes, but it is problematic in practice.

In that case, you don’t get to be a “friend”. Tough cookies. Life isn’t “fair”.
In an exact science like SW development, control must be hierarchical or 
singular. Any deviation, however small, will come back to bite.
Too many API developers have spend too much time to look for “errors” that 
inexperienced or unknowing API users caused because the API was too “open”. The 
API developer may think that “it is clearly documented”… but then again, look 
at stackoverflow…. people don’t read them, and the API developer will be held 
responsible for the error of others… if only in reputation...

>  As another poster mentioned, we basically have friend classes already, just 
> based on location of code.  The core issue I am trying to solve here cannot 
> be solved with more variation of the same, we need a counterpoint to it, and 
> then the two approaches can be mixed to get the desired balance/tradeoffs.

Balances and tradeoffs only get you deeper into the quicksand. Better not to 
tread there. Sometimes you have to say NO.


PS: I do understand the lure, buts it’s (IMO) always better to resist.

> Thanks,
> Jon
>> Rien.
>>> On 16 Oct 2016, at 22:34, Jonathan Hull via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> I keep wanting a “protected” access level, but I must also admit that there 
>>> was something really elegant about Swift 2’s access scheme (and I think 
>>> most of us feel like the word ‘fileprivate’ feels out of place).  I was 
>>> thinking about how to mesh those two ideas, and I think I may have come up 
>>> with a solution.
>>> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  
>>> Hidden would work exactly the same way as fileprivate does now, but adds 
>>> the connotation that what is hidden can also be unhidden.  By adding 
>>> ‘import hidden TypeName’ to another file, that file also gains access to 
>>> all of the hidden items of that type (kind of like if it was in the same 
>>> file).
>>> #FileA      
>>>     import Foundation
>>>     Struct A {
>>>             private var x:Int
>>>             hidden var y:Int  //This is just like fileprivate, but can also 
>>> be shared with other files
>>>     }
>>>     extension A {
>>>             //y can be accessed here because they are in the same file
>>>     }
>>> #FileB
>>>     import Foundation
>>>     import hidden A  //This allows the entire file to see A’s hidden 
>>> variables
>>>     extension A {
>>>             //y can be accessed here because of the ‘import hidden’ 
>>> declaration
>>>     }
>>> #FileC
>>>     import Foundation
>>>     extension A {
>>>             //y can NOT be seen or accessed here because it is hidden
>>>     }
>>> I think this is a fairly elegant solution to our protected dilemma, which 
>>> also feels in sync with Swift 2’s file-based scheme.  The key features:
>>>     • Extensions no longer need to be piled in the same file if it is 
>>> getting too long
>>>     • Subclasses can be in their own file, but still have access to the 
>>> necessary parts of their superclass
>>>     • It communicates the author’s intent that the items are not meant to 
>>> be visible to its users, but that it is expected to be used for 
>>> extension/subclassing
>>>     • It requires an explicit statement ‘import hidden’ to access the 
>>> hidden variables. Safe by default, with override.
>>>     • It is not bound by module boundaries  (i.e. you could use it for 
>>> subclassing classes from an imported module)
>>>     • Roughly the same length as ‘private’ and ‘public’ so various 
>>> declarations packed together are much easier to read (fileprivate breaks 
>>> reading rhythm)  
>>> Worth a formal proposal?
>>> Thanks,
>>> Jon
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to