> On May 24, 2016, at 4:23 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution >> <swift-evolution@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
