-1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at the start of every line. Also if an API is intended to be used like that its methods would return `self` and it would be used in a FLUENT style.
Sent from my iPad > On 28 Dec 2015, at 9:00 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 >> <swift-evolution@swift.org> wrote: >> >> Hi, >> >> Please find my comment in body: >> >> BR, >> Radek Smogura >>>> On 27 Dec 2015, at 22:08, Taras Zakharko <taras.zakha...@uzh.ch> wrote: >>>> >>>> >>> >>>> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com> 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 >>>>> <swift-evolution@swift.org> wrote: >>>>> Hi, >>>>> >>>>> That’s a great idea! >>>>> >>>>> Kind regards, >>>>> Radek >>>>> >>>>> > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution >>>>> > <swift-evolution@swift.org> 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 >>>>> > swift-evolution@swift.org >>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
