www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Omissible Parentheses...

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Omissible Parentheses

Could someone remind me why we don't remove these?

So far I have
- They save typing.
- Removing them breaks backwards compatibility.
- They allow some features of properties, but with a list of limitations
and gotchas.

This is not intended to be a deep discussion.  I'm writing a piece on
properties, so I'm gathering information.
Aug 01 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 01 Aug 2009 21:04:43 +0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.
Andrei likes them.
Aug 01 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-01 13:05:26 -0400, "Denis Koroskin" <2korden gmail.com> said:

 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J  
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Omissible Parentheses
 
 Could someone remind me why we don't remove these?
 
 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.
 
 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.
Andrei likes them.
I like them too, despite their gotchas. If they were not cause for special rules when returning delegates, also classes and structs with an opCall member, I'd want to keep them. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 01 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.
Andrei likes them.
http://igsoft.net/dpolls/poll/results.php?pollid=1 http://igsoft.net/dpolls/poll/results.php?pollid=2 Andrei
Aug 01 2009
parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Denis Koroskin wrote:
 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:

 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.
Andrei likes them.
http://igsoft.net/dpolls/poll/results.php?pollid=1 http://igsoft.net/dpolls/poll/results.php?pollid=2 Andrei
If I'm not mistaken, each of those polls shows a two-to-one preference for getting rid of omissable parentheses and introducing a dedicated property syntax of some kind. --benji
Aug 01 2009
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Aug 01, 2009 at 11:49:04PM -0400, Benji Smith wrote:
http://igsoft.net/dpolls/poll/results.php?pollid=1
http://igsoft.net/dpolls/poll/results.php?pollid=2


Andrei
If I'm not mistaken, each of those polls shows a two-to-one preference for getting rid of omissable parentheses and introducing a dedicated property syntax of some kind.
They also prove that there are more than one person who are fairly happy with the current system. There might be a majority in favor of a change, but the prospects are much more iffy about there being enough votes to kill our filibuster! (I'm not sure if filibusters are common outside of American politics, so if you aren't familiar with the term, it is when someone in the US Senate debates a proposed bill non stop until the proposal just dies and nothing is changed. The filibuster can be stopped with 60 votes out of the 100 senators - something that can be a pain to get, and leads to a lot of compromise to keep the bill alive. In other words: see what happens on this newsgroup :P )
 
 --benji
-- Adam D. Ruppe http://arsdnet.net
Aug 01 2009
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 01 Aug 2009 13:05:26 -0400, Denis Koroskin <2korden gmail.com>  
wrote:

 On Sat, 01 Aug 2009 21:04:43 +0400, Chad J  
 <chadjoan __spam.is.bad__gmail.com> wrote:

 Omissible Parentheses

 Could someone remind me why we don't remove these?

 So far I have
 - They save typing.
 - Removing them breaks backwards compatibility.
 - They allow some features of properties, but with a list of limitations
 and gotchas.

 This is not intended to be a deep discussion.  I'm writing a piece on
 properties, so I'm gathering information.
Andrei likes them.
I like them too (a lot). I find they increase the clarity of my code (particularly function chaining).
Aug 01 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses. -- Michiel Helvensteijn
Aug 01 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn  
<m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Aug 01 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:
 
 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
Aug 02 2009
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
Aug 02 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
KennyTM~ wrote:

 Interesting.  I don't think I've seen this angle yet.
 
 Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
Sure, but they have parameters, so they require parentheses anyway. Robert Jacques was talking about omissible parentheses for function chaining. That would require parameter-less functions. -- Michiel Helvensteijn
Aug 02 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Michiel Helvensteijn, el  2 de agosto a las 16:25 me escribiste:
 KennyTM~ wrote:
 
 Interesting.  I don't think I've seen this angle yet.
 
 Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
