[swift-evolution] [Review] SE-0159: Fix Private Access Levels
vhesener at gmail.com
Fri Mar 24 12:29:55 CDT 2017
I agree it would be hard. In fact, it would be the most difficult part
about it. Like how the API team at Apple will debate for weeks the name of
a foundation method.
Another counter point to my theory is that most developers will go for the
automatic "private var". So there would definitely be a habitual ritual
learning curve. But imagine how much more accurate and descriptive it would
be for new folks. And Crustys (like me) can claim a terse semantic victory,
although having to relearn some mental autopilot routines.
On Fri, Mar 24, 2017 at 9:42 AM Sean Heber <sean at fifthace.com> wrote:
> This line of thought seems worth some consideration - why require a mental
> mapping from the meaning of “public” to what it *really* is when it could
> just say what it means? Although I admit that coming up with decent words
> or nice phrasings might be harder than it seems. :)
> > On Mar 24, 2017, at 6:12 AM, Vinnie Hesener via swift-evolution <
> swift-evolution at swift.org> wrote:
> > I like the idea of changing some reserved words. Aren't 'private',
> 'friend, 'public', 'internal', etc just metaphors that were built on top of
> object encapsulation (another metaphor)? I think we're starting to see the
> limits of stretching metaphoric syntax.
> > Why can't we just start naming access modifiers literally: a location in
> the code that they apply to. Examples such as "scope" or
> "insidethecurlybraces" or "file" or "module" or "submodule" or "codebase".
> Any of these or other synonyms would be much more Swifty in my opinion.
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution