Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 31 October 2017 at 02:29, Adam Kemp  wrote:

>
> No, grep would be sufficient as well. The issue is still which files to
> grep in the first place. Everything else comes after that. If you manually
> read files looking for usages of an API you’re changing then I feel sorry
> for you. You’re doing things the hard way.
>
>
so you've used grep to search for "foo" in all files of the module (in case
of "internal func foo") and grep returned 50 files.

in case of "classprivate func foo" that would be, say, 10 files. or even 50
files - doesn't matter.

what matters is the actual number of hits of "foo" to review, in the former
case it would be, say "50 files * 10 hits in each" in the latter - "50
files with one hit in each". and in reality even "10 files with one hit in
each". thus the search set to review is much much smaller.

I’m not going to go back and forth on this any longer. We’re going in
> circles. We just don’t agree, and this doesn’t appear to be going anywhere.
>

i agree to disagree.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 5:36 PM, Noah Desch  wrote:
> 
> If I’m concerned with how much work I’ll have to do, no that’s not the key. 
> The key is how many files do I have to read myself (only those containing a 
> subclass or extension of my base class).

Why would you read any file before searching for usages and figuring out which 
files use that API? And the scope of that search is defined by the access 
level. 

> You seem to be conflating a near instantaneous search in an IDE

No, grep would be sufficient as well. The issue is still which files to grep in 
the first place. Everything else comes after that. If you manually read files 
looking for usages of an API you’re changing then I feel sorry for you. You’re 
doing things the hard way. 


> There doesn’t need to be anything in the language, I just need to have a 
> defined coding convention that contributors follow. As someone else said 
> upthread you have to be able to trust your fellow developers.

If you trust your fellow developers then you don’t need a new access scope. Use 
internal or public. 

I’m not going to go back and forth on this any longer. We’re going in circles. 
We just don’t agree, and this doesn’t appear to be going anywhere. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Xiaodi Wu via swift-evolution]

This idea has been discussed before and deemed inconsistent with Swift's
design for access levels. Any further access levels are pretty clearly out
of scope for Swift 5. I'll refer you to the list of focus areas here:

https://github.com/apple/swift-evolution


On Mon, Oct 30, 2017 at 20:30 Mike Kluev via swift-evolution <
swift-evolution@swift.org> wrote:

> On 31 October 2017 at 00:36, Noah Desch  wrote:
>
>>
>>
>> > On Oct 30, 2017, at 6:38 PM, Adam Kemp via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >
>> >> On Oct 30, 2017, at 2:23 PM, Mike Kluev  wrote:
>> >>
>> >> On 30 October 2017 at 19:49, Adam Kemp  wrote:
>> >>
>> >> How do you know there’s not an extension in this file without looking?
>> If you don’t know then you have to check. That puts it in the same bucket
>> as internal or public. The set of files you have to search through for
>> usages is the same.
>> >>
>> >>
>> >> I'd just search for "extension SomeClass", Xcode search result window
>> will list all files that have it.
>> >> or I will list all the users of "foo" if that's the one I am changing.
>> >
>> > When you do that search, which files do you include in the search?
>> That’s the key.
>>
>>
>> If I’m concerned with how much work I’ll have to do, no that’s not the
>> key. The key is how many files do I have to read myself (only those
>> containing a subclass or extension of my base class). You seem to be
>> conflating a near instantaneous search in an IDE with manually evaluating a
>> change’s impact to other source files in the module. “Classprivate" makes
>> significantly fewer files that I have to manually review compared to
>> “internal”.
>
>
> exactly. significantly fewer files or fragments of files - significantly
> fewer entries in the search results in other words.
>
> when in a pub:
>
> public / internal:
>   - may i have a pint of lager please? - sure, here you are
>
> classprivate / protected:
>   - may i have a pint of ale please?
>   - sure. are you a member of our club? we serve ale to members only
>   - errr. no. can i become a member?
>   - yes, it is free. just take a seat over there and fill this form
> first, once done i will bring you your ale.
>   - errr, thanks. may i have lager instead please?
>
> private:
>   - may i have a pint of potter please?
>   - sure. are you a member of our club?
>   - yes, i just filed the form, here it is.
>- are you aware that we serve potter only in that "core members
> only" private room?
>   - errr, no, how do i get there?
>   - ah, no sir, it is impossible. you would know if you can go there.
> it is by invitation only system.
>   - damn!! lager!
>
> i am dead sure they will serve much less ale than lager, don't you.
>
> Mike
>
> ___
> 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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 31 October 2017 at 00:36, Noah Desch  wrote:

>
>
> > On Oct 30, 2017, at 6:38 PM, Adam Kemp via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> >> On Oct 30, 2017, at 2:23 PM, Mike Kluev  wrote:
> >>
> >> On 30 October 2017 at 19:49, Adam Kemp  wrote:
> >>
> >> How do you know there’s not an extension in this file without looking?
> If you don’t know then you have to check. That puts it in the same bucket
> as internal or public. The set of files you have to search through for
> usages is the same.
> >>
> >>
> >> I'd just search for "extension SomeClass", Xcode search result window
> will list all files that have it.
> >> or I will list all the users of "foo" if that's the one I am changing.
> >
> > When you do that search, which files do you include in the search?
> That’s the key.
>
>
> If I’m concerned with how much work I’ll have to do, no that’s not the
> key. The key is how many files do I have to read myself (only those
> containing a subclass or extension of my base class). You seem to be
> conflating a near instantaneous search in an IDE with manually evaluating a
> change’s impact to other source files in the module. “Classprivate" makes
> significantly fewer files that I have to manually review compared to
> “internal”.


exactly. significantly fewer files or fragments of files - significantly
fewer entries in the search results in other words.

when in a pub:

public / internal:
  - may i have a pint of lager please? - sure, here you are

classprivate / protected:
  - may i have a pint of ale please?
  - sure. are you a member of our club? we serve ale to members only
  - errr. no. can i become a member?
  - yes, it is free. just take a seat over there and fill this form
first, once done i will bring you your ale.
  - errr, thanks. may i have lager instead please?

private:
  - may i have a pint of potter please?
  - sure. are you a member of our club?
  - yes, i just filed the form, here it is.
   - are you aware that we serve potter only in that "core members
only" private room?
  - errr, no, how do i get there?
  - ah, no sir, it is impossible. you would know if you can go there.
it is by invitation only system.
  - damn!! lager!

i am dead sure they will serve much less ale than lager, don't you.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Noah Desch via swift-evolution]

> On Oct 30, 2017, at 6:38 PM, Adam Kemp via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 30, 2017, at 2:23 PM, Mike Kluev  wrote:
>> 
>> On 30 October 2017 at 19:49, Adam Kemp  wrote:
>>  
>> How do you know there’s not an extension in this file without looking? If 
>> you don’t know then you have to check. That puts it in the same bucket as 
>> internal or public. The set of files you have to search through for usages 
>> is the same.
>> 
>> 
>> I'd just search for "extension SomeClass", Xcode search result window will 
>> list all files that have it.
>> or I will list all the users of "foo" if that's the one I am changing.
> 
> When you do that search, which files do you include in the search? That’s the 
> key.


If I’m concerned with how much work I’ll have to do, no that’s not the key. The 
key is how many files do I have to read myself (only those containing a 
subclass or extension of my base class). You seem to be conflating a near 
instantaneous search in an IDE with manually evaluating a change’s impact to 
other source files in the module. “Classprivate" makes significantly fewer 
files that I have to manually review compared to “internal”.



>> the good guideline from Obj-C was (and still is) using 
>> "SomeClass+ExtensionName" file naming convention that also helps.
> 
> That’s not sufficient because there’s nothing in the language that would 
> force people to follow this convention, and you can have extensions in any 
> file for any class.


There doesn’t need to be anything in the language, I just need to have a 
defined coding convention that contributors follow. As someone else said 
upthread you have to be able to trust your fellow developers.

-Noah
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[James Froggatt via swift-evolution]

 Begin Message  
Group: gmane.comp.lang.swift.evolution 
MsgID:  

if they really want it they will make an extension (which would
be a legitimate use of it) if they don't need it really - they will find
another way without making an extension. the (reasonable) expectation is
that such a "classprivate" will reduce the number of instances where "foo"
is used thus reducing the "working set" of instances i have to review when
making a change to it.

- End Message - 

This first point is the key issue. Any internal-scope usage can be trivially 
converted into an extension, so the ‘access control’ here is simply making it 
less discoverable. The ‘pure’ access levels of fileprivate and internal truly 
CANNOT be worked around in this way without access to the original file/module, 
which may be withheld.

That said, there is precedent for this kind of modifier already - it seems to 
me the current ‘private’ access level is to fileprivate what this is to 
internal. With private, you still have to search the whole file for extensions; 
the benefit is having autocomplete be less cluttered elsewhere in the file, and 
the hint to the developer to consider usage more carefully. From that 
perspective, where private is a scoped fileprivate, a scoped version of 
internal makes a good deal of sense. For what it's worth, I'd consider 
typeprivate a good name for this.

However the introduction of the new 'private’ was highly controversial in 
itself, even with the advantage it had over this proposal by being a solution 
for access control in Playgrounds. While I respect your support for this, I 
don't thing this proposal will get very far given the circumstances.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 4:31 PM, Mike Kluev  wrote:
> 
> On 30 October 2017 at 23:14, Adam Kemp  > wrote:
> 
> > On Oct 30, 2017, at 4:10 PM, Mike Kluev  > > wrote:
> >
> > "classprivate" helps to resolve this problem. if it is marked so developer 
> > will at least think twice before making an extension to use it
> 
> Why would they think twice, though? You’ve told them extensions can use it, 
> and they’ve written an extension to use it. What did they do wrong? I don’t 
> think the rules are nearly as clear as for protected.
> 
> this is obvious: when they are writing a method in their own class and try to 
> call: some.foo() it will give them and access level error (or even before 
> that the autocomplete will not work as an early hint),


This is not the situation I was asking about. I was asking why would someone in 
a random file who is about to write an extension think twice about using this 
method? He wouldn’t, because you’ve told him using that method (in an 
extension) is fine. But you may not know about or approve of that code he’s 
writing, and you may later make a change that breaks that usage. The access 
level has not improved your ability to reason about what might break.

The root of our disagreement is in how we view extensions. There’s no real 
difference between code in an extension and code in some other 
class/struct/whatever. It’s still a client of the original class, not part of 
that class itself. It’s a separate thing. You’re thinking of an extension as 
part of the original class, but it’s not. Since anyone can write an extension, 
even in other modules, it has to be thought of as a separate thing, an external 
client. The author of the class has no control over or knowledge of extensions 
on that class, and the only way to be able to reason about whether a change to 
an API is safe is to use access levels that tell the author which files might 
be able to use that API.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 23:14, Adam Kemp  wrote:

>
> > On Oct 30, 2017, at 4:10 PM, Mike Kluev  wrote:
> >
> > "classprivate" helps to resolve this problem. if it is marked so
> developer will at least think twice before making an extension to use it
>
> Why would they think twice, though? You’ve told them extensions can use
> it, and they’ve written an extension to use it. What did they do wrong? I
> don’t think the rules are nearly as clear as for protected.
>

this is obvious: when they are writing a method in their own class and try
to call: some.foo() it will give them and access level error (or even
before that the autocomplete will not work as an early hint), they will
reveal foo's definition, see "classprivate" in there and at that very point
take a pause, think and make a conscious decision whether they really want
it or not. if they really want it they will make an extension (which would
be a legitimate use of it) if they don't need it really - they will find
another way without making an extension. the (reasonable) expectation is
that such a "classprivate" will reduce the number of instances where "foo"
is used thus reducing the "working set" of instances i have to review when
making a change to it.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 4:10 PM, Mike Kluev  wrote:
> 
> "classprivate" helps to resolve this problem. if it is marked so developer 
> will at least think twice before making an extension to use it

Why would they think twice, though? You’ve told them extensions can use it, and 
they’ve written an extension to use it. What did they do wrong? I don’t think 
the rules are nearly as clear as for protected.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 22:38, Adam Kemp  wrote:

>
> “specialprivate", by allowing any extension to access the API, would imply
> the same set of files as either internal or public. You can’t know ahead of
> time whether some random file in your module might make an extension that
> access that API so you have to search all files within that module. You
> would perform the search exactly the same way. It doesn’t help you as a
> library maintainer. You’re not going to save work by making something
> “specialprivate” instead of internal. Worst case is you actually convince
> yourself that you don’t have to search the whole module, and then you break
> something because of that misunderstanding. That’s why internal is better.
> It avoids obfuscating the actual implications of that access level.
>

i still see a value in it:

- i do a search for, say, "foo" (all files in the module)
- let's say 50 usages will be legitimate use from within the class or it's
extensions
- another 10 usages will be wrong, that mistakenly treated it's "internal /
public" as a permission to use.
- i found those instances which shall not be there (that mistakenly use it
as it is effectively public)
- i ask developers who did it to not do this again / fix the problem / etc
- some time later i can do the same mistake myself again or other people
will do the same mistake again and the process repeats.
- compiler doesn't help as it can't check
- it becomes a manual and error prone process

"classprivate" helps to resolve this problem. if it is marked so developer
will at least think twice before making an extension to use it - similar to
how marking a method "protected" stops people from using it without
subclassing - (and creating an extension for the sole purpose of using
despite of it's access level would qualify as "cheating", which we can
leave aside). with "internal / public" there is nothing stopping them for a
second and they can use it without even realising they are doing something
wrong. all IMHO.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 2:23 PM, Mike Kluev  wrote:
> 
> On 30 October 2017 at 19:49, Adam Kemp  > wrote:
>  
> How do you know there’s not an extension in this file without looking? If you 
> don’t know then you have to check. That puts it in the same bucket as 
> internal or public. The set of files you have to search through for usages is 
> the same.
> 
> 
> I'd just search for "extension SomeClass", Xcode search result window will 
> list all files that have it.
> or I will list all the users of "foo" if that's the one I am changing.

When you do that search, which files do you include in the search? That’s the 
key.

> 
> the good guideline from Obj-C was (and still is) using 
> "SomeClass+ExtensionName" file naming convention that also helps.

That’s not sufficient because there’s nothing in the language that would force 
people to follow this convention, and you can have extensions in any file for 
any class.

The point I’m trying to make, again, is that the set of files that you would 
have to search through is the same. Once you know the set of files that need to 
be searched you can just search for actual usages of the API you’re changing 
(the method or property or whatever). The important thing is to know which 
files need to be searched in the first place. That’s what access level really 
controls.

Each access level implies a unique set of files that have to be searched. 
Public = all files in all clients. Internal = all files in this module. File 
private = just one file. Private = just one part of one file.

“specialprivate", by allowing any extension to access the API, would imply the 
same set of files as either internal or public. You can’t know ahead of time 
whether some random file in your module might make an extension that access 
that API so you have to search all files within that module. You would perform 
the search exactly the same way. It doesn’t help you as a library maintainer. 
You’re not going to save work by making something “specialprivate” instead of 
internal. Worst case is you actually convince yourself that you don’t have to 
search the whole module, and then you break something because of that 
misunderstanding. That’s why internal is better. It avoids obfuscating the 
actual implications of that access level.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 19:49, Adam Kemp  wrote:


> How do you know there’s not an extension in this file without looking? If
> you don’t know then you have to check. That puts it in the same bucket as
> internal or public. The set of files you have to search through for usages
> is the same.
>
>
I'd just search for "extension SomeClass", Xcode search result window will
list all files that have it.
or I will list all the users of "foo" if that's the one I am changing.

the good guideline from Obj-C was (and still is) using
"SomeClass+ExtensionName" file naming convention that also helps.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 11:19 AM, Mike Kluev  wrote:
> 
> 
> On 30 October 2017 at 18:07, Adam Kemp  > wrote:
>> On Oct 30, 2017, at 10:57 AM, Mike Kluev > > wrote:
>> 
>> 
>> the new bucket would be "class and all of its extensions be them in the same 
>> file or in different files”.
> 
> That’s not a new bucket. It is equivalent to either internal or public, 
> depending on whether you want to extend this beyond the module boundary. The 
> set of code you would have to audit is the same.
> 
> it is different, see below:
> 
> === file: Some.swift
> 
> class Some {
>internal func foo() {
>   bar()
>}
>classprivate func better() {
>   good()
> }
> }
> 
> === file: Some+Bar.swift
> 
> extension Some {
>   internal func bar() {
>   foo()
>   }
>   classprivate func good() {
>   better()
>}
> }
> 
> === any other file (same module)
> 
> class Other {
> func x() {
> let some = Some()
> 
> some.foo() // ** UNWANTED!!
> 
> some.better() // error.  ** WANTED!
> }
> }

How do you know there’s not an extension in this file without looking? If you 
don’t know then you have to check. That puts it in the same bucket as internal 
or public. The set of files you have to search through for usages is the same.

> 
> I do not want to audit the class Other when I make a change to "foo" or 
> "bar", which are essentially "private" and only made "internal" because of 
> the language limitation in regards to "private" vs "multi-file class" issue.
> 
> 
> What does marking a method as “specialprivate” (my made up name for this new 
> access level) tell clients about who can use it or how it can be used?
> 
> it tells them: "you can't use this, unless you are writing an extension to 
> this class or making changes to this class itself”

There’s nothing special about an extension. Anyone can write an extension to 
any class. You shouldn’t need any special privileges to enable people to write 
extensions. You’re not gaining anything by introducing an interface only usable 
by extensions.

> 
> Mike
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 18:07, Adam Kemp  wrote:

> On Oct 30, 2017, at 10:57 AM, Mike Kluev  wrote:
>
>
> the new bucket would be "class and all of its extensions be them in the
> same file or in different files”.
>
>
> That’s not a new bucket. It is equivalent to either internal or public,
> depending on whether you want to extend this beyond the module boundary.
> The set of code you would have to audit is the same.
>

it is different, see below:

=== file: Some.swift

class Some {
   internal func foo() {
  bar()
   }
   classprivate func better() {
  good()
}
}

