> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution > <[email protected]> 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. > 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