Sure, but they have parameters, so they require parentheses anyway. Robert Jacques was talking about omissible parentheses for function chaining. That would require parameter-less functions.
Well, just take parameter-less functions then: " hello ".strip.toupper.replace("O", "A"); // "HELLA" (I don't know if that even compiles in D2) I think it's better to have mandatory (), though. Even when you save a couple of strokes there, I find that code way more confusing than the same with () (from that code it looks like hello has a strip property which in case have a toupper property which then have a replace method). Again, is a tradeoff between writeability and readability. I think is way more important to prioritize readability. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- - i bet microsoft's developers were on diet when they had to do win95 - microsoft has developers?
Aug 02 2009
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Leandro Lucarella wrote:

 Well, just take parameter-less functions then:
 
 " hello   ".strip.toupper.replace("O", "A"); // "HELLA"
Those would be fine candidates for read-only properties: " hello ".stripped.inupper.replace("O", "A"); -- Michiel Helvensteijn
Aug 02 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Michiel Helvensteijn, el  2 de agosto a las 20:08 me escribiste:
 Leandro Lucarella wrote:
 
 Well, just take parameter-less functions then:
 
 " hello   ".strip.toupper.replace("O", "A"); // "HELLA"
Those would be fine candidates for read-only properties: " hello ".stripped.inupper.replace("O", "A");
That looks a little better indeed =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- You look so tired-unhappy, bring down the government, they don't, they don't speak for us.
Aug 02 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 02 Aug 2009 14:02:37 -0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Michiel Helvensteijn, el  2 de agosto a las 16:25 me escribiste:
 KennyTM~ wrote:

 Interesting.  I don't think I've seen this angle yet.

 Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
Sure, but they have parameters, so they require parentheses anyway. Robert Jacques was talking about omissible parentheses for function chaining. That would require parameter-less functions.
Well, just take parameter-less functions then: " hello ".strip.toupper.replace("O", "A"); // "HELLA" (I don't know if that even compiles in D2) I think it's better to have mandatory (), though. Even when you save a couple of strokes there, I find that code way more confusing than the same with () (from that code it looks like hello has a strip property which in case have a toupper property which then have a replace method). Again, is a tradeoff between writeability and readability. I think is way more important to prioritize readability.
I think its better to prioritize readability too, it's just that to me "hello".strip.toupper; is more readable than "hello".strip().toupper();. I've long since ceased to use () on zero argument functions and have never looked back. BTW, I think you meant a strip field, since a property is just a method call with some syntactic sugar.
Aug 02 2009
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
KennyTM~ wrote:
 Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
I'm not seeing the use of function/property duals or the lack of parentheses. Am I missing it? (To be clear, I am not looking for an example of function chaining. I'd like to see why function/property duals are useful for function chaining.)
Aug 02 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 02 Aug 2009 18:30:33 +0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 KennyTM~ wrote:
 Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
I'm not seeing the use of function/property duals or the lack of parentheses. Am I missing it? (To be clear, I am not looking for an example of function chaining. I'd like to see why function/property duals are useful for function chaining.)
Stdout("Hello, World!").newline.newline.newline;
Aug 02 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Denis Koroskin wrote:
 On Sun, 02 Aug 2009 18:30:33 +0400, Chad J
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 KennyTM~ wrote:
 Chad J wrote:
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 Nope. I meant _function_ chaining. This comment comes mostly from
 using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the
 flexibility
 of function call / property duality. I've also used toggle/flag
 setting
 methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
"<p>yes?</p>".replace("<", "&lt;").replace(">", "&gt;");
I'm not seeing the use of function/property duals or the lack of parentheses. Am I missing it? (To be clear, I am not looking for an example of function chaining. I'd like to see why function/property duals are useful for function chaining.)
Stdout("Hello, World!").newline.newline.newline;
Thanks
Aug 02 2009
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-02 11:01:01 -0400, "Denis Koroskin" <2korden gmail.com> said:

 Stdout("Hello, World!").newline.newline.newline;
This syntax/wording just looks wrong to me. "newline" isn't a verb, it's more like a noun and thus should be a property, a getter in this case. But it does an action and return the stream, it's no getter at all. Completly backward. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 02 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;
Ugh. This is one of the few things about Tango that really drives me nuts. I hate all the usage of the opCall overload and non-parenthetized function calls. At first glance, that code doesn't make any sense to me. My brain just doesn't grok what's going on. It takes me a split second to mentally parse it. --benji
Aug 03 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Aug 3, 2009 at 9:26 PM, Benji Smith<dlanguage benjismith.net> wrote:
 Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;
