Re: [swift-evolution] continuations - "extensions on steroids" idea

[Tino Heth via swift-evolution]

I haven’t seen real resistance against partial types so far — and why should 
somebody oppose? Hopefully, no one who doesn’t like this feature will be forced 
to use it, right?

But imho that’s a slippery path, because there’s still a cost associated with 
every feature that is completely new:
Increased complexity.

I have no doubt that some people would find this feature cool, and build code 
with it, but I know that I personally don’t need it, and that there are things 
I consider to be more important.

Imho it’s at least worth a debate if splitting a type is actually that useful: 
We can already blame it for the trouble with access rights, so I’d rather 
prefer to postpone the topic in favor of changes that decrease complexity by 
removing limitations on existing features (for example, I’d like to be able to 
override something declared in an extension of a superclass…)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[David Waite via swift-evolution]

My preference would be around features to aggregate functionality, or to 
provide proper mixing.

1. One simpler feature would be a way to indicate your implementation of a 
protocol is via a property, and that calls should be forwarded.

2. More complex mixin behavior would include the included feature basically 
requesting a protocol as well, as a sort of language-level delegate. Compiler 
support means this can be done with value types, and that the implementations 
can be optimized/inlined.

Partial classes can solve some of these problems, but without a contract it can 
be difficult to manage the spaghetti nest of data and responsibilities. It also 
doesn’t allow for either part to be reusable across multiple implementations 
(except through class inheritance).

Partial classes in C# always seemed to exist specifically to combine authored 
and generated code without requiring a subclassing relationship.

-DW


> On Nov 8, 2017, at 11:44 AM, Adam Kemp via swift-evolution 
>  wrote:
> 
> That is a legitimate concern, but massive view controllers is a problem that 
> already exists. The kind of person who would use partial classes to split up 
> a giant view controller would probably also use extensions and just throw all 
> of the fields in the main file. People do that today with both Objective-C 
> and Swift. Partial classes would only make it marginally easier to implement 
> the bad designs that people are already doing. So I do think it’s a 
> legitimate concern, but I also think the benefits outweigh those costs.
> 
>> On Nov 8, 2017, at 2:54 AM, Benjamin G  wrote:
>> 
>> All your use cases make perfect sense, however i see one potential issue 
>> with this "pattern" : 
>> 
>> I've seen a LOT of iOS developers (some juniors, some not) ending up with 
>> monstruous UIViewControllers, and it has happened almost since the very 
>> beginning of iOS development. Because of their lack of understanding of the 
>> MVC pattern, they completely under estimate either the model or the view 
>> layer and put too many things in their VC. 
>> 
>> Now this pattern would give them the illusion that they're working in a sane 
>> architecture and that they've decomposed the problem correctly, but in fact 
>> were not. The fact that extension wouldn't let you add variable makes it 
>> harder to conceal the problem, but with "continuations" i can see no limit.
>> 
>> What do you think ? 
> 
> ___
> 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] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

That is a legitimate concern, but massive view controllers is a problem that 
already exists. The kind of person who would use partial classes to split up a 
giant view controller would probably also use extensions and just throw all of 
the fields in the main file. People do that today with both Objective-C and 
Swift. Partial classes would only make it marginally easier to implement the 
bad designs that people are already doing. So I do think it’s a legitimate 
concern, but I also think the benefits outweigh those costs.

> On Nov 8, 2017, at 2:54 AM, Benjamin G  wrote:
> 
> All your use cases make perfect sense, however i see one potential issue with 
> this "pattern" : 
> 
> I've seen a LOT of iOS developers (some juniors, some not) ending up with 
> monstruous UIViewControllers, and it has happened almost since the very 
> beginning of iOS development. Because of their lack of understanding of the 
> MVC pattern, they completely under estimate either the model or the view 
> layer and put too many things in their VC. 
> 
> Now this pattern would give them the illusion that they're working in a sane 
> architecture and that they've decomposed the problem correctly, but in fact 
> were not. The fact that extension wouldn't let you add variable makes it 
> harder to conceal the problem, but with "continuations" i can see no limit.
> 
> What do you think ? 

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 8 November 2017 at 15:56, Benjamin G 
wrote:

> I'm extremely curious to know the use case that made you code this way. Is
> it one of the case Adam listed before ?
>
>
to "manage complexities". once the type is relatively big (it's not a view
controller :) -> there's a need to split it into different extensions (or
even files) to keep things manageable -> hence the need to expose the
private things as internals due to the current language limitations ->
hence the fear that someone on the same module (even myself few weeks
later) one day will take advantage of "what is supposed to be private" and
get an unwanted dependency on it. plus of course a desire to save time on
trips to the main type and back when i have to change the variables, which
is quite annoying. if your type is reasonably big you may find yourself in
a situation when all you have in the main type definitions is just
variables (*), and you have several extensions each implementing a certain
feature.

(*) and those methods that relate to other language limitations, e.g.
"can't override methods of extensions yet"

among those 1.5 million hits for "how do i store variables in extensions in
swift" a significant portion would be for the "own type" use cases - so
that's not "just me".

the use case of IB outlets/variables brought by Adam can be a significant
plus for parts/continuations/partial ideas. just imagine you no longer have
to manually keep in sync the two (storyboard and outlets/variables) as
Xcode will do it itself. once we have this feature all IB classes (e.g. all
view controllers) will become parts/continuations/partials.

I don't want to sidetrack this issue, but i wonder if something like this
> https://golang.org/doc/effective_go.html#embedding wouldn't be a
> "cleaner" solution.
>
>
at the first glance it resembles... the ledger :) just from a slightly
different angle.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Benjamin G via swift-evolution]

I'm extremely curious to know the use case that made you code this way. Is
it one of the case Adam listed before ?

I don't want to sidetrack this issue, but i wonder if something like this
https://golang.org/doc/effective_go.html#embedding wouldn't be a "cleaner"
solution.

On Wed, Nov 8, 2017 at 3:45 PM, Mike Kluev  wrote:

> On 8 November 2017 at 14:20, Mike Kluev  wrote:
>
>> On 8 November 2017 at 10:54, Benjamin G 
>> wrote:
>>
>>> All your use cases make perfect sense, however i see one potential issue
>>> with this "pattern" :
>>>
>>> I've seen a LOT of iOS developers (some juniors, some not) ending up
>>> with monstruous UIViewControllers, and it has happened almost since the
>>> very beginning of iOS development. Because of their lack of understanding
>>> of the MVC pattern, they completely under estimate either the model or the
>>> view layer and put too many things in their VC.
>>>
>>> Now this pattern would give them the illusion that they're working in a
>>> sane architecture and that they've decomposed the problem correctly, but in
>>> fact were not. The fact that extension wouldn't let you add variable makes
>>> it harder to conceal the problem, but with "continuations" i can see no
>>> limit.
>>>
>>> What do you think ?
>>>
>>>
>> good tools won't fix bad developers (c)
>>
>> you know that you can already sort of "store variables" in extensions,
>> right? obj-c associated object is one way (1). and if we are talking about
>> the use case of extending "your own types only" -- i am -- your own classes
>> are under your full control, so nobody stops you from having, say, an
>> "extensionVars" dictionary in your root class(es) and a handy set of
>> generic api's to get/set those in a convenient manner without too much
>> effort (2). is it ideal? no. performance suffers. usability suffers. non
>> trivial to have weak/unowned variables with (2). not a "first class
>> citizen" solution. the sheer number of hits of "how to i store variables in
>> extensions in swift" (more than a million now) hints you that the language
>> can step in to help, at least in the critical use case of "own types".
>>
>>
> ftm, this is what i have now (based on method 2):
>
> extension SomeClass /* FeatureX */ {
>
>
>
> var someVar: Float {
>
> get { return extensionVar() }
>
> set { setExtensionVar(newValue) }
>
> }
>
>
>
> var otherVar: Bool {
>
> get { return extensionVar() }
>
> set { setExtensionVar(newValue) }
>
> }
>
>
>
> var someOptionalVar: Int? {
>
> get { return extensionVarOpt() }
>
> set { setExtensionVarOpt(newValue) }
>
> }
>
>
>
> func initFeatureX() {
>
> // init is optional if you can trust your code doing "set" before
> the first "get"
>
> someVar = 0
>
> otherVar = false
>
> }
>
> }
>
>
> this is on the use side. "not too bad". not too insane syntax. not too
> much code on the use side. note that i don't even have to spell the keys
> explicitly, so it is the same copy-paste code for all the variables. but
> then... optional vars need a different syntax. no weak/unowned support.
> non-optional ones need to be "set before get". performance suffers. etc,
> etc... (see the above).
>
>
> this is the ideal i am dreaming of:
>
>
> part FeatureX SomeClass {
>
> var someOptionalVar: Int? {
>
> var someVar: Float = 0
>
> var otherVar: Bool = false
>
> var someOptionalVar: Int?
>
>
>
> weak var someWeakVar: X?
>
> }
>
> }
>
> parts (continuations) can be an answer.
>
> Mike
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 8 November 2017 at 14:20, Mike Kluev  wrote:

