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.
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.
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.
Also, would this be limited to instance methods?
-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
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()
}
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.
···
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com> wrote:
-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
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?
···
On 27 Dec 2015, at 22:08, Taras Zakharko <taras.zakharko@uzh.ch> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@gmail.com>> wrote:
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
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.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@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
I thought there was some sort of showstopper that ended further discussion for Swift 3 — but seems it wasn't the fault of the archive that I didn't find that reason ;-)
I'll use the opportunity to talk about my major motivation to want cascades in Swift:
Several years ago, I was quite bored by Objective-C and did an inquiry what other languages I might like.
I considered exotic choices like Vala (reference counted, compiled), but despite my dislike for garbage-collected systems, I also looked at the JVM.
At that time, my feeling was that many people were deeply impressed by some goodies Groovy had to offer, but didn't want to give up the benefits of type safety.
One of the major selling point for a nice contender called "Kotlin" has been "type safe, Groovy-style builders", and their use case might become very important for Swift as well.
I'll just show an example:
let page = HTML().{
body.{
table.{
tr.{
td.text("Cell content")
td.text("Another cell")
}
}
div(color: .redColor()).text("Some text")
}
}
// basic principle: directly start a method cascade on computed properties
This piece of code (I'm not using the proposed "with"-syntax but a light-weight alternative that I'd prefer) could generate a complete HTML-page, ready to be send to a browser — and the syntax is much easier than the generated markup itself!
With Swift on Linux, I'm quite sure generating HTML will become a very important task for the language.
-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:
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.zakharko@uzh.ch> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@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
On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lovatt@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:
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.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@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
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.zakharko@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:
On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lovatt@gmail.com <mailto:howard.lovatt@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:
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.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@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
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> wrote:
On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lovatt@gmail.com <mailto:howard.lovatt@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:
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.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@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
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> wrote:
On Dec 27, 2015, at 6:24 PM, Howard Lovatt <howard.lovatt@gmail.com <mailto:howard.lovatt@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:
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.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@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
Same is true for the implicit self, and yet we’ve seen how people react to making self explicit. There are many places in contemporary Apple programming where this could be of great utility. For instance, I miss a lexical scope construction every time I work with Metal.
···
On 28 Dec 2015, at 02:24, Howard Lovatt via swift-evolution <swift-evolution@swift.org> 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:
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.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:
On 27 Dec 2015, at 21:55, Mosab Elagha <mosabelagha@gmail.com <mailto:mosabelagha@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