[swift-evolution] Pitch: Partial Implementations

[Pranshu Goyal]

Hello Karl,

Don't you think stored properties in extensions would encourage the kind of
code you talked about. I believe may you're doing it while understanding
it's implications and also accepting the fact that it's not easy to write
UI code in a modular way, but do we want everyone to think like this?
Should we accept defeat on the face of this problem that there's no way to
write UI code in a modular way where we don't have to put everything in one
massive view controller?

I feel we would be just raising our hands up if we do it this way

On 24 March 2017 at 16:49, Karl Wagner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 24 Mar 2017, at 10:50, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 23 Mar 2017, at 21:10, Vladimir.S via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On 23.03.2017 21:21, Matthew Johnson via swift-evolution wrote:
>
>
> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> MOTIVATION:
>
> In current Swift, a pattern has emerged among some developers, in
> order to logically group parts of a class or struct’s declaration,
> particularly around protocols:
>
> >> ...
>
>
> What do you think?
>
>
> If we wanted to allow code like this to be written we wouldn’t need a
> new keyword to do it.  You are proposing two things here:
>
> 1) Allow stored properties in same-module extensions.  This has been
> discussed in the past and is a possibility, but I suspect it is not in
> scope for consideration during Swift 4.
>
>
> Are we really expect to have stored properties in same-module extensions?
> As I remember, there a lot of questions were raised during discussions so
> for some reason *I* had a feeling that we should not expect this happens in
> near feature. Probably I missed something.
>
>
> I can see why some people might want to do stored properties in extensions
> to structure things, but personally I quite like the lack of flexibility as
> it encourages the initial type declaration to focus on what a type
> *contains*, while extensions focus on what it *does*. I've really taken
> to that style, as I now almost never declare methods or computed properties
> in an initial type declaration, unless it's a very simple one; instead
> doing all my methods and protocol conformances in their own extensions.
>
> i.e- I quite like that by the time you've finished your type declaration
> you have finalised what its size will be, and nothing else can change that,
> spreading it out feels like it could make that more confusing. It also IMO
> helps to encourage you to keep a type's contents fairly simple, as you can
> see in one place if you've made it very complicated.
>
> I suppose there's an argument for having the freedom to do it however you
> want, but I don't think spreading out across a module is a good idea;
> unless we're assuming that module in this context applies like in other
> proposals, where fileprivate is a "module" with only one file.
>
> I dunno, I just think that as a pattern the current requirement to keep
> stored properties within a type declaration enforces some good practices. I
> found it a bit jarring at first too, but after adapting to the type +
> extensions style I find I actually really like doing things that way.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> If you have a complex class (especially in UI code), you sometimes don’t
> really care about the size of the class and would prefer data to be grouped
> in broader functional groups. For example, I might like my toolbar-related
> iVars to be in one extension, and my datasource-related iVars in another,
> maybe with a couple of protocol conformances with require the odd state
> variable.
>
> Requiring all of the stored properties live in the initial declaration
> means that the code is ultimately less clear: instead of being
> locally-declared (and perhaps even privately-scoped), the variable is now
> thousands of lines away from the only place I want to access it directly
> and visible throughout my implementation for me to one day muck up its
> state.
>
> Allowing stored extensions within the same file seems like a good
> compromise to me, especially if its “trivial” to implement ;) Perhaps we
> could require such types to have some special annotation or magic
> “ExtensionVariables” item, for the benefit of readability? Just trying to
> find what you’d feel would be acceptable.
>
> - Karl
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/a384ce4b/attachment.html>