I think it would be of great value to post both here and at the bug itself.
Thanks! -- E, looking forward to it > On Dec 27, 2015, at 8:22 PM, Taras Zakharko <taras.zakha...@googlemail.com> > wrote: > > Ah, thank you for pointing this out! I think I would suggest a change or two > to your proposal, but I need to flesh them out first. Is it possible to leave > comments on the bug site? BTW, why was it delegated to the bug report system > in the first place? > > > >> On 28 Dec 2015, at 02:28, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The most common use-case for this is with Cocoa classes, which are not set >> up for fluent implementation. A preliminary proposal (which I am not >> updating since the matter was referred to the bug report system) is here: >> https://gist.github.com/erica/6794d48d917e2084d6ed >> <https://gist.github.com/erica/6794d48d917e2084d6ed> Hopefully it explains >> the reason this would add to the Apple development ecosystem. The bug report >> is here: https://bugs.swift.org/browse/SR-160 >> <https://bugs.swift.org/browse/SR-160> >> >> -- E >> >> >>> On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lov...@gmail.com >>> <mailto:howard.lov...@gmail.com>> wrote: >>> >>> -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 <mailto: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/ >>>> <http://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 >>>> >>>> <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 <mailto: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 >>>>>> <mailto:taras.zakha...@uzh.ch>> wrote: >>>>>> >>>>>> >>>>>>> On 27 Dec 2015, at 21:55, Mosab Elagha <mosabela...@gmail.com >>>>>>> <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org> >>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
