On 8 November 2017 at 14:20, Mike Kluev <mike.kl...@gmail.com> wrote:
> On 8 November 2017 at 10:54, Benjamin G <benjamin.garrig...@gmail.com> > 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