> On 8 November 2017 at 10:54, Benjamin G 
> wrote:
>
>> All your use cases make perfect sense, however i see one potential issue
>> with this "pattern" :
>>
>> I've seen a LOT of iOS developers (some juniors, some not) ending up with
>> monstruous UIViewControllers, and it has happened almost since the very
>> beginning of iOS development. Because of their lack of understanding of the
>> MVC pattern, they completely under estimate either the model or the view
>> layer and put too many things in their VC.
>>
>> Now this pattern would give them the illusion that they're working in a
>> sane architecture and that they've decomposed the problem correctly, but in
>> fact were not. The fact that extension wouldn't let you add variable makes
>> it harder to conceal the problem, but with "continuations" i can see no
>> limit.
>>
>> What do you think ?
>>
>>
> good tools won't fix bad developers (c)
>
> you know that you can already sort of "store variables" in extensions,
> right? obj-c associated object is one way (1). and if we are talking about
> the use case of extending "your own types only" -- i am -- your own classes
> are under your full control, so nobody stops you from having, say, an
> "extensionVars" dictionary in your root class(es) and a handy set of
> generic api's to get/set those in a convenient manner without too much
> effort (2). is it ideal? no. performance suffers. usability suffers. non
> trivial to have weak/unowned variables with (2). not a "first class
> citizen" solution. the sheer number of hits of "how to i store variables in
> extensions in swift" (more than a million now) hints you that the language
> can step in to help, at least in the critical use case of "own types".
>
>
ftm, this is what i have now (based on method 2):

extension SomeClass /* FeatureX */ {



var someVar: Float {

get { return extensionVar() }

set { setExtensionVar(newValue) }

}



var otherVar: Bool {

get { return extensionVar() }

set { setExtensionVar(newValue) }

}



var someOptionalVar: Int? {

get { return extensionVarOpt() }

set { setExtensionVarOpt(newValue) }

}



func initFeatureX() {

// init is optional if you can trust your code doing "set" before
the first "get"

someVar = 0

otherVar = false

}

}


this is on the use side. "not too bad". not too insane syntax. not too much
code on the use side. note that i don't even have to spell the keys
explicitly, so it is the same copy-paste code for all the variables. but
then... optional vars need a different syntax. no weak/unowned support.
non-optional ones need to be "set before get". performance suffers. etc,
etc... (see the above).


this is the ideal i am dreaming of:


part FeatureX SomeClass {

var someOptionalVar: Int? {

var someVar: Float = 0

var otherVar: Bool = false

var someOptionalVar: Int?



weak var someWeakVar: X?

}

}

parts (continuations) can be an answer.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 8 November 2017 at 10:54, Benjamin G 
wrote:

> All your use cases make perfect sense, however i see one potential issue
> with this "pattern" :
>
> I've seen a LOT of iOS developers (some juniors, some not) ending up with
> monstruous UIViewControllers, and it has happened almost since the very
> beginning of iOS development. Because of their lack of understanding of the
> MVC pattern, they completely under estimate either the model or the view
> layer and put too many things in their VC.
>
> Now this pattern would give them the illusion that they're working in a
> sane architecture and that they've decomposed the problem correctly, but in
> fact were not. The fact that extension wouldn't let you add variable makes
> it harder to conceal the problem, but with "continuations" i can see no
> limit.
>
> What do you think ?
>
>
good tools won't fix bad developers (c)

you know that you can already sort of "store variables" in extensions,
right? obj-c associated object is one way (1). and if we are talking about
the use case of extending "your own types only" -- i am -- your own classes
are under your full control, so nobody stops you from having, say, an
"extensionVars" dictionary in your root class(es) and a handy set of
generic api's to get/set those in a convenient manner without too much
effort (2). is it ideal? no. performance suffers. usability suffers. non
trivial to have weak/unowned variables with (2). not a "first class
citizen" solution. the sheer number of hits of "how to i store variables in
extensions in swift" (more than a million now) hints you that the language
can step in to help, at least in the critical use case of "own types".

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Benjamin G via swift-evolution]

All your use cases make perfect sense, however i see one potential issue
with this "pattern" :

I've seen a LOT of iOS developers (some juniors, some not) ending up with
monstruous UIViewControllers, and it has happened almost since the very
beginning of iOS development. Because of their lack of understanding of the
MVC pattern, they completely under estimate either the model or the view
layer and put too many things in their VC.

Now this pattern would give them the illusion that they're working in a
sane architecture and that they've decomposed the problem correctly, but in
fact were not. The fact that extension wouldn't let you add variable makes
it harder to conceal the problem, but with "continuations" i can see no
limit.

What do you think ?


On Tue, Oct 31, 2017 at 4:22 AM, Adam Kemp via swift-evolution <
swift-evolution@swift.org> wrote:

> This I actually support. In C# the same concept exists in the form of
> partial classes. A class must be declared as partial everywhere in order to
> support it. It only works within a single assembly (similar to a module).
>
> There are a few important use cases for this in C#:
>
> 1. Code generation. For instance, Interface Builder could modify a
> separate file for things like outlets and actions, and it could freely wipe
> and regenerate that file from scratch without touching any of your own
> code. Some people also generate parts of classes from templates while
> filling in the rest in another file.
>
> 2. Cross platform code. A common strategy in C# is to have a class split
> into parts, where one part is compiled on all platforms, and the other
> files are each specific to one platform or another. For instance, you may
> have Foo.swift, Foo.macOS.swift, and Foo.iOS.swift. Foo.swift would be
> compiled on both platforms, but then the iOS build would only include
> Foo.iOS.swift. This is a preferred alternative to using #ifs.
>
> 3. The use case Mike described. Sometimes we fail at making classes small,
> or maybe someone else failed and we’re stuck with it. Splitting a single
> class into pieces can be useful to organize cohesive chunks. That’s not
> something I tend to encourage as a design pattern, but it still happens
> anyway.
>
> A related feature in C# is partial methods, which are just void-returning
> methods that have been declared as partial without an implementation. If an
> implementation is provided by another file (in another part of the partial
> class) then it is used. If no file provides an implementation then calls to
> that method are just stripped out by the compiler. This is also commonly
> used for cross-platform code. Maybe one platform needs to do something at a
> particular time but another doesn’t. Rather than using #ifs or having empty
> stubs in other platforms you can declare it partial and provide an
> implementation on just the one platform that needs it.
>
> > On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > a general feeling that there are two very different use cases of
> extensions -- one to extend own classes and another to extend other people
> classes; a lengthy discussion in a nearby thread; a disparity of features
> of class and it's extensions and different access right treatment depending
> upon whether the extension is in the same with the main class or a
> different file lead me to the following idea. hopefully you will find this
> idea useful and we may even see it one day in swift.
> >
> > introducing class / struct / enum continuations.
> >
> > in a few words the are:
> >
> > 1) "extensions on steroids". in fact very similar to Objective-C "class
> extensions" but can be more than one and in more than one file.
> >
> > 2) as good as the classes they continue (or other continuations they
> continue)
> >
> > 3) can declare variables
> >
> > 4) have full access to "private" members of the class or other
> continuations
> > regardless whether they are in the same or in a different files. no need
> for "public/internal/module" fallbacks to pass though files boundaries.
> similarly the class itself can use private members of its continuations.
> >
> > 5) "by invitation only" system. can only be written if declared by the
> class or some continuation of it.
> >
> > 6) A particular continuation only defined once (of course). There can be
> an arbitrary number of different continuations to a class similar to
> extensions.
> >
> > 7) alternative name considered: "extending" (as a noun). shall
> definitely be a different name than say, "extension" with some
> bracket-syntax variation - the two use cases are very different and shall
> be named differently.
> >
> > 8) the particular syntax is preliminary of course.
> >
> > example:
> >
> > = Some.swift ==
> >
> > class Some {
> >
> > private func private_method_of_class() {
> >
> > // *** can use private methods of continuations even if they are
> in a different file
> > 

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 7, 2017, at 6:05 PM, Jon Gilbert via swift-evolution 
>  wrote:
> 
> It’s easy to have projects where one Swift module is made up of numerous git 
> repos. You can silo who is allowed to touch your code that way even within 
> people working on a single module.

Why do you need to have multiple git repos contribute to a single module 
instead of having each repo produce its own module? I don’t understand why you 
would do that.

To me “module” implies “a cohesive set of code maintained by a single team”. I 
trust people on my team, and I can also see every change that goes into the 
projects I work on.

Again, if you don’t trust developers that are contributing code to your module 
then you have bigger problems than this. Proper module boundaries would help to 
address those problems.

> Having a class “partial” where anyone in the module can screw around is 
> dangerous and therefore un-Swifty. 

This is contradicted by the experience of a large community of C# developers 
who have been using partial classes for years without running into your 
hypothetical problems.

A search on GitHub shows over 5 million hits for “partial class” in C# code:
https://github.com/search?l=C%23=desc=%22partial+class%22=indexed=Code
 

There are over 2000 hits in the Rosyln codebase alone (Microsoft’s C# compiler):

https://github.com/dotnet/roslyn/search?q=%22partial+class%22= 


This is heavily used in the real world by professionals working on projects of 
all sizes.

I think we have to weigh the FUD against what we can observe actually happening 
in the wild when developers use a feature like this. The reality is that the 
things you’re concerned about are not actually problems in practice. They’re 
contrived hypotheticals.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Jon Gilbert via swift-evolution]

On Nov 3, 2017, at 14:36, Adam Kemp via swift-evolution 
 wrote:
> 
> If you work with people who can’t follow conventions and would try to extend 
> partial classes from random places then I’m sorry. :)

This seems naive. 

Swift is based on the idea of making it impossible to do things the wrong way, 
because of Murphy’s Law.

You might get hired to clean up some total crap code that was created in a 
sweatshop overseas by people who never touched Swift before and only ever wrote 
in PHP 1.0 before that. I have seen this kind of thing all too often.

Then you have the fact that Swift is used increasingly in school environments, 
and I sure as heck don’t want some bully kid being able to inject pronz to 
display on my kid’s viewcontroller just because she wanted to use “parts” or 
“partials” (or whatever we end up calling it).

Then there are open source projects where all kinds of malicious things could 
be done with unbounded partiality, and people will hesitate to use this feature 
without being able to trust its safety.

My point is it’s not always a team of highly trained professional developers 
working on a project. It could be strangers you will never meet. Someone 
vindictive or stupid could also do something to deliberately or accidentally 
break code you worked. And when they blame you, then “those were private 
methods you used” would no longer be a valid excuse. 

I feel much better declaring the parts as a list, and that way you can 
command-click on them in XCode to jump to those other parts, and the 
initializer can make sure that all those parts can be found or else block 
compilation. 

Just my 0.02.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Jon Gilbert via swift-evolution]