=== file: Some+Bar.swift

extension Some {
  internal func bar() {
  foo()
  }
  classprivate func good() {
  better()
   }
}

=== any other file (same module)

class Other {
func x() {
let some = Some()

some.foo() // ** UNWANTED!!

some.better() // error.  ** WANTED!
}
}

I do not want to audit the class Other when I make a change to "foo" or
"bar", which are essentially "private" and only made "internal" because of
the language limitation in regards to "private" vs "multi-file class" issue.


> What does marking a method as “specialprivate” (my made up name for this
> new access level) tell clients about who can use it or how it can be used?
>

it tells them: "you can't use this, unless you are writing an extension to
this class or making changes to this class itself"

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 10:57 AM, Mike Kluev  wrote:
> 
> On 30 October 2017 at 17:22, Adam Kemp  > wrote:
> 
> The goal isn’t to entirely avoid having to audit any code while making a 
> change. The goal is to allow you to reason about which code you would have to 
> audit. A new access level should lead to a new bucket of code that needs to 
> be audited, but none of the proposals here would do that. They’re all 
> equivalent to existing access levels.
> 
> the new bucket would be "class and all of its extensions be them in the same 
> file or in different files”.

That’s not a new bucket. It is equivalent to either internal or public, 
depending on whether you want to extend this beyond the module boundary. The 
set of code you would have to audit is the same.

> 
> back to your example with the locked door and the keys on the doorstep, i can 
> violate "protected" in C++:
> 
> developer 1:
> class Base { protected void foo(); }
> 
> developer 2:
> class Derived: Base { public void not_so_protected_foo() { foo() }
> 
> but that doesn't mean that "protected" in C++ shall be ditched!

In terms of reasoning about code that might break, protected is equivalent to 
public. The only advantage to protected over public is that it tells clients 
how to properly use it.

What does marking a method as “specialprivate” (my made up name for this new 
access level) tell clients about who can use it or how it can be used?

> 
> this is similar to what you said before about writing an extension and 
> exposing the private functionality as public violating protection.
> 
> Mike
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 17:22, Adam Kemp  wrote:

>
> The goal isn’t to entirely avoid having to audit any code while making a
> change. The goal is to allow you to reason about which code you would have
> to audit. A new access level should lead to a new bucket of code that needs
> to be audited, but none of the proposals here would do that. They’re all
> equivalent to existing access levels.
>

the new bucket would be "class and all of its extensions be them in the
same file or in different files".

back to your example with the locked door and the keys on the doorstep, i
can violate "protected" in C++:

developer 1:
class Base { protected void foo(); }

developer 2:
class Derived: Base { public void not_so_protected_foo() { foo() }

but that doesn't mean that "protected" in C++ shall be ditched!

this is similar to what you said before about writing an extension and
exposing the private functionality as public violating protection.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 10:10 AM, Mike Kluev  wrote:
> 
> On 30 October 2017 at 16:34, Adam Kemp  > wrote:
> 
> I didn’t mean “no, you can’t do that”. You can if you want to. What I meant 
> was “no, I’m not suggesting that you should do that”. I don’t think it’s 
> necessary.
> 
> as you said before the benefit of keeping private things private is 
> minimizing the amount of code that can break once you change a variable. if 
> it's "internal" - the whole module must be checked. if it is "internal" 
> rather than "private”:
> it is done because otherwise i'd have to keep the (big) class in a single file

The goal isn’t to entirely avoid having to audit any code while making a 
change. The goal is to allow you to reason about which code you would have to 
audit. A new access level should lead to a new bucket of code that needs to be 
audited, but none of the proposals here would do that. They’re all equivalent 
to existing access levels.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

sorry, hit "Sent" too early

On 30 October 2017 at 16:34, Adam Kemp  wrote:

>
> I didn’t mean “no, you can’t do that”. You can if you want to. What I
> meant was “no, I’m not suggesting that you should do that”. I don’t think
> it’s necessary.
>

as you said before the benefit of keeping private things private is
minimizing the amount of code that can break once you change a variable. if
it's "internal" - the whole module must be checked. if it is "internal"
rather than "private":

- it is done because otherwise i'd have to keep the (big) class in a single
file
- shows the limitation in the language in regards to one-file-class vs
multi-file-class
- forces me to use one module per file if I want to mimic the "private"
keyword as close as possible
- or forces me to keep my class in a single file.

> Which other language has an access level like the one being proposed?

i am not aware of such a language. C++'s "private" comes close as it can be
used in multiple files but then C++ doesn't have extensions. C++
"protected" comes close for something I can use in subclasses.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 16:34, Adam Kemp  wrote:

>
> I didn’t mean “no, you can’t do that”. You can if you want to. What I
> meant was “no, I’m not suggesting that you should do that”. I don’t think
> it’s necessary.
>

as you said before the benefit of keeping private things private is
minimizing the amount of code that can break once you change a variable. if
it's "internal" - the whole module must be checked. if it is "internal"
rather than "private":
it is done because otherwise i'd have to keep the (big) class in a single
file



> Which other language has an access level like the one being proposed?
>
>
> this:
>
> SingleFileClass1.swift // with bunch of "privates" inside
>
> SingleFileClass2.swift // with bunch of "privates" inside
>
> SingleFileClass3.swift // with bunch of "privates" inside
>
> is equivalent to this:
>
> Module solely for Class1
>Class1.swift // with bunch of "internals inside
>Class1+Extension.swift // with bunch of "internals" inside
>
> Module solely for Class2
>Class2.swift // with bunch of "internals" inside
>Class2+Extension.swift // with bunch of "internals" inside
>
> Module solely for Class3
>Class3.swift  // with bunch of "internals" inside
>Class3+Extension.swift // with bunch of "internals" inside
>
>
> still "no" ?
>
> i mean, it's fine (although a bit odd) that a mere change from a
> single-file to a multi-file class leads to such drastic consequences.
> different to what i saw before. but I can adapt of course.
>
> Either way the answer is basically the same: don’t obfuscate the effective
>> access level and pretend you’re being strict when you’re really not. It’s
>> like putting a lock on the door with the key hanging from the doorknob. You
>> may as well just keep it unlocked.
>>
>>
> nice analogy :-)
>
> Mike
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 30, 2017, at 5:34 AM, Mike Kluev  wrote:
> 
> On 30 October 2017 at 07:30, Adam Kemp  > wrote:
> 
> No. There are two reasonable options:
> 
> 1. Make it public. If it’s needed outside the module then this is an accurate 
> description of its access level. 
> 
> 2. Make it internal and accept that any code in the same module can access 
> it. Again, that is effectively what your proposed scope allows anyway so 
> internal is an accurate description of its actual access level. Call it what 
> it is.
> 
> 
> Adam, i fail to see why you say "No" to "one module per class approach" if 
> the goal is to make the individual multi-file classes as isolated as possible 
> (i.e. not see each other "internal" stuff). which (this goal) is considered 
> the "way to go" approach in other languages and the "default" behaviour.

I didn’t mean “no, you can’t do that”. You can if you want to. What I meant was 
“no, I’m not suggesting that you should do that”. I don’t think it’s necessary.

Which other language has an access level like the one being proposed?

> 
> this:
> 
> SingleFileClass1.swift // with bunch of "privates" inside
> 
> SingleFileClass2.swift // with bunch of "privates" inside
> 
> SingleFileClass3.swift // with bunch of "privates" inside
> 
> is equivalent to this:
> 
> Module solely for Class1
>Class1.swift // with bunch of "internals inside
>Class1+Extension.swift // with bunch of "internals" inside
>
> Module solely for Class2
>Class2.swift // with bunch of "internals" inside
>Class2+Extension.swift // with bunch of "internals" inside  
> 
> Module solely for Class3
>Class3.swift  // with bunch of "internals" inside
>Class3+Extension.swift // with bunch of "internals" inside
>
> 
> still "no" ?
> 
> i mean, it's fine (although a bit odd) that a mere change from a single-file 
> to a multi-file class leads to such drastic consequences. different to what i 
> saw before. but I can adapt of course.
> 
> Either way the answer is basically the same: don’t obfuscate the effective 
> access level and pretend you’re being strict when you’re really not. It’s 
> like putting a lock on the door with the key hanging from the doorknob. You 
> may as well just keep it unlocked. 
> 
> 
> nice analogy :-)
> 
> Mike
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[C. Keith Ray via swift-evolution]

Access levels are not a security mechanism. You have to trust your (fellow) 
programmers. Lots of good software has been created in Smalltalk and other 
languages without "private" access levels.

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Oct 30, 2017, at 5:34 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
>> On 30 October 2017 at 07:30, Adam Kemp  wrote:
>> 
>> No. There are two reasonable options:
>> 
>> 1. Make it public. If it’s needed outside the module then this is an 
>> accurate description of its access level. 
>> 
>> 2. Make it internal and accept that any code in the same module can access 
>> it. Again, that is effectively what your proposed scope allows anyway so 
>> internal is an accurate description of its actual access level. Call it what 
>> it is.
>> 
> 
> Adam, i fail to see why you say "No" to "one module per class approach" if 
> the goal is to make the individual multi-file classes as isolated as possible 
> (i.e. not see each other "internal" stuff). which (this goal) is considered 
> the "way to go" approach in other languages and the "default" behaviour.
> 
> this:
> 
> SingleFileClass1.swift // with bunch of "privates" inside
> 
> SingleFileClass2.swift // with bunch of "privates" inside
> 
> SingleFileClass3.swift // with bunch of "privates" inside
> 
> is equivalent to this:
> 
> Module solely for Class1
>Class1.swift // with bunch of "internals inside
>Class1+Extension.swift // with bunch of "internals" inside
>
> Module solely for Class2
>Class2.swift // with bunch of "internals" inside
>Class2+Extension.swift // with bunch of "internals" inside  
> 
> Module solely for Class3
>Class3.swift  // with bunch of "internals" inside
>Class3+Extension.swift // with bunch of "internals" inside
>
> 
> still "no" ?
> 
> i mean, it's fine (although a bit odd) that a mere change from a single-file 
> to a multi-file class leads to such drastic consequences. different to what i 
> saw before. but I can adapt of course.
> 
>> Either way the answer is basically the same: don’t obfuscate the effective 
>> access level and pretend you’re being strict when you’re really not. It’s 
>> like putting a lock on the door with the key hanging from the doorknob. You 
>> may as well just keep it unlocked. 
>> 
> 
> nice analogy :-)
> 
> Mike
> 
> ___
> 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

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 07:30, Adam Kemp  wrote:

>
> No. There are two reasonable options:
>
> 1. Make it public. If it’s needed outside the module then this is an
> accurate description of its access level.
>
> 2. Make it internal and accept that any code in the same module can access
> it. Again, that is effectively what your proposed scope allows anyway so
> internal is an accurate description of its actual access level. Call it
> what it is.
>
>
Adam, i fail to see why you say "No" to "one module per class approach" if
the goal is to make the individual multi-file classes as isolated as
possible (i.e. not see each other "internal" stuff). which (this goal) is
considered the "way to go" approach in other languages and the "default"
behaviour.

this:

SingleFileClass1.swift // with bunch of "privates" inside

SingleFileClass2.swift // with bunch of "privates" inside

SingleFileClass3.swift // with bunch of "privates" inside

is equivalent to this:

Module solely for Class1
   Class1.swift // with bunch of "internals inside
   Class1+Extension.swift // with bunch of "internals" inside

Module solely for Class2
   Class2.swift // with bunch of "internals" inside
   Class2+Extension.swift // with bunch of "internals" inside

Module solely for Class3
   Class3.swift  // with bunch of "internals" inside
   Class3+Extension.swift // with bunch of "internals" inside


still "no" ?

i mean, it's fine (although a bit odd) that a mere change from a
single-file to a multi-file class leads to such drastic consequences.
different to what i saw before. but I can adapt of course.

