[swift-evolution] Make access control private by default.

[L. Mihalkovic]

> On May 24, 2016, at 4:23 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I was just about to mention this too. I think it's interesting that
>> one can write a simple application in Swift without having to worry
>> (much) about visibility of elements. Please note I'm talking about
>> applications not frameworks.
> 
> I'm glad this is working for you, because this is exactly the intent.
> 
>> I also agree this is good for teachability because you can worry about
>> more important aspects of programming (functionality and structure)
>> than just the correct visibility (that makes no difference to a
>> student until they move to coding a framework themselves).
> 
> Right.  I think the phrase Chris likes to pull out here is "progressive disclosure":
> the language should allow you to focus on learning one lesson at a time.
> Making students write "public" everywhere doesn't make understand good
> code structure and encapsulation; it just forces them to learn a magic word.
> 
> In fact — and here I'll confess to not being up-to-date on CS pedagogy
> research, and if I'm mistaken I would be happy to be corrected — intuitively I find
> it improbable that you can really teach encapsulation to intro students at all.
> I mean, sure, you can teach the terminology and mechanics, and you can
> mandate a particular code style for their assignments, but they won't really
> understand the value until they've experienced the problems of code that
> *isn't* well-abstracted.

+1 share the view. Over the years I have seen a lot of IMHO poorly abstracted code that on the outside was following the view that if "if it is inside, then it is good OO". Teaching encapsulation is hard, and I do join the chorus saying that the problem starts was initializers (I do *pray* that swift does not give in to the partial-inits/auto-inits proposals I've seen floating). I understand more and more, in my day to day professional life, why people would look to FP for a solution: the mount of damages contained in an bad method at least has a clear boundary.


> 
>> But I also agree that, to some extent, private may not make sense if
>> the default visibility is already not visible outside the current
>> module but should that be an excuse to just drop it?
> 
> It makes sense for programmers to be able to develop strong abstractions
> within a module.  We're not going to drop private.
> 
> John.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution