[swift-evolution] Idea: Public Access Modifier Respected in Type Definition

[omochi.metaru]

I am grad if it is accepted.

I have two reasons.

(1)
I just recently confused visibility rule of extension which is different
from class/struct.

(2)
I often write many classes in only one application target in project first.
After code base grow, I often make new Framework target and move some
classes into this for organizing dependency and improving modularity.
At that time I need to write may `public` for classes and each func and
vars.
This is boring work.
If I need to write `public` only once for each classes, It is very
convenient.

--
omochimetaru

2017年9月29日(金) 10:05 Jonathan Hull via swift-evolution <
swift-evolution at swift.org>:

> I should also mention that this is from a class of error where it becomes
> more likely with expertise.  Thus, the more you do it, and get used to
> doing it, the more your brain will automate the task.  You see this type of
> thing pretty often with nurses, for example.
>
> For anyone who would like a better understanding of the science behind
> designing to prevent errors, I recommend the book *“Human Error” *by*
> James Reason*.
>
> Also *"The Design of Everyday Things" *by* Don Norman* has a pretty good
> chapter on the basics, and is much more accessible.
>
> I really like that Swift attempts to do this!  The use of forcing
> functions around optionals, for example, is brilliant.  It is just that we
> are applying solutions rather haphazardly (without matching them to the
> underlying cause of error), and I think we can do better.  That we are even
> considering these things is huge!  I am just saying that there is an entire
> body of scientific research we can use to effectively accomplish this goal
> (and avoid known pitfalls)…  we don’t have to reinvent the wheel.
>
> Thanks,
> Jon
>
>
> On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> +1000
>
> This is the way it always should have worked… and it is the way my brain
> still expects it to work.  All of the extraneous “Public”s clutter the code
> and make it much more difficult to read.  Without it, the relatively few
> properties marked Internal or Private stand out.
>
> I know there is the argument about making people think about whether they
> want to expose each item… but it doesn’t work that way.  Once you assign
> someone a rote task (assigning Public to most of the things), you lose the
> effect of having them think.  From a cognitive psychology lens, when you
> give the brain a number of decisions to make in a row that are very
> similar, it will naturally make that task more efficient by automating as
> much of it as possible (i.e. thinking about it less).  Mistakes become much
> more likely as a result.
>
> Tl;dr:  Despite the* myth*/intention that the current setup makes you*
> think about the problem more,* it actually does the* opposite* and leads
> to an *increased risk of error*.
>
> Thanks,
> Jon
>
>
> On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> When declaring a public class or struct the properties still default to
> internal.
> ```
> public final class NewType {
> /// This property defaults to internal.
> var property: Any?
> }
> ```
>
> This is not the same for a public extension on the type, where then the
> access modifier is respected for any function or calculated property within
> the extension.
> ```
> public extension NewType {
> /// This function inherits the public modifier.
> func function() {
> }
> }
> ```
>
> I dislike this inconsistency, and I frequently find that when using my
> dynamic frameworks my code will not compile, and it will be due to my
> accidentally writing a public struct but not declaring the properties
> public.
>
> I believe in the idea that explicitly stating the access modifier leads to
> more legible code, but in my opinion it can be overdone, and I much prefer
> to explicitly state my intentions in the modifier on the definition or
> extension. For example:
>
> ```
> public struct Coordinate {
> /// Should default to public.
> let latitude: Double
> /// Should default to public.
> let longitude: Double
> /// Should default to public
> init?(latitude: Double, longitude: Double) {
> guard validate(latitude: latitude, longitude: longitude) else { return nil
> }
> …
> }
> }
> internal extension Coordinate {
> /// Convenience initialiser to me used internally within the module.
> init(coordinate: CLLocationCoordinate2D) {
> …
> }
> }
> private extension Coordinate {
> /// Private validation of the coordinate.
> func validate(latitude: Double, longitude: Double) -> Bool {
> …
> }
> }
> ```
>
> This is legible and intuitive. The current behaviour is not.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170929/2bf63332/attachment.html>