Ugh. This is one of the few things about Tango that really drives me nuts. I hate all the usage of the opCall overload and non-parenthetized function calls.
For what it's worth, "all" the use of opCall overloads is pretty much exclusively limited to Stdout (or more generally, tango.io.stream.Format). And the omission of parens everywhere is just Kris' style. I can't read half his code because of it :P
Aug 03 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Benji Smith wrote:
 Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;
Ugh. This is one of the few things about Tango that really drives me nuts. I hate all the usage of the opCall overload and non-parenthetized function calls. At first glance, that code doesn't make any sense to me. My brain just doesn't grok what's going on. It takes me a split second to mentally parse it.
Another thing about omissable parenthesis and function calls. When you define an opCall, to use it you must write "()". That implies that to call a function you must write "()". So not writing "()" should imply a function call! -- import std.stdio; struct Bar { Foo foo; } struct Foo { int opCall() { return 1; } } void main() { Bar bar; writefln("%s", bar.foo); // prints Foo writefln("%s", bar.foo()); // prints 1 } -- Isn't that an inconsistency?
Aug 04 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig wrote:
 Benji Smith wrote:
 Denis Koroskin wrote:
 Stdout("Hello, World!").newline.newline.newline;
Ugh. This is one of the few things about Tango that really drives me nuts. I hate all the usage of the opCall overload and non-parenthetized function calls. At first glance, that code doesn't make any sense to me. My brain just doesn't grok what's going on. It takes me a split second to mentally parse it.
Another thing about omissable parenthesis and function calls. When you define an opCall, to use it you must write "()". That implies that to call a function you must write "()". So not writing "()" should imply a function call!
Oops, typo: should *not* imply a function call.
Aug 04 2009
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 02 Aug 2009 09:06:29 -0400, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
Here are two examples from a couple of days ago: auto data = (cast(string)std.file.read(filename)).chomp.split; set_colour.uses = (new Texture!float4(mod,"TRANSFER", tranfer_data)).normalize.clamp.linear; I'd also point out 'uses' is overloaded with a variadic version: CCK_engine.uses( iCCK, a_p, a_p2, a_t); There were also a bunch of std.algorithm examples in the newsgroup back with the new phobos was launched. (Though this only works for arrays)
Aug 02 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Robert Jacques wrote:
 On Sun, 02 Aug 2009 09:06:29 -0400, Chad J
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Robert Jacques wrote:
 Nope. I meant _function_ chaining. This comment comes mostly from using
 std.string and std.algorithm, whose functions don't behave as fields.
 Both of these libraries show off the power you get from the flexibility
 of function call / property duality. I've also used toggle/flag setting
 methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
Here are two examples from a couple of days ago: auto data = (cast(string)std.file.read(filename)).chomp.split; set_colour.uses = (new Texture!float4(mod,"TRANSFER", tranfer_data)).normalize.clamp.linear; I'd also point out 'uses' is overloaded with a variadic version: CCK_engine.uses( iCCK, a_p, a_p2, a_t); There were also a bunch of std.algorithm examples in the newsgroup back with the new phobos was launched. (Though this only works for arrays)
Thank you.
Aug 02 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Sun, 02 Aug 2009 09:06:29 -0400, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Robert Jacques wrote:
 On Sat, 01 Aug 2009 16:00:52 -0400, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:

 Robert Jacques wrote:

 I like them too (a lot). I find they increase the clarity of my code
 (particularly function chaining).
I think that when you find you need to use function-chaining, the functions (except possibly the rightmost) are often meant to be properties/fields. That's why they would look more natural without parentheses.
Nope. I meant _function_ chaining. This comment comes mostly from using std.string and std.algorithm, whose functions don't behave as fields. Both of these libraries show off the power you get from the flexibility of function call / property duality. I've also used toggle/flag setting methods in this way. It's concise, clean and very understandable.
Interesting. I don't think I've seen this angle yet. Could you provide code examples, please?
Here are two examples from a couple of days ago: auto data = (cast(string)std.file.read(filename)).chomp.split;
BTW now Phobos has auto data = std.file.readText(filename).chomp.split; Andrei
Aug 02 2009