I believe this has popped up on-list a few times. Search for method cascades:
cascading site:https://lists.swift.org/pipermail/swift-evolution/ https://www.google.com/?gws_rd=ssl#q=cascading+site:https:%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F Other search terms include dart, initializers, ".." (although that may be hard to look for) -- E > On Dec 27, 2015, at 2:34 PM, Radosław Smogura via swift-evolution > <[email protected]> wrote: > > Hi, > > Please find my comment in body: > > BR, > Radek Smogura >> On 27 Dec 2015, at 22:08, Taras Zakharko <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On 27 Dec 2015, at 21:55, Mosab Elagha <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Agreed, this seems like a great idea. Looks like it would also allow for a >>> lot of customization - for example out of one "template" object. >>> >>> Would the object have to already be initialized or could you initialize it >>> from this? IMO it would have to already be initialized or else it might >>> lead to confusion. >> >> The object could be any kind of valid Swift entity that has members (where >> you would usually use . to access them): object instance, type, struct etc. >> I can also imagine combining it with assignment, e.g. instead of >> >> let obj = MyClass() >> do with obj { >> prop1 = v1 >> setup2() >> } >> >> a combined assignment form such as >> >> do with let obj = MyClass() { >> prop1 = v1 >> setup2() >> } > I think in this case it’s important to define scope of obj - it should be > only “do with”, not the the outer one? > >> But this clashes with optional binding, so it might be not a good idea. >> >>> Also, would this be limited to instance methods? >> >> Anything you can access with the dot notation. >> >>> >>> -Mosab Elagha >>> >>> On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura >>> <[email protected] <mailto:[email protected]>> wrote: >>> Hi, >>> >>> That’s a great idea! >>> >>> Kind regards, >>> Radek >>> >>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > >>> > Quite often, one needs to perform a number of operations on a single >>> > object (e.g. call up a bunch of configuration or action methods). This >>> > proposal is to extend the ‘do' statement with an explicit lexical scope >>> > feature. For instance, this piece of code >>> > >>> > object.do_something() >>> > object.do_somethind_else() >>> > object.prop1 = value >>> > >>> > becomes >>> > >>> > do with object // or with object do >>> > { >>> > do_something() >>> > do_somethind_else() >>> > prop1 = value >>> > } >>> > >>> > Essentially, this construct would introduce a level of lexical scope — >>> > explicitly controlled by the programmer, in addition to the implicit >>> > scope dictated by statement blocks, closures and self. >>> > >>> > The advantage of this construct is that it allows one to remove >>> > boilerplate code for initialisation/configuration as well as adds clear >>> > logical separation to the code. Disadvantage is potential shadowing of >>> > identifiers in the scope, but this should to be a big issue because the >>> > syntax is explicit rather then implicit, meaning that its the programmers >>> > job to make sure that no shadowing occurs (btw, compiler could warn about >>> > shadowing). The additions to the language syntax is minimal and the >>> > implementation should be straightforward (its essentially the same logic >>> > as for self). >>> > >>> > Note that this proposal is close to the discussion about popular the >>> > implicit self on this mailing list. A body of any method could be >>> > understood as wrapped into an implicit >>> > >>> > do with self {} >>> > >>> > Finally, this construct exists in a very similar form in Pascal (no idea >>> > if Wirth was inspired by some other feature or not here) and is also >>> > present in a bunch of languages that have dynamic scope. Personally, I >>> > use it all the time in R and I am loving it. >>> > >>> > If the community thinks this could be a nice addition to the language, I >>> > am ready to draft a proposal. Also, apologies if this has been suggested >>> > before — it is impossible to keep up with this list. >>> > >>> > Best, >>> > >>> > Taras >>> > _______________________________________________ >>> > swift-evolution mailing list >>> > [email protected] <mailto:[email protected]> >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
