<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>Also, would this be limited to instance methods?</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><span style="border-collapse:collapse;font-family:arial,sans-serif;font-size:13px"><font color="#C0C0C0"><div>-Mosab Elagha</div></font></span></div></div></div>
<br><div class="gmail_quote">On Sun, Dec 27, 2015 at 3:13 PM, Radosław Smogura <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
That’s a great idea!<br>
<br>
Kind regards,<br>
Radek<br>
<div><div><br>
> On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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<br>
><br>
> object.do_something()<br>
> object.do_somethind_else()<br>
> object.prop1 = value<br>
><br>
> becomes<br>
><br>
> do with object // or with object do<br>
> {<br>
> do_something()<br>
> do_somethind_else()<br>
> prop1 = value<br>
> }<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> 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<br>
><br>
> do with self {}<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Best,<br>
><br>
> Taras<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>