Either way the answer is basically the same: don’t obfuscate the effective
> access level and pretend you’re being strict when you’re really not. It’s
> like putting a lock on the door with the key hanging from the doorknob. You
> may as well just keep it unlocked.
>
>
nice analogy :-)

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 29, 2017, at 9:22 PM, Mike Kluev  wrote:
> 
> Module1
> 
> Class A in it's own file
> extension A in it's own file
> 
> Class B in it's own file
> extension B in it's own file
> 
> Class C in it's own file
> extension C in it's own file
> 
> Module 2
> 
> 
> obviously i do not want guys from team B and C accessing anything "team A 
> private".

Then your proposal cannot help you accomplish that goal. If any extension of 
class A can access a method then someone writing code in the same file as B or 
C can write an extension of class A and expose it to other code in the same 
file as B or C. That means when you are making a change to that method you have 
to assume that there may be code relying on it, and you have to audit that code.

It’s worse than that, though. If that method is accessible even to extensions 
in other modules then that means any external client of this module could also 
rely on that behavior, and that means you cannot safely change it at all. You 
have effectively made it public. You have lost all control. It is no longer 
encapsulated at all.

When you choose an access level you are deciding which code you are allowing to 
depend on it, and thus which code you will have to fix if you change it. If a 
change might break any client of the whole module then it’s public. You’re only 
fooling yourself if you call it something else. 

> 
> is my understanding of your words then correct that you suggest to have this:
> 
> Module1
> 
> Class A in it's own file
> extension A in it's own file
> 
> Module2
> 
> Class B in it's own file
> extension B in it's own file
> 
> Module3
> 
> Class C in it's own file
> extension C in it's own file
> 
> Module 4
> 

No. There are two reasonable options:

1. Make it public. If it’s needed outside the module then this is an accurate 
description of its access level. 

2. Make it internal and accept that any code in the same module can access it. 
Again, that is effectively what your proposed scope allows anyway so internal 
is an accurate description of its actual access level. Call it what it is.

Either way the answer is basically the same: don’t obfuscate the effective 
access level and pretend you’re being strict when you’re really not. It’s like 
putting a lock on the door with the key hanging from the doorknob. You may as 
well just keep it unlocked. 

> 
> 
> 
>> On 30 October 2017 at 04:04, Adam Kemp  wrote:
>> Access levels exist for encapsulation. They don’t mean anything unless they 
>> actually allow you to reason about which code can break if you make a 
>> change. Given that, here is how each existing access level is useful:
>> 
>> Public means a change could break any code. 
>> 
>> Internal means only code in the module can break so you can audit all 
>> usages in that module and fix as needed.
>> 
>> File private means only code within the file can break so you only have 
>> to audit the one file.
>> 
>> Private means only code within the class or extensions in the same file 
>> can break so you only have to audit part of that one file.
>> 
>> What would a proposed new access level mean for which code has to be audited 
>> when making a change?
>> 
>> If any extension can access something even across modules then that 
>> makes it the same as public. You can’t make any change without risking 
>> breaking a client.
>> 
>> If any extension can access something within the same module then it’s 
>> the same as internal. You have to audit the whole module.
>> 
>> If your new access level doesn’t make a new bucket for what code to audit 
>> then it’s not adding any value.
>> 
>>> On Oct 29, 2017, at 8:40 PM, Mike Kluev  wrote:
>>> 
 On 30 October 2017 at 02:54, Adam Kemp  wrote:
 
 That was my original point. This is what internal does. We don’t need any 
 new access levels for extensions. Internal solves these use cases. Code in 
 the same module can be maintained in lockstep so you can make things 
 internal as needed for extensions. Anything beyond that is effectively 
 indistinguishable from public so just call it that. 
 
>>> 
>>> if I have N big classes,  each split across M files to keep size 
>>> manageable, do I need to have N different modules if i want to achieve a 
>>> good separation between classes? (same level of protection that private 
>>> gives for a class that fits in a single file) i.e. one module per one class?
>>> 
>>> Mike
>>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

Module1

Class A in it's own file
extension A in it's own file

Class B in it's own file
extension B in it's own file

Class C in it's own file
extension C in it's own file

Module 2


obviously i do not want guys from team B and C accessing anything "team A
private".

is my understanding of your words then correct that you suggest to have
this:

Module1

Class A in it's own file
extension A in it's own file

Module2

Class B in it's own file
extension B in it's own file

Module3

Class C in it's own file
extension C in it's own file

Module 4




On 30 October 2017 at 04:04, Adam Kemp  wrote:

> Access levels exist for encapsulation. They don’t mean anything unless
> they actually allow you to reason about which code can break if you make a
> change. Given that, here is how each existing access level is useful:
>
> Public means a change could break any code.
>
> Internal means only code in the module can break so you can audit all
> usages in that module and fix as needed.
>
> File private means only code within the file can break so you only
> have to audit the one file.
>
> Private means only code within the class or extensions in the same
> file can break so you only have to audit part of that one file.
>
> What would a proposed new access level mean for which code has to be
> audited when making a change?
>
> If any extension can access something even across modules then that
> makes it the same as public. You can’t make any change without risking
> breaking a client.
>
> If any extension can access something within the same module then it’s
> the same as internal. You have to audit the whole module.
>
> If your new access level doesn’t make a new bucket for what code to audit
> then it’s not adding any value.
>
> On Oct 29, 2017, at 8:40 PM, Mike Kluev  wrote:
>
> On 30 October 2017 at 02:54, Adam Kemp  wrote:
>
>>
>> That was my original point. This is what internal does. We don’t need any
>> new access levels for extensions. Internal solves these use cases. Code in
>> the same module can be maintained in lockstep so you can make things
>> internal as needed for extensions. Anything beyond that is effectively
>> indistinguishable from public so just call it that.
>>
>>
> if I have N big classes,  each split across M files to keep size
> manageable, do I need to have N different modules if i want to achieve a
> good separation between classes? (same level of protection that private
> gives for a class that fits in a single file) i.e. one module per one class?
>
> Mike
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

Access levels exist for encapsulation. They don’t mean anything unless they 
actually allow you to reason about which code can break if you make a change. 
Given that, here is how each existing access level is useful:

Public means a change could break any code. 

Internal means only code in the module can break so you can audit all 
usages in that module and fix as needed.

File private means only code within the file can break so you only have to 
audit the one file.

