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

[Mike Kluev]

On 8 November 2017 at 15:56, Benjamin G <benjamin.garrigues at gmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171108/84b3d221/attachment.html>