I like the ledger list idea better than saying “this class is partial” and now 
it can be extended anywhere.

Adam said below that, “you have to trust your fellow developers,” but that’s 
BS. You can’t merge a PR to master without approval, and some repos you have to 
PR from a fork. 

It’s easy to have projects where one Swift module is made up of numerous git 
repos. You can silo who is allowed to touch your code that way even within 
people working on a single module.

Having a class “partial” where anyone in the module can screw around is 
dangerous and therefore un-Swifty. 

If devs could be trusted then Swift and git would not even exist.

So I feel it has to be the ledger, guys :D Just saying.

J

> On Nov 2, 2017, at 18:37, Adam Kemp via swift-evolution 
>  wrote:
> 
> I will echo what several other people said in the previous discussion: you 
> have to trust your fellow developers. By declaring a class as “partial” you 
> are allowing that class to be extended elsewhere. Typically that would mean 
> in an adjacent file named ClassName.Foo.swift (next to ClassName.swift). It 
> should be highly discouraged to extend the class using partial from anywhere 
> else, and listing tools can enforce that if needed. But at the end of the day 
> if you can’t trust your fellow developers not to do that then you can’t trust 
> them not to add a new name to the ledger either.
> 
> And in case someone was wondering why I’m ok with this and not the 
> “classprivate" idea, the key difference here is that this is opt-in. I’m 
> still not ok with a random extension being able to access private fields of 
> any class by default. Partial classes should be an exception for specific use 
> cases, not a default behavior.
> 
>> On Nov 2, 2017, at 5:18 AM, Mike Kluev via swift-evolution 
>>  wrote:
>> 
>> to sum up. so far the feedback on this proposal was:
>> 
>> 1) generally in favour (e.g. to have ability of adding variables and 
>> accessing privates at all)
>> 
>> 2) the name "continuation" is used for something else
>> 
>> 3) why not to use partials as they are in c#
>> 
>> 4) having explicit names for continuations is unwanted because naming is hard
>> 
>> 5) the ledger list is unnecessary as anyone on the same module will be able 
>> to change it anyway - false feel of protection.
>> 
>> here are my thoughts on it.
>> 
>> 1) "generally in favour (e.g. to have ability of adding variables and 
>> accessing privates at all)"
>> -- great! thank you.
>> 
>> 2) "the name "continuation" is used for something else"
>> -- thought the same. let it be "part" instead of continuation
>> 
>> 3) "why not to use partials as they are in c#"
>> -- my belief here is that just because i made my type partial (for my own 
>> reasons, e.g. as a result of splitting a single-file class into a 
>> multi-file) it does not necessarily mean I want other developers of my team 
>> (on the same module) to add continuations / parts to my class. in other 
>> words, while there are the module boundaries (the building walls) i still 
>> want to see some partitions between the rooms of that building to have some 
>> privacy.
>> 
>> 4) "having explicit names for continuations is unwanted because naming is 
>> hard"
>> -- every time I am adding extension now I want to label it somehow to 
>> indicate it's purpose. if that extensions adds a protocol conformance (e.g. 
>> "extension ViewController: UITableViewDataSource") the problem is not as 
>> critical as the protocol (or the list of protocols) name itself can serve 
>> the purpose of such an indication. if there is no such a protocol 
>> conformance however i tend to add a "MARK: ThePurpose" or a comment 
>> ("extension ViewController /* ThePurpose */) and as the comments are not 
>> checked and get out of sync every time i do this i wish there was a a more 
>> explicit extension label in the language for this purpose. maybe that's just 
>> me.
>> 
>> 5) "the ledger list is unnecessary as anyone on the same module will be able 
>> to change it anyway - false feel of protection."
>> -- to this i can give the same response as in (3). here is another example 
>> that hopefully will clarify my point: we shall not really say that "private" 
>> in swift is useless and "internal" shall be used instead of it just because 
>> anyone in the same module can bypass it anyway: go to your class and change 
>> the source from "private" to "internal" for their own benefits, so why 
>> bother with private / fileprivate to begin with. so is true in regards to 
>> the ledger: yes, it is true that anyone on the team working on the same 
>> module has a physical ability to go to my class (the class who's sole 
>> maintainer and "owner" is myself) and mess around it, changing it's ledger 
>> along the way, or making it partial as in (3) or changing it's privates to 
>> internal, or adding variables, etc. it's just they shouldn't, at least not 
>> talking to me first. 

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 21:36, Adam Kemp  wrote:

>
> Your ledger idea might theoretically prevent some of those bad things from
> happening, but at the expense of making the whole thing unusable for this
> use case. That’s not a good trade off.
>

well, this particular one is not impossible with ledger:

class View: UIView {
   part Feature1// *** default
   optional part Feature2   // *** the behaviour you describing
}

or even this (if majority agrees this is a better default):

class View: UIView {
   required part Feature1// *** opt-in
   part Feature2   // *** optional, the behaviour you describing
}

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 3, 2017, at 11:45 AM, Mike Kluev  wrote:
> 
> On 3 November 2017 at 18:08, Adam Kemp  > wrote:
> 
> 1. You end up with a whole section of type aliases at the top of the file,
> 
> i'm putting those in a separate Platform.swift file
>  
> and as you read the file it’s hard to understand what those types actually 
> represent.
> 
> in the example above "View" - a very similar concept between macOS and 
> iOS/tvOS/watchOS.
> in case of doubts - command click is always at the finger tips.
>  
> Which methods are you actually allowed to use? What should code completion 
> show you? 
> 
> autocomplete shows the relevant methods on each platform correctly.
> 
> 2. The type alias is only useful when the naming of the methods/properties is 
> identical and the sequence of calls you have to make is identical, which very 
> often isn’t the case. You end up needing conditional compilation anyway for 
> cases where you only need to make a call on one platform, or where the method 
> you have to call is named slightly different or takes different arguments.
> 
> if the differences are minute i'm creating my own extension methods to make 
> the difference non existent.
> 
> example: layer is optional on OSX and non optional on iOS. the difference is 
> minute and i can make this difference non existent, e.g. by:
> 
> extension UIView {
> var viewLayer: CALayer? {
> return layer
> }
> }
> 
> and a similar thing on OSX, and afterwards i have single API on both 
> platforms with no differences.
> 
> You end up needing conditional compilation anyway for cases where you only 
> need to make a call on one platform, or where the method you have to call is 
> named slightly different or takes different arguments. 
>  
>  
> i rarely have to use conditional compilation and even when have to do so i 
> normally hide it inside the relevant "utility" extensions, from then on i 
> don't see anything "conditional" within the normal app sources.
>  
> Out of the strategies I’ve seen used for cross-platform code this one was the 
> most frustrating to work with in my experience.
> 
> quite the contrary to me - the best possible experience with such an approach 
> (during many years of experience ftm)

All I can say is, again, I’ve worked with code that plays these tricks, and I 
found it much harder to deal with than the code that used partial classes. 
You’re using all the tricks you can to make it work, but in my experience those 
tricks add up to a code base that is harder to work with and harder to 
understand and more brittle than the alternative approach I described. The 
tricks are part of what makes it confusing. At the risk of sounding 
presumptuous, I think if you could actually try the other approach (i.e., if we 
actually had partial classes that work like in C#) you would likely agree. 
Unfortunately it’s hard to do that comparison when you haven’t tried both 
approaches in real world situations.

>  
>> My argument is that there should be no ledger in the first place. IMO you 
>> haven’t made the case for that requirement.
> 
> the real-world example would be:
> 
> case 1. you have a single page of paper on hands saying: "partial contract A. 
> continued elsewhere. Blah, blah". you look around and within a multitude of 
> papers on the table you managed to find another sheet of paper with "partial 
> contract A. continued elsewhere. Blah, blah". in order to find the whole 
> thing you will have to look in all papers on your table, then in the shelve 
> and then in the whole building (module boundaries)

This is not how it works in practice. In practice the files are right next to 
each other with similar names. It would be more like having “to be continued” 
at the end of a book sitting right next to another book with the same name plus 
“Volume 2”. I think you would know where to look.

If you work with people who can’t follow conventions and would try to extend 
partial classes from random places then I’m sorry. :)

You may notice that this has echoes to our earlier conversation where I was on 
the other side of a very similar disagreement about extensions. I argued that 
extensions would lead to confusion because they can be thrown anywhere, and 
someone pointed out that there are file naming conventions for that. I think 
this is different because extensions are very often included in random files 
where they are most convenient. They have a different meaning and a different 
use case that I think encourages their use in files that are not named after 
the class they’re extending.

Partial classes aren’t intended to be used that way so it really never makes 
sense to have a partial class implementation in a file that is not dedicated 
specifically to that partial class implementation. That would raise red flags 
during code reviews. It’s a very simple rule to follow: if you see “partial 
class Foo” then the file name 

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 18:08, Adam Kemp  wrote:

>
> 1. You end up with a whole section of type aliases at the top of the file,
>

i'm putting those in a separate Platform.swift file


> and as you read the file it’s hard to understand what those types actually
> represent.
>

in the example above "View" - a very similar concept between macOS and
iOS/tvOS/watchOS.
in case of doubts - command click is always at the finger tips.


> Which methods are you actually allowed to use? What should code completion
> show you?
>

autocomplete shows the relevant methods on each platform correctly.

2. The type alias is only useful when the naming of the methods/properties
> is identical and the sequence of calls you have to make is identical, which
> very often isn’t the case. You end up needing conditional compilation
> anyway for cases where you only need to make a call on one platform, or
> where the method you have to call is named slightly different or takes
> different arguments.
>

if the differences are minute i'm creating my own extension methods to make
the difference non existent.

example: layer is optional on OSX and non optional on iOS. the difference
is minute and i can make this difference non existent, e.g. by:

extension UIView {

var viewLayer: CALayer? {

return layer

}

}

and a similar thing on OSX, and afterwards i have single API on both
platforms with no differences.

You end up needing conditional compilation anyway for cases where you only
> need to make a call on one platform, or where the method you have to call
> is named slightly different or takes different arguments.
>

>

i rarely have to use conditional compilation and even when have to do so i
normally hide it inside the relevant "utility" extensions, from then on i
don't see anything "conditional" within the normal app sources.


> Out of the strategies I’ve seen used for cross-platform code this one was
> the most frustrating to work with in my experience.
>

quite the contrary to me - the best possible experience with such an
approach (during many years of experience ftm)


> My argument is that there should be no ledger in the first place. IMO you
>> haven’t made the case for that requirement.
>>
> the real-world example would be:

case 1. you have a single page of paper on hands saying: "partial contract
A. continued elsewhere. Blah, blah". you look around and within a multitude
of papers on the table you managed to find another sheet of paper with
"partial contract A. continued elsewhere. Blah, blah". in order to find the
whole thing you will have to look in all papers on your table, then in the
shelve and then in the whole building (module boundaries)

case 2. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around and within a
multitude of papers on the table you managed to find another sheet of paper
with: "part B of contract A, blah, blah". at that point you know that you
found everything, don't need to look on the shelve or in the whole building.

case 3. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around the whole
building and found no "part B". at this point you know - something is lost,
and act accordingly.

i mean this:
>
> class MyView: UIView {
> optional part Drawing
> }
>
> part Drawing of MyView { //  forgot to include this into target
> override func drawRect(...) {
> .
> }
> }
>
> the app compiles but doesn't work correctly.
>
>
> That example doesn’t make any sense.
>

i don't see why (and I am not talking about cross platform code at this
point). i have instances like these implemented via extensions in a day to
day code. the split of the class into files was done merely for organising
purposes, to keep file size manageable.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 3, 2017, at 10:55 AM, Mike Kluev  wrote:
> 
> On 3 November 2017 at 17:23, Adam Kemp  > wrote:
> 
> 
> When you actually try to use that technique in a fuller example it becomes 
> impractical. I know because some people working on the same code base tried 
> that, and it was much worse.
> 
> please provide more details on this. i was and still using such a technique, 
> so want to be prepared for those pitfalls before i actually encounter them.

1. You end up with a whole section of type aliases at the top of the file, and 
as you read the file it’s hard to understand what those types actually 
represent. Which methods are you actually allowed to use? What should code 
completion show you? Nothing is as it seems.

2. The type alias is only useful when the naming of the methods/properties is 
identical and the sequence of calls you have to make is identical, which very 
often isn’t the case. You end up needing conditional compilation anyway for 
cases where you only need to make a call on one platform, or where the method 
you have to call is named slightly different or takes different arguments.

Out of the strategies I’ve seen used for cross-platform code this one was the 
most frustrating to work with in my experience.

> My argument is that there should be no ledger in the first place. IMO you 
> haven’t made the case for that requirement.
> 
> If you forget to implement a protocol then ...
> 
> i mean this:
> 
> class MyView: UIView {
> optional part Drawing
> }
> 
> part Drawing of MyView { //  forgot to include this into target
> override func drawRect(...) {
> .
> }
> }
> 
> the app compiles but doesn't work correctly.

That example doesn’t make any sense. You wouldn’t override a drawRect function 
in the shared file because that function is overriding a platform-specific 
function. This is exactly the use case I gave an example for. What you would do 
instead is override the platform-specific draw function in a platform-specific 
file and then redirect to a shared implementation that has a cross-platform 
interface.

In general I would say you shouldn’t implement a protocol method for a protocol 
not declared in the same file or override a method of a superclass not 
explicitly mentioned in that file. That’s just a bad practice. Instead you 
would put that function in the same file as the protocol or superclass is 
mentioned and then, if needed, redirect to another function in another file. 
Then if you leave out that file it won’t compile because you’ll be missing a 
function.

Trust me, this works very well in practice. I never once ran into a bug like 
that over several years of doing things this way.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 17:23, Adam Kemp  wrote:

>
>
> When you actually try to use that technique in a fuller example it becomes
> impractical. I know because some people working on the same code base tried
> that, and it was much worse.
>

please provide more details on this. i was and still using such a
technique, so want to be prepared for those pitfalls before i actually
encounter them.


> I will concede that there are other techniques for cross-platform code
> that might be considered even cleaner. This isn’t the only technique, and I
> won’t claim that it’s the best technique, but it is a very useful technique
> that I have seen used very effectively. It would be nice to be able to have
> it as an option.
>
> having said that, yes, i can see your point. my fear is that it will be
> (1) too fragile (e.g. you have "TableViewDelegate" in the ledger and just
> forgot to include the relevant file in the target - the app compiles but
> then misbehaves,
>
>
> My argument is that there should be no ledger in the first place. IMO you
> haven’t made the case for that requirement.
>

> If you forget to implement a protocol then ...
>

i mean this:

class MyView: UIView {
optional part Drawing
}

part Drawing of MyView { //  forgot to include this into target
override func drawRect(...) {
.
}
}

the app compiles but doesn't work correctly.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 3, 2017, at 10:05 AM, Mike Kluev  wrote:
> 
> On 3 November 2017 at 16:42, Adam Kemp  > wrote:
> 
> If that’s the case then this wouldn’t solve one of the major use cases I 
> listed for this: splitting up cross-platform classes into platform-specific 
> files. The idea is that each target contains a different subset of the files. 
> Consider a case where two platforms are similar enough to share some code but 
> not all code. For instance:
> 
>  
> i think we need a better real-world example, as in this one it's probably 
> easier to have "View" defined as a type alias to either UIView or NSView 
> depending upon a platform and similarly define currentGraphicsContext() to be 
> either UIGraphicsGetCurrentContext() or 
> NSGraphicsContext.currentContext()?.CGContext depending upon a platform and 
> have a single code base afterwords:

When you actually try to use that technique in a fuller example it becomes 
impractical. I know because some people working on the same code base tried 
that, and it was much worse. Partial classes make for a much cleaner 
implementation, and they avoid conditional compilation.

I will concede that there are other techniques for cross-platform code that 
might be considered even cleaner. This isn’t the only technique, and I won’t 
claim that it’s the best technique, but it is a very useful technique that I 
have seen used very effectively. It would be nice to be able to have it as an 
option.

> having said that, yes, i can see your point. my fear is that it will be (1) 
> too fragile (e.g. you have "TableViewDelegate" in the ledger and just forgot 
> to include the relevant file in the target - the app compiles but then 
> misbehaves,

My argument is that there should be no ledger in the first place. IMO you 
haven’t made the case for that requirement.

If you forget to implement a protocol then your build will fail because either 
1) you claimed to implement it and didn’t or 2) you didn’t claim to implement 
it and then tried to use that class somewhere that expects an object conforming 
to the protocol. This was never a problem. We have a type safe language. Even 
if you come up with some corner case where this could actually happen it falls 
squarely into the realm of bugs that would never ship (i.e., it will be obvious 
very quickly that something is wrong).

> and (2) open for abuse.

Again, we have to trust our developers to some extent. I worked in a large 
codebase with a large team of developers and not once did anyone abuse this.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 16:42, Adam Kemp  wrote:

>
> If that’s the case then this wouldn’t solve one of the major use cases I
> listed for this: splitting up cross-platform classes into platform-specific
> files. The idea is that each target contains a different subset of the
> files. Consider a case where two platforms are similar enough to share some
> code but not all code. For instance:
>
>
i think we need a better real-world example, as in this one it's probably
easier to have "View" defined as a type alias to either UIView or NSView
depending upon a platform and similarly define currentGraphicsContext() to
be either UIGraphicsGetCurrentContext() or
NSGraphicsContext.currentContext()?.CGContext depending upon a platform and
have a single code base afterwords:

class PresentationView: View {

private func draw(inContext context: CGContext) {

// Shared CoreGraphics drawing

}



func draw(_ rect: CGRect) {

self.draw(inContext: currentGraphicsContext())

}

}


having said that, yes, i can see your point. my fear is that it will be (1)
too fragile (e.g. you have "TableViewDelegate" in the ledger and just
forgot to include the relevant file in the target - the app compiles but
then misbehaves, and (2) open for abuse.


alternative 1 - it's not too hard to put an empty:


part Feature of SomeClass {}


for the relevant platform


alternative 2 - have this in the ledger:


class Some {

part Feature1

optional part Feature2

}


as an "opt-in" to the behaviour you want.


i think this type of refinement can be done at some later stage. after all,
we do not have even (much needed IMHO) optional protocol methods without
resorting to @objc as of now...


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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 3, 2017, at 5:17 AM, Mike Kluev  wrote:
> 
> On 3 November 2017 at 03:05, Adam Kemp  > wrote:
> 
> 
> Would it be an error to have an entry in the “ledger” but not a corresponding 
> implementation?
> 
> definitely so. and vice versa.
> 
> Mike
> 

If that’s the case then this wouldn’t solve one of the major use cases I listed 
for this: splitting up cross-platform classes into platform-specific files. The 
idea is that each target contains a different subset of the files. Consider a 
case where two platforms are similar enough to share some code but not all 
code. For instance:

Class.swift
Class.UIKit.swift // Used by iOS + watchOS
Class.iOS.swift
Class.watchOS.swift
Class.macOS.swift

There are three targets, and two of the targets include Class.UIKit.swift but 
not the third. So what do you put in the ledger?

For a real-world example, consider a custom view that is used for presenting 
content in an app that shares code on iOS, tvOS, and macOS. Much of the logic 
for this is shared, including rendering which is done using CoreGraphics. You 
could write that class something like this:

PresentationView.swift:
import CoreGraphics

partial class PresentationView {

private func draw(inContext context: CGContext) {
// Shared CoreGraphics drawing
}

}

PresentationView.UIKit.swift: // Used by iOS + tvOS
import UIKit

partial class PresentationView : UIView {
func draw(_ rect: CGRect) {
self.draw(inContext: UIGraphicsGetCurrentContext())
}
}

PresentationView.AppKit.swift:
import AppKit

partial class PresentationView : NSView {
func draw(_ dirtyRect: NSRect) {
self.draw(inContext: NSGraphicsContext.currentContext()?.CGContext)
}
}

This is exactly the technique that I’ve used in the past (in C#) to share code 
across iOS, Android, macOS, and WPF. It’s really powerful, but the ledger would 
make it much harder.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 02:52, Noah Desch  wrote:

>
> I’m +1 on the ledger and partial classes in general. I think extensions
> serving the dual purpose of extending other module’s classes, as well as an
> organizational tool for in-module classes has resulted in some bad choices
> and makes future development harder. Having a new construct for in-module
> class organization neatly solves the problem.
>

well said


> (I still want C++’s protected scope too though, in case there was any
> doubt).
>

+1

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 3 November 2017 at 03:05, Adam Kemp  wrote:

>
>
> Would it be an error to have an entry in the “ledger” but not a
> corresponding implementation?
>

definitely so. and vice versa.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 2, 2017, at 7:52 PM, Noah Desch  wrote:
> 
> 
> IMO the ledger isn’t just about access control, it’s also about having a 
> convenient (and guaranteed correct, due compiler enforcement) place to see 
> where the rest of your class is defined. 

I have worked on several large code bases in C# that made extensive use of 
partial classes. This was never a problem. No one ever tried to put a partial 
class where it didn’t belong. 

Would it be an error to have an entry in the “ledger” but not a corresponding 
implementation?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Noah Desch via swift-evolution]

IMO the ledger isn’t just about access control, it’s also about having a 
convenient (and guaranteed correct, due compiler enforcement) place to see 
where the rest of your class is defined. 

I’m +1 on the ledger and partial classes in general. I think extensions serving 
the dual purpose of extending other module’s classes, as well as an 
organizational tool for in-module classes has resulted in some bad choices and 
makes future development harder. Having a new construct for in-module class 
organization neatly solves the problem.

(I still want C++’s protected scope too though, in case there was any doubt). 


> On Nov 2, 2017, at 9:37 PM, Adam Kemp via swift-evolution 
>  wrote:
> 
> I will echo what several other people said in the previous discussion: you 
> have to trust your fellow developers. By declaring a class as “partial” you 
> are allowing that class to be extended elsewhere. Typically that would mean 
> in an adjacent file named ClassName.Foo.swift (next to ClassName.swift). It 
> should be highly discouraged to extend the class using partial from anywhere 
> else, and listing tools can enforce that if needed. But at the end of the day 
> if you can’t trust your fellow developers not to do that then you can’t trust 
> them not to add a new name to the ledger either.
> 
> And in case someone was wondering why I’m ok with this and not the 
> “classprivate" idea, the key difference here is that this is opt-in. I’m 
> still not ok with a random extension being able to access private fields of 
> any class by default. Partial classes should be an exception for specific use 
> cases, not a default behavior.
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

I will echo what several other people said in the previous discussion: you have 
to trust your fellow developers. By declaring a class as “partial” you are 
allowing that class to be extended elsewhere. Typically that would mean in an 
adjacent file named ClassName.Foo.swift (next to ClassName.swift). It should be 
highly discouraged to extend the class using partial from anywhere else, and 
listing tools can enforce that if needed. But at the end of the day if you 
can’t trust your fellow developers not to do that then you can’t trust them not 
to add a new name to the ledger either.

And in case someone was wondering why I’m ok with this and not the 
“classprivate" idea, the key difference here is that this is opt-in. I’m still 
not ok with a random extension being able to access private fields of any class 
by default. Partial classes should be an exception for specific use cases, not 
a default behavior.

> On Nov 2, 2017, at 5:18 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> to sum up. so far the feedback on this proposal was:
> 
> 1) generally in favour (e.g. to have ability of adding variables and 
> accessing privates at all)
> 
> 2) the name "continuation" is used for something else
> 
> 3) why not to use partials as they are in c#
> 
> 4) having explicit names for continuations is unwanted because naming is hard
> 
> 5) the ledger list is unnecessary as anyone on the same module will be able 
> to change it anyway - false feel of protection.
> 
> here are my thoughts on it.
> 
> 1) "generally in favour (e.g. to have ability of adding variables and 
> accessing privates at all)"
> -- great! thank you.
> 
> 2) "the name "continuation" is used for something else"
> -- thought the same. let it be "part" instead of continuation
> 
> 3) "why not to use partials as they are in c#"
> -- my belief here is that just because i made my type partial (for my own 
> reasons, e.g. as a result of splitting a single-file class into a multi-file) 
> it does not necessarily mean I want other developers of my team (on the same 
> module) to add continuations / parts to my class. in other words, while there 
> are the module boundaries (the building walls) i still want to see some 
> partitions between the rooms of that building to have some privacy.
> 
> 4) "having explicit names for continuations is unwanted because naming is 
> hard"
> -- every time I am adding extension now I want to label it somehow to 
> indicate it's purpose. if that extensions adds a protocol conformance (e.g. 
> "extension ViewController: UITableViewDataSource") the problem is not as 
> critical as the protocol (or the list of protocols) name itself can serve the 
> purpose of such an indication. if there is no such a protocol conformance 
> however i tend to add a "MARK: ThePurpose" or a comment ("extension 
> ViewController /* ThePurpose */) and as the comments are not checked and get 
> out of sync every time i do this i wish there was a a more explicit extension 
> label in the language for this purpose. maybe that's just me.
> 
> 5) "the ledger list is unnecessary as anyone on the same module will be able 
> to change it anyway - false feel of protection."
> -- to this i can give the same response as in (3). here is another example 
> that hopefully will clarify my point: we shall not really say that "private" 
> in swift is useless and "internal" shall be used instead of it just because 
> anyone in the same module can bypass it anyway: go to your class and change 
> the source from "private" to "internal" for their own benefits, so why bother 
> with private / fileprivate to begin with. so is true in regards to the 
> ledger: yes, it is true that anyone on the team working on the same module 
> has a physical ability to go to my class (the class who's sole maintainer and 
> "owner" is myself) and mess around it, changing it's ledger along the way, or 
> making it partial as in (3) or changing it's privates to internal, or adding 
> variables, etc. it's just they shouldn't, at least not talking to me first. 
> they won't be "behaving properly" if they do.
> 
> some additional thoughts. ledger works similar to the c++ class definition 
> itself, which lists all the members of the class, just on a less granular 
> scope: while in C++ you have to go there every time you want to add, say, a 
> private method, with parts you go change the ledger very infrequently, to add 
> a group or functionalities. another tangentially similar feature of C++ is 
> "friends". if you class have, say, 10 different extensions each implementing 
> a certain feature and you converted them to "parts" the ledger list will 
> contain 10 entries naming those features explicitly.
> 
> Mike
> 
> ps. by now i figured that discussing protection levels in swift is akin to 
> having a wonderful morning walk across a mine field
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

to sum up. so far the feedback on this proposal was:

1) generally in favour (e.g. to have ability of adding variables and
accessing privates at all)

2) the name "continuation" is used for something else

3) why not to use partials as they are in c#

4) having explicit names for continuations is unwanted because naming is
hard

5) the ledger list is unnecessary as anyone on the same module will be able
to change it anyway - false feel of protection.

here are my thoughts on it.

1) "generally in favour (e.g. to have ability of adding variables and
accessing privates at all)"
-- great! thank you.

2) "the name "continuation" is used for something else"
-- thought the same. let it be "part" instead of continuation

3) "why not to use partials as they are in c#"
-- my belief here is that just because i made my type partial (for my own
reasons, e.g. as a result of splitting a single-file class into a
multi-file) it does not necessarily mean I want other developers of my team
(on the same module) to add continuations / parts to my class. in other
words, while there are the module boundaries (the building walls) i still
want to see some partitions between the rooms of that building to have some
privacy.

4) "having explicit names for continuations is unwanted because naming is
hard"
-- every time I am adding extension now I want to label it somehow to
indicate it's purpose. if that extensions adds a protocol conformance (e.g.
"extension ViewController: UITableViewDataSource") the problem is not as
critical as the protocol (or the list of protocols) name itself can serve
the purpose of such an indication. if there is no such a protocol
conformance however i tend to add a "MARK: ThePurpose" or a comment
("extension ViewController /* ThePurpose */) and as the comments are not
checked and get out of sync every time i do this i wish there was a a more
explicit extension label in the language for this purpose. maybe that's
just me.

5) "the ledger list is unnecessary as anyone on the same module will be
able to change it anyway - false feel of protection."
-- to this i can give the same response as in (3). here is another example
that hopefully will clarify my point: we shall not really say that
"private" in swift is useless and "internal" shall be used instead of it
just because anyone in the same module can bypass it anyway: go to your
class and change the source from "private" to "internal" for their own
benefits, so why bother with private / fileprivate to begin with. so is
true in regards to the ledger: yes, it is true that anyone on the team
working on the same module has a physical ability to go to my class (the
class who's sole maintainer and "owner" is myself) and mess around it,
changing it's ledger along the way, or making it partial as in (3) or
changing it's privates to internal, or adding variables, etc. it's just
they shouldn't, at least not talking to me first. they won't be "behaving
properly" if they do.

some additional thoughts. ledger works similar to the c++ class definition
itself, which lists all the members of the class, just on a less granular
scope: while in C++ you have to go there every time you want to add, say, a
private method, with parts you go change the ledger very infrequently, to
add a group or functionalities. another tangentially similar feature of C++
is "friends". if you class have, say, 10 different extensions each
implementing a certain feature and you converted them to "parts" the ledger
list will contain 10 entries naming those features explicitly.

Mike

ps. by now i figured that discussing protection levels in swift is akin to
having a wonderful morning walk across a mine field
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Lee M via swift-evolution]

I suggested something similar a little while ago:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170327/034767.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 1, 2017, at 11:09 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> On 1 November 2017 at 15:31, BJ Homer  > wrote:
> Again, though, “anyone” here only means “anyone working in the same module”. 
> Which is a very restricted set of “anyone”: it only includes people who 
> already have full access, and could just modify the original struct anyway.
> 
> by this logic we can conclude that "private" in C++ is absolutely useless, as 
> anyone (like "anyone in the world with the header") can change the header 
> from: "private: void foo();" to "public: void foo();" even without the need 
> of having the corresponding source file with "void foo()". right?

Swift doesn’t have headers so this doesn’t really make sense here. The idea of 
a module is to be able to provide someone an immutable binary with a public 
interface. Someone consuming your code via a module won’t be able to modify the 
contents of that module and shouldn’t be able to access private methods of 
classes in that module or add new private fields or methods to classes in that 
module. I think we all agree on that. A module that your code uses is immutable 
to you.

But people who are building that module and already editing code within that 
module can and should be able to modify a class in that module any way they 
want. That should be obvious, right? That person can choose to directly edit 
the class in its main definition file, but (with partial classes as I’ve 
described) they could also choose to mark that class as partial and then add to 
it from a different swift file from within the same module. As a maintainer of 
that module there is absolutely nothing wrong with this. That’s why it’s 
important that this only be possible within that module.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 1 November 2017 at 15:31, BJ Homer  wrote:

> Again, though, “anyone” here only means “anyone working in the same
> module”. Which is a very restricted set of “anyone”: it only includes
> people who already have full access, and could just modify the original
> struct anyway.
>

by this logic we can conclude that "private" in C++ is absolutely useless,
as anyone (like "anyone in the world with the header") can change the
header from: "private: void foo();" to "public: void foo();" even without
the need of having the corresponding source file with "void foo()". right?

i'd say wrong. i'd say that even if i have a physical write access to, say,
30 third party libraries and use them in my project doesn't mean i am
"free" to go to those other people classes and change private things to
public willy nilly, or add variables to their classes, etc. my proposal, as
well as the above example with C++ private - only works if people "behave".
ledger is an explicit list of parts allowed. a guest list if you wish.
"party crashing" is not addressed in this proposal.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 1, 2017, at 8:54 AM, Zach Wolfe via swift-evolution 
>  wrote:
> 
> I like what this idea attempts to do, but have you thought of simply allowing 
> extensions of types within the same module to access private members and 
> declare stored properties?

The advantage of the extra keyword is that it makes it opt-in, which means you 
can know by looking at the class whether there are other places that have 
access to your private methods/fields/etc.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 1, 2017, at 8:28 AM, Mike Kluev  wrote:
> 
> name and ledger are essential in this proposal.
> 
> no name -> 
> no ledger (how to reference it?) -> 

What purpose does the “ledger" serve? I’m not sure what this even means.

> anyone can write parts of your class -> 

Anyone in the same module, but only if you explicitly declare your class as 
partial in the first place.

Impartial.swift:
class Impartial {}
Impartial.extra.swift:
partial class Impartial {} // error

Partial.swift:
partial class Partial {}
Partial.extra.swift:
partial class Partial {} // OK
Partial.othermodule.swift:
partial class Partial {} // Error

> anyone can add variables to your class ?! -> 
> anyone can access private members of your class ?! 
> 
> makes no sense without a name and a ledger.
> 
> Mike
> 

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Zach Wolfe via swift-evolution]

I like what this idea attempts to do, but have you thought of simply allowing 
extensions of types within the same module to access private members and 
declare stored properties? Adding a whole new construct to the language—while 
technically not source-breaking—would in practice change what is considered to 
be the idiomatic “Swifty” way of extending your own types, forcing people who 
care about such things to revisit their code for (imo) no good reason.

As a separate point, I’m strongly against the requirement that continuations be 
named and declared within the original type declaration or other continuations. 
As an optional categorization feature I’d be ok with it, but naming is hard, 
and forcing me to come up with a name every time I wish to isolate 
functionality of my types will push me away from doing it in the first place. 
Not to mention when I inevitably change one of my horrible continuation names, 
I will have to change it in two places (or more in the cross-platform example)!

Also on the naming point, you mention being able to refer to continuations by 
name. Can you give an example where that would be useful?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[BJ Homer via swift-evolution]

Again, though, “anyone” here only means “anyone working in the same module”. 
Which is a very restricted set of “anyone”: it only includes people who already 
have full access, and could just modify the original struct anyway.

-BJ

> On Nov 1, 2017, at 9:28 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> 
> On 1 November 2017 at 15:22, Adam Kemp  > wrote:
> I don’t see why “parts” would need to be named. That seems overly complex for 
> little benefit. 
> 
> 
> name and ledger are essential in this proposal.
> 
> no name -> 
> no ledger (how to reference it?) -> 
> anyone can write parts of your class -> 
> anyone can add variables to your class ?! -> 
> anyone can access private members of your class ?! 
> 
> makes no sense without a name and a ledger.
> 
> 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] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 1 November 2017 at 15:22, Adam Kemp  wrote:

> I don’t see why “parts” would need to be named. That seems overly complex
> for little benefit.
>
>
name and ledger are essential in this proposal.

no name ->
no ledger (how to reference it?) ->
anyone can write parts of your class ->
anyone can add variables to your class ?! ->
anyone can access private members of your class ?!

makes no sense without a name and a ledger.

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

I don’t see why “parts” would need to be named. That seems overly complex for 
little benefit. 

> On Nov 1, 2017, at 7:43 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
>> On 1 November 2017 at 13:34, Wallacy  wrote:
>> Partial (like in C#) is good enough.
> 
> "partial" will not read correctly in this context:
> 
> class ViewController: UIViewController {
> partial DataSource // ?!
> ...
> }
> 
> partial DataSource of ViewController: UITableViewDataSource { // ?!
> } 
> 
> if you mean:
> 
> partial class ViewController: UITableViewDataSource {
> ...
> }
> 
> this is not what i'm suggesting. parts/continuations must have a name and 
> this name must be listed in a ledger (of the main class or another part of 
> it) for the part to be able to exist at all.
> 
> having the "main" part (just the normal class definition) is good for:
> 
> - it is the only place to put base class in (like the above UIViewController)
> 
> - it has the starting ledger that list parts (direct sub-parts). all parts 
> can be found "recursively" from that starting point.
> 
> with "parts" many pieces that are extensions today will become parts. and 
> "private" to "fileprivate" promotion feature will likely not be needed 
> anymore (we can of course leave it as is for compatibility).
> 
> 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] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 1 November 2017 at 13:34, Wallacy  wrote:

> Partial (like in C#) is good enough.
>

"partial" will not read correctly in this context:

class ViewController: UIViewController {
partial DataSource // ?!
...
}

partial DataSource of ViewController: UITableViewDataSource { // ?!
}

if you mean:

partial class ViewController: UITableViewDataSource {
...
}

this is not what i'm suggesting. parts/continuations must have a name and
this name must be listed in a ledger (of the main class or another part of
it) for the part to be able to exist at all.

having the "main" part (just the normal class definition) is good for:

- it is the only place to put base class in (like the above
UIViewController)

- it has the starting ledger that list parts (direct sub-parts). all parts
can be found "recursively" from that starting point.

with "parts" many pieces that are extensions today will become parts. and
"private" to "fileprivate" promotion feature will likely not be needed
anymore (we can of course leave it as is for compatibility).

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Wallacy via swift-evolution]

Partial (like in C#) is good enough.

Em qua, 1 de nov de 2017 às 09:52, Mike Kluev via swift-evolution <
swift-evolution@swift.org> escreveu:

> class ViewController {
> part DataSource
> ...
> }
>
> part DataSource of ViewController: UITableViewDataSource {
> 
> }
>
> 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] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

class ViewController {
part DataSource
...
}

part DataSource of ViewController: UITableViewDataSource {

}

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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Eagle Offshore via swift-evolution]

"Continuation" already means something else in computer programming.  I would 
suggest you find another term.

https://en.wikipedia.org/wiki/Continuation


> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> a general feeling that there are two very different use cases of extensions 
> -- one to extend own classes and another to extend other people classes; a 
> lengthy discussion in a nearby thread; a disparity of features of class and 
> it's extensions and different access right treatment depending upon whether 
> the extension is in the same with the main class or a different file lead me 
> to the following idea. hopefully you will find this idea useful and we may 
> even see it one day in swift.
> 
> introducing class / struct / enum continuations.
> 
> in a few words the are:
> 
> 1) "extensions on steroids". in fact very similar to Objective-C "class 
> extensions" but can be more than one and in more than one file.
> 
> 2) as good as the classes they continue (or other continuations they continue)
> 
> 3) can declare variables
> 
> 4) have full access to "private" members of the class or other continuations
> regardless whether they are in the same or in a different files. no need for 
> "public/internal/module" fallbacks to pass though files boundaries. similarly 
> the class itself can use private members of its continuations.
> 
> 5) "by invitation only" system. can only be written if declared by the class 
> or some continuation of it.
> 
> 6) A particular continuation only defined once (of course). There can be an 
> arbitrary number of different continuations to a class similar to extensions.
> 
> 7) alternative name considered: "extending" (as a noun). shall definitely be 
> a different name than say, "extension" with some bracket-syntax variation - 
> the two use cases are very different and shall be named differently.
> 
> 8) the particular syntax is preliminary of course. 
> 
> example:
> 
> = Some.swift ==
> 
> class Some {
> 
> private func private_method_of_class() {
> 
> // *** can use private methods of continuations even if they are in a 
> different file
> private_method_defined_in_a_continuation()
> }
> 
> // *** "by invitation" system
> 
> continuation Feature  // *** declaring a continuation
> continuation SomethingElse// *** Capitalized names, like classes
> }
> 
> = Some-Feature.swift ==
> 
> // *** similar naming convetion to "Some+Feature.swift"
> // used for extensions, just with "-" instead
> 
> // *** this is merely a naming convention, no need to
> necessarily follow it, can put more than one thing into
> a file, the continuation can reside in the same file as
> the main class fie, etc.
> 
> continuation Feature of Some {
> 
> // *** as good as class itself. first-class citizen
> // *** same syntax can be used for structs and enums
> 
> var x: Int // *** can declare variables
> 
> private func private_method_defined_in_a_continuation() {
> private_method_of_class()
> 
> // *** can use private methods of the class or of other
> continuations even if they are in a different file
> }
> 
> // *** continuations are as good as classes and can
> // *** declare other continuations if needed
> 
> continuation CanDoThis
> }
> 
> = Any file ==
> 
> continuation Feature of Some { // *** error, continuation is already defined
> }
> 
> continuation Other of Some { // *** error: Other is not a continuation of Some
> }
> 
> thoughts?
> 
> 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] continuations - "extensions on steroids" idea

[Wallacy via swift-evolution]

Like Adam said, this make much more sense than
"classprivate./typeprivate"...

+1 for me.

You just create another 'bucket'! ;)

Em ter, 31 de out de 2017 às 08:19, Mike Kluev via swift-evolution <
swift-evolution@swift.org> escreveu:

> On 31 October 2017 at 06:57, Goffredo Marocchi  wrote:
>
>> I like the IB use case :).
>>
>>
> my favourite one would probably be continuations used for protocol
> adoption - no longer the trip to the main class needed to add a variable:
>
> continuation DataSource of MyViewController: UITableViewDataSource {
>
> private var variable: Bool // ***
>
> override func tableView(_ tableView: UITableView, cellForRowAt
> indexPath: IndexPath) -> UITableViewCell {
> ...
> }
> }
>
> ___
> 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] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

On 31 October 2017 at 06:57, Goffredo Marocchi  wrote:

> I like the IB use case :).
>
>
my favourite one would probably be continuations used for protocol adoption
- no longer the trip to the main class needed to add a variable:

continuation DataSource of MyViewController: UITableViewDataSource {

private var variable: Bool // ***

override func tableView(_ tableView: UITableView, cellForRowAt
indexPath: IndexPath) -> UITableViewCell {
...
}
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Goffredo Marocchi via swift-evolution]

I like the IB use case :).

Sent from my iPhone

> On 31 Oct 2017, at 03:22, Adam Kemp via swift-evolution 
>  wrote:
> 
> This I actually support. In C# the same concept exists in the form of partial 
> classes. A class must be declared as partial everywhere in order to support 
> it. It only works within a single assembly (similar to a module).
> 
> There are a few important use cases for this in C#:
> 
> 1. Code generation. For instance, Interface Builder could modify a separate 
> file for things like outlets and actions, and it could freely wipe and 
> regenerate that file from scratch without touching any of your own code. Some 
> people also generate parts of classes from templates while filling in the 
> rest in another file. 
> 
> 2. Cross platform code. A common strategy in C# is to have a class split into 
> parts, where one part is compiled on all platforms, and the other files are 
> each specific to one platform or another. For instance, you may have 
> Foo.swift, Foo.macOS.swift, and Foo.iOS.swift. Foo.swift would be compiled on 
> both platforms, but then the iOS build would only include Foo.iOS.swift. This 
> is a preferred alternative to using #ifs.
> 
> 3. The use case Mike described. Sometimes we fail at making classes small, or 
> maybe someone else failed and we’re stuck with it. Splitting a single class 
> into pieces can be useful to organize cohesive chunks. That’s not something I 
> tend to encourage as a design pattern, but it still happens anyway. 
> 
> A related feature in C# is partial methods, which are just void-returning 
> methods that have been declared as partial without an implementation. If an 
> implementation is provided by another file (in another part of the partial 
> class) then it is used. If no file provides an implementation then calls to 
> that method are just stripped out by the compiler. This is also commonly used 
> for cross-platform code. Maybe one platform needs to do something at a 
> particular time but another doesn’t. Rather than using #ifs or having empty 
> stubs in other platforms you can declare it partial and provide an 
> implementation on just the one platform that needs it.
> 
>> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>>  wrote:
>> 
>> a general feeling that there are two very different use cases of extensions 
>> -- one to extend own classes and another to extend other people classes; a 
>> lengthy discussion in a nearby thread; a disparity of features of class and 
>> it's extensions and different access right treatment depending upon whether 
>> the extension is in the same with the main class or a different file lead me 
>> to the following idea. hopefully you will find this idea useful and we may 
>> even see it one day in swift.
>> 
>> introducing class / struct / enum continuations.
>> 
>> in a few words the are:
>> 
>> 1) "extensions on steroids". in fact very similar to Objective-C "class 
>> extensions" but can be more than one and in more than one file.
>> 
>> 2) as good as the classes they continue (or other continuations they 
>> continue)
>> 
>> 3) can declare variables
>> 
>> 4) have full access to "private" members of the class or other continuations
>> regardless whether they are in the same or in a different files. no need for 
>> "public/internal/module" fallbacks to pass though files boundaries. 
>> similarly the class itself can use private members of its continuations.
>> 
>> 5) "by invitation only" system. can only be written if declared by the class 
>> or some continuation of it.
>> 
>> 6) A particular continuation only defined once (of course). There can be an 
>> arbitrary number of different continuations to a class similar to extensions.
>> 
>> 7) alternative name considered: "extending" (as a noun). shall definitely be 
>> a different name than say, "extension" with some bracket-syntax variation - 
>> the two use cases are very different and shall be named differently.
>> 
>> 8) the particular syntax is preliminary of course. 
>> 
>> example:
>> 
>> = Some.swift ==
>> 
>> class Some {
>> 
>>private func private_method_of_class() {
>> 
>>// *** can use private methods of continuations even if they are in a 
>> different file
>>private_method_defined_in_a_continuation()
>>}
>> 
>>// *** "by invitation" system
>> 
>>continuation Feature// *** declaring a continuation
>>continuation SomethingElse// *** Capitalized names, like classes
>> }
>> 
>> = Some-Feature.swift ==
>> 
>> // *** similar naming convetion to "Some+Feature.swift"
>> // used for extensions, just with "-" instead
>> 
>> // *** this is merely a naming convention, no need to
>> necessarily follow it, can put more than one thing into
>> a file, the continuation can reside in the same file as
>> the main class fie, etc.
>> 
>> continuation Feature of Some {
>> 
>> // *** as 

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

This I actually support. In C# the same concept exists in the form of partial 
classes. A class must be declared as partial everywhere in order to support it. 
It only works within a single assembly (similar to a module).

There are a few important use cases for this in C#:

1. Code generation. For instance, Interface Builder could modify a separate 
file for things like outlets and actions, and it could freely wipe and 
regenerate that file from scratch without touching any of your own code. Some 
people also generate parts of classes from templates while filling in the rest 
in another file. 

2. Cross platform code. A common strategy in C# is to have a class split into 
parts, where one part is compiled on all platforms, and the other files are 
each specific to one platform or another. For instance, you may have Foo.swift, 
Foo.macOS.swift, and Foo.iOS.swift. Foo.swift would be compiled on both 
platforms, but then the iOS build would only include Foo.iOS.swift. This is a 
preferred alternative to using #ifs.

3. The use case Mike described. Sometimes we fail at making classes small, or 
maybe someone else failed and we’re stuck with it. Splitting a single class 
into pieces can be useful to organize cohesive chunks. That’s not something I 
tend to encourage as a design pattern, but it still happens anyway. 

A related feature in C# is partial methods, which are just void-returning 
methods that have been declared as partial without an implementation. If an 
implementation is provided by another file (in another part of the partial 
class) then it is used. If no file provides an implementation then calls to 
that method are just stripped out by the compiler. This is also commonly used 
for cross-platform code. Maybe one platform needs to do something at a 
particular time but another doesn’t. Rather than using #ifs or having empty 
stubs in other platforms you can declare it partial and provide an 
implementation on just the one platform that needs it.

> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> a general feeling that there are two very different use cases of extensions 
> -- one to extend own classes and another to extend other people classes; a 
> lengthy discussion in a nearby thread; a disparity of features of class and 
> it's extensions and different access right treatment depending upon whether 
> the extension is in the same with the main class or a different file lead me 
> to the following idea. hopefully you will find this idea useful and we may 
> even see it one day in swift.
> 
> introducing class / struct / enum continuations.
> 
> in a few words the are:
> 
> 1) "extensions on steroids". in fact very similar to Objective-C "class 
> extensions" but can be more than one and in more than one file.
> 
> 2) as good as the classes they continue (or other continuations they continue)
> 
> 3) can declare variables
> 
> 4) have full access to "private" members of the class or other continuations
> regardless whether they are in the same or in a different files. no need for 
> "public/internal/module" fallbacks to pass though files boundaries. similarly 
> the class itself can use private members of its continuations.
> 
> 5) "by invitation only" system. can only be written if declared by the class 
> or some continuation of it.
> 
> 6) A particular continuation only defined once (of course). There can be an 
> arbitrary number of different continuations to a class similar to extensions.
> 
> 7) alternative name considered: "extending" (as a noun). shall definitely be 
> a different name than say, "extension" with some bracket-syntax variation - 
> the two use cases are very different and shall be named differently.
> 
> 8) the particular syntax is preliminary of course. 
> 
> example:
> 
> = Some.swift ==
> 
> class Some {
> 
> private func private_method_of_class() {
> 
> // *** can use private methods of continuations even if they are in a 
> different file
> private_method_defined_in_a_continuation()
> }
> 
> // *** "by invitation" system
> 
> continuation Feature  // *** declaring a continuation
> continuation SomethingElse// *** Capitalized names, like classes
> }
> 
> = Some-Feature.swift ==
> 
> // *** similar naming convetion to "Some+Feature.swift"
> // used for extensions, just with "-" instead
> 
> // *** this is merely a naming convention, no need to
> necessarily follow it, can put more than one thing into
> a file, the continuation can reside in the same file as
> the main class fie, etc.
> 
> continuation Feature of Some {
> 
> // *** as good as class itself. first-class citizen
> // *** same syntax can be used for structs and enums
> 
> var x: Int // *** can declare variables
> 
> private func private_method_defined_in_a_continuation() {
> private_method_of_class()
> 
> //