Private means only code within the class or extensions in the same file can 
break so you only have to audit part of that one file.

What would a proposed new access level mean for which code has to be audited 
when making a change?

If any extension can access something even across modules then that makes 
it the same as public. You can’t make any change without risking breaking a 
client.

If any extension can access something within the same module then it’s the 
same as internal. You have to audit the whole module.

If your new access level doesn’t make a new bucket for what code to audit then 
it’s not adding any value.

> On Oct 29, 2017, at 8:40 PM, Mike Kluev  wrote:
> 
>> On 30 October 2017 at 02:54, Adam Kemp  wrote:
>> 
>> That was my original point. This is what internal does. We don’t need any 
>> new access levels for extensions. Internal solves these use cases. Code in 
>> the same module can be maintained in lockstep so you can make things 
>> internal as needed for extensions. Anything beyond that is effectively 
>> indistinguishable from public so just call it that. 
>> 
> 
> if I have N big classes,  each split across M files to keep size manageable, 
> do I need to have N different modules if i want to achieve a good separation 
> between classes? (same level of protection that private gives for a class 
> that fits in a single file) i.e. one module per one class?
> 
> Mike
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 30 October 2017 at 02:54, Adam Kemp  wrote:

>
> That was my original point. This is what internal does. We don’t need any
> new access levels for extensions. Internal solves these use cases. Code in
> the same module can be maintained in lockstep so you can make things
> internal as needed for extensions. Anything beyond that is effectively
> indistinguishable from public so just call it that.
>
>
if I have N big classes,  each split across M files to keep size
manageable, do I need to have N different modules if i want to achieve a
good separation between classes? (same level of protection that private
gives for a class that fits in a single file) i.e. one module per one class?

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

> On Oct 29, 2017, at 5:29 PM, Mike Kluev  wrote:
> 
>> On 29 October 2017 at 16:04, Adam Kemp  wrote:
>> Internal is the right choice here. If it gives too much access then you 
>> might consider pulling this code into a separate module.
>> 
>> If “private” gave access to every extension then any code outside your 
>> module could make a new extension and access that method. That would make it 
>> effectively public in that you wouldn’t have any ability to limit who can 
>> call it.
>> 
> 
> there are two very different use cases for which we use extensions.
> 
> 1) the extensions i use to split implementation of my own classes into 
> different parts and / or files. for the sake of this discussion let's call 
> this type of extensions a "continuation". 

Internal is sufficient for this use case. 

> 
> 2) the extensions that are used to extend other people classes or system 
> classes. this matches what we have now.

There’s no need for a new access level here. If it’s in the same module then 
you use internal. If it’s not then you shouldn’t be able to access anything 
other than public API. 

> 
> speaking of (1) the naïve newcomers from C++ land would consider these 
> continuations the same as splitting their C++ class implementation into 
> separate files. e.g. the expectation is having an ability to access "private" 
> members. if such a thing existed in swift at all it wouldn't be unimaginable 
> having an ability to add variables in these continuations the same way as in 
> the class itself. here  "protected" access level would be a reasonable 
> addition, and if we want to be totally nitpicky "protected" would be for 
> subclasses and some other keyword, say, "extensionprivate" or "domestic" for 
> continuations.

Protected is a different concept entirely.  I’m not sure what the reasoning was 
for leaving it out. Personally I do think protected is a useful access level so 
that you can clearly define API intended for subclasses. However, protected has 
nothing to do with extensions. It doesn’t solve that use case. 

> 
> an interesting challenge would be somehow prohibiting external people adding 
> continuations to your own classes :)

That was my original point. This is what internal does. We don’t need any new 
access levels for extensions. Internal solves these use cases. Code in the same 
module can be maintained in lockstep so you can make things internal as needed 
for extensions. Anything beyond that is effectively indistinguishable from 
public so just call it that. 

> 
> Mike
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

On 29 October 2017 at 16:04, Adam Kemp  wrote:

> Internal is the right choice here. If it gives too much access then you
> might consider pulling this code into a separate module.
>
> If “private” gave access to every extension then any code outside your
> module could make a new extension and access that method. That would make
> it effectively public in that you wouldn’t have any ability to limit who
> can call it.
>
>
there are two very different use cases for which we use extensions.

1) the extensions i use to split implementation of my own classes into
different parts and / or files. for the sake of this discussion let's call
this type of extensions a "continuation".

2) the extensions that are used to extend other people classes or system
classes. this matches what we have now.

speaking of (1) the naïve newcomers from C++ land would consider these
continuations the same as splitting their C++ class implementation into
separate files. e.g. the expectation is having an ability to access
"private" members. if such a thing existed in swift at all it wouldn't be
unimaginable having an ability to add variables in these continuations the
same way as in the class itself. here  "protected" access level would be a
reasonable addition, and if we want to be totally nitpicky "protected"
would be for subclasses and some other keyword, say, "extensionprivate" or
"domestic" for continuations.

an interesting challenge would be somehow prohibiting external people
adding continuations to your own classes :)

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Noah Desch via swift-evolution]

Even if separating code into modules was an effortless process “internal" would 
still not be the right access modifier because you would have to make a 
sub-module for every class in a class hierarchy which defined new “protected” 
members. So we would need some near-effortless process for creating modules, 
and sub-modules would also have to be introduced to the language before we 
approach the functionality of a “protected” scope. I get that organizing all 
access around modules is conceptually simple (and thus tempting) but in 
practice I think it would be a huge PITA. 


