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

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:

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

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

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

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

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

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 :) ->

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

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

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

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

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

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

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

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

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

> 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.

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

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

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

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

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

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

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

> 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

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

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. >

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

> 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

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

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.

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

> 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

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

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 >

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

> 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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

> 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

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

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.

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

> 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

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

> 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 ->

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

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

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

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 >

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

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

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

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

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

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:

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

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 > >

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

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

"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

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

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

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

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:

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

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

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

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.