> On Oct 29, 2017, at 3:36 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> You’re not really missing an other access modifier here. I assume you’re 
> speaking about a macOS/iOS app, right? Therefore the thing you’re really 
> missing is a full integration of SPM in Xcode macOS/iOS projects and 
> submodules. Then, and only then `internal` would really seem like the right 
> choice, because the rest of the app won’t be able to access all the type 
> members you’re trying to hide (assuming that part is moved to it’s own 
> submodule). Right now `public` and `open` doesn’t make any sense in such 
> projects, which is a pity.
> 
> 
> Am 29. Oktober 2017 um 15:37:38, Mike Kluev via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> i am missing some protection level, which can be called "classprivate" or 
>> "structprivate" / "enumprivate" (names could be better). here is an example:
>> 
>> --- file Some.swift ---
>> 
>> class Some {
>> private func foo() {
>> bar() // error: inaccessible due to 'private'
>> }
>> }
>> 
>> --- file Some+Bar.swift ---
>> 
>> extension Some {
>> private func bar() {
>> foo() // error: inaccessible due to 'private'
>> }
>> }
>> 
>> 1) i want to have this extension in a different file (to keep file sizes 
>> manageable).
>> 
>> 2) i can't use either private or fileprivate due to compilation errors
>> 
>> 3) i do not want to have neither "foo" nor "bar" public
>> 
>> 4) "internal" doesn't help as "foo" and "bar" will be available to my app 
>> (which is unwanted).
>> 
>> is there some "classprivate" to help here? if not so far, shall there be 
>> one? opinions?
>> 
>> Mike
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adrian Zubarev via swift-evolution]

You’re not really missing an other access modifier here. I assume you’re 
speaking about a macOS/iOS app, right? Therefore the thing you’re really 
missing is a full integration of SPM in Xcode macOS/iOS projects and 
submodules. Then, and only then `internal` would really seem like the right 
choice, because the rest of the app won’t be able to access all the type 
members you’re trying to hide (assuming that part is moved to it’s own 
submodule). Right now `public` and `open` doesn’t make any sense in such 
projects, which is a pity.


Am 29. Oktober 2017 um 15:37:38, Mike Kluev via swift-evolution 
(swift-evolution@swift.org) schrieb:

i am missing some protection level, which can be called "classprivate" or 
"structprivate" / "enumprivate" (names could be better). here is an example:

--- file Some.swift ---

class Some {
private func foo() {
bar() // error: inaccessible due to 'private'
}
}

--- file Some+Bar.swift ---

extension Some {
private func bar() {
foo() // error: inaccessible due to 'private'
}
}

1) i want to have this extension in a different file (to keep file sizes 
manageable).

2) i can't use either private or fileprivate due to compilation errors

3) i do not want to have neither "foo" nor "bar" public

4) "internal" doesn't help as "foo" and "bar" will be available to my app 
(which is unwanted).

is there some "classprivate" to help here? if not so far, shall there be one? 
opinions?

Mike

___
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

Re: [swift-evolution] classprivate protection level?

[Noah Desch via swift-evolution]

Internal is the best choice available at the moment but I wouldn’t call it the 
“right” choice. Languages with the concept of classes often have a “protected” 
scope with means “visible within this class and subclasses”. In Swift that 
could mean “visible within this class, subclasses, and extensions” which would 
also make it useful for structs/enums, etc. I’ve also wanted such an access 
level on numerous occasions.


> On Oct 29, 2017, at 12:04 PM, Adam Kemp via swift-evolution 
>  wrote:
> 
> Internal is the right choice here. If it gives too much access then you might 
> consider pulling this code into a separate module.
> 
> If “private” gave access to every extension then any code outside your module 
> could make a new extension and access that method. That would make it 
> effectively public in that you wouldn’t have any ability to limit who can 
> call it.
> 
> On Oct 29, 2017, at 7:37 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
>> i am missing some protection level, which can be called "classprivate" or 
>> "structprivate" / "enumprivate" (names could be better). here is an example:
>> 
>> --- file Some.swift ---
>> 
>> class Some {
>>  private func foo() {
>>  bar() // error: inaccessible due to 'private'
>>  }
>> }
>> 
>> --- file Some+Bar.swift ---
>> 
>> extension Some {
>>  private func bar() {
>>  foo() // error: inaccessible due to 'private'
>>  }
>> }
>> 
>> 1) i want to have this extension in a different file (to keep file sizes 
>> manageable).
>> 
>> 2) i can't use either private or fileprivate due to compilation errors
>> 
>> 3) i do not want to have neither "foo" nor "bar" public
>> 
>> 4) "internal" doesn't help as "foo" and "bar" will be available to my app 
>> (which is unwanted).
>> 
>> is there some "classprivate" to help here? if not so far, shall there be 
>> one? opinions?
>> 
>> Mike
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] classprivate protection level?

[Adam Kemp via swift-evolution]

Internal is the right choice here. If it gives too much access then you might 
consider pulling this code into a separate module.

If “private” gave access to every extension then any code outside your module 
could make a new extension and access that method. That would make it 
effectively public in that you wouldn’t have any ability to limit who can call 
it.

> On Oct 29, 2017, at 7:37 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> i am missing some protection level, which can be called "classprivate" or 
> "structprivate" / "enumprivate" (names could be better). here is an example:
> 
> --- file Some.swift ---
> 
> class Some {
>   private func foo() {
>   bar() // error: inaccessible due to 'private'
>   }
> }
> 
> --- file Some+Bar.swift ---
> 
> extension Some {
>   private func bar() {
>   foo() // error: inaccessible due to 'private'
>   }
> }
> 
> 1) i want to have this extension in a different file (to keep file sizes 
> manageable).
> 
> 2) i can't use either private or fileprivate due to compilation errors
> 
> 3) i do not want to have neither "foo" nor "bar" public
> 
> 4) "internal" doesn't help as "foo" and "bar" will be available to my app 
> (which is unwanted).
> 
> is there some "classprivate" to help here? if not so far, shall there be one? 
> opinions?
> 
> Mike
> 
> ___
> 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

[swift-evolution] classprivate protection level?

[Mike Kluev via swift-evolution]

i am missing some protection level, which can be called "classprivate" or
"structprivate" / "enumprivate" (names could be better). here is an example:

--- file Some.swift ---


class Some {

private func foo() {

bar() // error: inaccessible due to 'private'

}

}

--- file Some+Bar.swift ---

extension Some {

private func bar() {

foo() // error: inaccessible due to 'private'

}

}

1) i want to have this extension in a different file (to keep file sizes
manageable).

2) i can't use either private or fileprivate due to compilation errors

3) i do not want to have neither "foo" nor "bar" public

4) "internal" doesn't help as "foo" and "bar" will be available to my app
(which is unwanted).

is there some "classprivate" to help here? if not so far, shall there be
one? opinions?

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution