www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new DIP5: Properties 2

reply Kagamin <spam here.lot> writes:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5

As namespaces were proposed, a variant of them is in DIP5 now.
Jul 27 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Kagamin wrote:
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5
 
 As namespaces were proposed, a variant of them is in DIP5 now.

Oh dear, here we go. Let's all create our own DIPs as slight variations of existing ones when we disagree instead of actually working together! Is there ANY reason this couldn't have been put into DIP4 as an alternative solution? This isn't even an objective proposal... "Parts of DIP4 are too puristic and as a consequence - insane." No objective reasoning given; just calling DIP4 "insane." "Default storage is not a big deal to be so anal about it." That's subjective. You then go on to admit that you need trivial properties for interfaces, yet completely discount that use case. "The {get;set;} syntax exists in C# only for reflection purposes..." No, I'm pretty sure it exists because interfaces can't have fields, and most accessors are trivial. This is *exactly* why I said DIPs need to have some form of editorial control.
Jul 27 2009
next sibling parent reply Kagamin <spam here.lot> writes:
Daniel Keep Wrote:

 Let's all create our own DIPs as slight variations of existing ones when
 we disagree instead of actually working together!

People draw their proposals, they are criticised and new proposals are drawn. This is how discussion works.
 Is there ANY reason this couldn't have been put into DIP4 as an
 alternative solution?

I didn't thought it's meant to work this way.
 This isn't even an objective proposal...
 
 "Parts of DIP4 are too puristic and as a consequence - insane."  No
 objective reasoning given; just calling DIP4 "insane."

Yeah, it may lack political correctness.
Jul 27 2009
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Kagamin wrote:
 Daniel Keep Wrote:
 
 Let's all create our own DIPs as slight variations of existing ones when
 we disagree instead of actually working together!

People draw their proposals, they are criticised and new proposals are drawn. This is how discussion works.

Yes, but discussions should take place in this group, not on the DIP page. That said, I think DIP4 was launched too early, while the "properties" discussion was still going very strong. -Lars
Jul 27 2009
parent Kagamin <spam here.lot> writes:
Lars T. Kyllingstad Wrote:

 Yes, but discussions should take place in this group, not on the DIP 
 page. That said, I think DIP4 was launched too early, while the 
 "properties" discussion was still going very strong.

I think, it's years since there was no progress in the properties discussion.
Jul 27 2009
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Daniel Keep wrote:
 Kagamin wrote:
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5

 As namespaces were proposed, a variant of them is in DIP5 now.

Oh dear, here we go. Let's all create our own DIPs as slight variations of existing ones when we disagree instead of actually working together! Is there ANY reason this couldn't have been put into DIP4 as an alternative solution? This isn't even an objective proposal... "Parts of DIP4 are too puristic and as a consequence - insane." No objective reasoning given; just calling DIP4 "insane." "Default storage is not a big deal to be so anal about it." That's subjective. You then go on to admit that you need trivial properties for interfaces, yet completely discount that use case. "The {get;set;} syntax exists in C# only for reflection purposes..." No, I'm pretty sure it exists because interfaces can't have fields, and most accessors are trivial. This is *exactly* why I said DIPs need to have some form of editorial control.

Agreed. There are problems with most of the DIPs already: DIP3 is way too brief. The Rationale is just one sentence, stating simply that "[...] leads to strange behaviour", full stop. DIP4 was created at too early a stage in the discussion. (That said, it is probably the most well written one, with a good rationale section and a comprehensive list of pros and cons.) DIP5 is too brief, written in a very subjective style, and -- most importantly -- unnecessary, as it's just a "reply" to DIP4. DIP5 reads like an NG post. (Regarding DIP3: I posted the above critique in the DIP3 thread, but it was ignored. Indeed, DIP3 seems abandoned by its author, since it hasn't been updated after its announcement.) -Lars
Jul 27 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
 This is *exactly* why I said DIPs need to have some form of editorial
 control.

I agree. DIPs shouldn't just be "newsgroup postings with higher exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 This is *exactly* why I said DIPs need to have some form of editorial
 control.

I agree. DIPs shouldn't just be "newsgroup postings with higher exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

I agree. That bureaucracy should be community-enforced; Walter and I lack the resources to add to organizing DIPs, though we'd be glad to try them. Andrei
Jul 27 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 grauzone wrote:
 This is *exactly* why I said DIPs need to have some form of editorial
 control.

I agree. DIPs shouldn't just be "newsgroup postings with higher exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

I agree. That bureaucracy should be community-enforced; Walter and I lack the resources to add to organizing DIPs, though we'd be glad to try them. Andrei

I'm coming to the sad conclusion that DIPs will be as ineffective as bugzilla. I haven't seen Walter voice an opinion on any DIP so far. We desperately need to get a DIP through a full cycle. Has anything gotten past the draft stage?
Jul 27 2009
next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 grauzone wrote:
 This is *exactly* why I said DIPs need to have some form of editorial
 control.

exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

lack the resources to add to organizing DIPs, though we'd be glad to try them. Andrei

I'm coming to the sad conclusion that DIPs will be as ineffective as bugzilla. I haven't seen Walter voice an opinion on any DIP so far. We desperately need to get a DIP through a full cycle. Has anything gotten past the draft stage?

DIP2 is the place to start, then: - it is well justified and has a good description - it is linked to a bug which has many votes - it was generally well received on the NG - it has been updated several times, and by more than one person I think it deserves a comment from Walter. -Lars
Jul 27 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Andrei Alexandrescu Wrote:
 
 grauzone wrote:
 This is *exactly* why I said DIPs need to have some form of editorial
 control.

exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

lack the resources to add to organizing DIPs, though we'd be glad to try them. Andrei

I'm coming to the sad conclusion that DIPs will be as ineffective as bugzilla.

Why do you assume bugzilla is ineffective? I think it's a lifesaver.
 I haven't seen Walter voice an opinion on any DIP so far. We desperately need
to get a DIP through a full cycle. Has anything gotten past the draft stage?

Walter is cautiously optimistic about DIP. He'd be as happy to give them a try as anyone else. Andrei
Jul 27 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 27 de julio a las 08:45 me escribiste:
I haven't seen Walter voice an opinion on any DIP so far. We desperately need 
to get a DIP through a full cycle. Has anything gotten past the draft stage?

Walter is cautiously optimistic about DIP. He'd be as happy to give them a try as anyone else.

I really don't get why Walter can't speak for himself. No offense, but it's a little weird when you (or others) speak for him as some kind of ambassador. Is not that hard to show some interest by himself, really. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Hey you, out there beyond the wall, Breaking bottles in the hall, Can you help me?
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 08:45 me escribiste:
 I haven't seen Walter voice an opinion on any DIP so far. We desperately need 
 to get a DIP through a full cycle. Has anything gotten past the draft stage?

as anyone else.

I really don't get why Walter can't speak for himself. No offense, but it's a little weird when you (or others) speak for him as some kind of ambassador. Is not that hard to show some interest by himself, really.

If this were a pattern, I'd agree. But it's an isolated event. Andrei
Jul 27 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 27 de julio a las 09:41 me escribiste:
 Leandro Lucarella wrote:
Andrei Alexandrescu, el 27 de julio a las 08:45 me escribiste:
I haven't seen Walter voice an opinion on any DIP so far. We desperately need 
to get a DIP through a full cycle. Has anything gotten past the draft stage?

as anyone else.

it's a little weird when you (or others) speak for him as some kind of ambassador. Is not that hard to show some interest by himself, really.

If this were a pattern, I'd agree. But it's an isolated event.

At least for DIPs, it was a pattern =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- - Mire, don Inodoro! Una paloma con un anillo en la pata! Debe ser mensajera y cayó aquí! - Y... si no es mensajera es coqueta... o casada. -- Mendieta e Inodoro Pereyra
Jul 27 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el 27 de julio a las 08:45 me escribiste:
 I haven't seen Walter voice an opinion on any DIP so far. We 
 desperately need to get a DIP through a full cycle. Has anything 
 gotten past the draft stage?

them a try as anyone else.

I really don't get why Walter can't speak for himself. No offense, but it's a little weird when you (or others) speak for him as some kind of ambassador. Is not that hard to show some interest by himself, really.

If this were a pattern, I'd agree. But it's an isolated event.

Andrei can speak for me on this. We've talked about this, and we're in full agreement.
Jul 27 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 27 de julio a las 12:45 me escribiste:
 Andrei Alexandrescu wrote:
Leandro Lucarella wrote:
Andrei Alexandrescu, el 27 de julio a las 08:45 me escribiste:
I haven't seen Walter voice an opinion on any DIP so far. We desperately 
need to get a DIP through a full cycle. Has anything gotten past the draft 
stage?

try as anyone else.

I really don't get why Walter can't speak for himself. No offense, but it's a little weird when you (or others) speak for him as some kind of ambassador. Is not that hard to show some interest by himself, really.


Andrei can speak for me on this. We've talked about this, and we're in full agreement.

... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
Jul 28 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu Wrote:
 Walter is cautiously optimistic about DIP. He'd be as happy to give them 
 a try as anyone else.

One difference between Python PEPs and D DIPs is that people that write a PEP sometimes have written an implementation of the requested new feature. Bye, bearophile
Jul 27 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 27 de julio a las 07:34 me escribiste:
 grauzone wrote:
This is *exactly* why I said DIPs need to have some form of editorial
control.

least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

I agree. That bureaucracy should be community-enforced; Walter and I lack the resources to add to organizing DIPs, though we'd be glad to try them.

I think I could be some kind of editor *if* there is some official status for DIPs. I don't want to spend time and effort in some parallel world where nothing materializes. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- The average person laughs 13 times a day
Jul 27 2009
prev sibling parent reply Kagamin <spam here.lot> writes:
grauzone Wrote:

 This is *exactly* why I said DIPs need to have some form of editorial
 control.

I agree. DIPs shouldn't just be "newsgroup postings with higher exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

You already have spec for that purpose. No one prevents you from getting something into it right from NG. NG posts just go in vain. They say Andrei described some problem with properties, but that post is buried somewhere out there. As a result the community lacks communication and almost everyone remain nearly uninformed repeating the same thoughts again and again. Or some problems can even get forgotten in the same way. That's the very purpose of dips - to crystallize proposals in more or less integral and thought-through form. Even failing proposals help exposing problems which will help to come with a better proposals. This can't be done in NG, I think. If dip5 is as bad as opGet_foo is I'll delete it right now.
Jul 27 2009
next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Kagamin, el 27 de julio a las 09:57 me escribiste:
 grauzone Wrote:
 
 This is *exactly* why I said DIPs need to have some form of editorial
 control.

I agree. DIPs shouldn't just be "newsgroup postings with higher exposure". At least we'd need a higher entry barrier, like some checking for formal requirements. Yay for bureaucracy.

You already have spec for that purpose. No one prevents you from getting something into it right from NG. NG posts just go in vain. They say Andrei described some problem with properties, but that post is buried somewhere out there. As a result the community lacks communication and almost everyone remain nearly uninformed repeating the same thoughts again and again. Or some problems can even get forgotten in the same way. That's the very purpose of dips - to crystallize proposals in more or less integral and thought-through form. Even failing proposals help exposing problems which will help to come with a better proposals. This can't be done in NG, I think.

You are right about most of this, but an issue should be addresses just by *one* DIP. If there are some alternative solutions for that issue, they should be presented as alternatives in the *same* DIP. Alternative should have some consensus, though; there is no point to have as many alternatives as people in this group. If this weren't true, they would be as many DIPs as posts in this NG and the DIPs would get lost as easily as a NG post. The idea is to centralize the information about an issue in one DIP, not to distribute it, so one can easily go through a DIP and see all the alternatives and why one won over another in *one* place.
 If dip5 is as bad as opGet_foo is I'll delete it right now.

I think DIP5 should be removed, no matter how good or bad it is. If the DIP has some consensus here, then somebody should add it to DIP4 as an alternative. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- If you do not change your beliefs Your life will always be like this
Jul 27 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:
 You are right about most of this, but an issue should be addresses just by
 *one* DIP. If there are some alternative solutions for that issue, they
 should be presented as alternatives in the *same* DIP.

Thank you for your work on explaining how to use DIPs and on the purposes of what a useful tuple has to do. Bye, bearophile
Jul 27 2009
parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 27 de julio a las 10:23 me escribiste:
 Leandro Lucarella:
 You are right about most of this, but an issue should be addresses just by
 *one* DIP. If there are some alternative solutions for that issue, they
 should be presented as alternatives in the *same* DIP.

Thank you for your work on explaining how to use DIPs and on the purposes of what a useful tuple has to do.

You're welcome. (!?) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Pack and get dressed before your father hears us, before all hell breaks loose.
Jul 27 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el 27 de julio a las 11:15 me escribiste:
 If dip5 is as bad as opGet_foo is I'll delete it right now.

I think DIP5 should be removed, no matter how good or bad it is. If the DIP has some consensus here, then somebody should add it to DIP4 as an alternative.

And BTW, *please* add an author to the proposal! -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- More people die from a champagne-cork popping, than from poison spiders
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Leandro Lucarella, el 27 de julio a las 11:15 me escribiste:
 If dip5 is as bad as opGet_foo is I'll delete it right now.

DIP has some consensus here, then somebody should add it to DIP4 as an alternative.

And BTW, *please* add an author to the proposal!

It might be good to define a sort of an ombudsman for any given DIP. The ombudsman would collect suggestions by email or NG and fold the relevant ones in the DIP text. Andrei
Jul 27 2009
parent Jesse Phillips <jessekphillips+d gmail.com> writes:
Bill Baxter Wrote:

 I think it might also be good to have a two-tier system.   "DIPs in
 training" can be made by anyone on the wiki.  And then after some
 period of discussion, editing, and perhaps an informal community vote,
 *then* they can earn the official title of DIP and be moved to a
 different section of the wiki for DIPs that have significant community
 support.  Or at least which are agreed to surpass some minimal
 editorial threshold.  I think this could help prevent DIPs from
 turning into a Wiki form of the Eigenpoll.
 
 --bb

I think this can be accomplished by having other pages that reference no longer Draft proposals, e.g. Pending and Approved. http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/Approved http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/Pending I thought this could be automated using folders, but that is not the case.
Jul 27 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Kagamin wrote:
 If dip5 is as bad as opGet_foo is I'll delete it right now.

What's wrong with opGet_foo? I like it better than any of the proposed new syntaxes for properties: - It keeps the language simple by not adding more syntactic clutter. - In the (very common) case of calculated read-only properties, opGet_foo means less typing. - With opGet_foo, the semantics of overriding properties in subclasses are obvious. You can override just the getter, just the setter, or even just one setter of many. You might also be able to do this with a dedicated syntax, but it's a lot less obvious. -- Rainer Deyke - rainerd eldwood.com
Jul 27 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Rainer Deyke wrote:
 Kagamin wrote:
 If dip5 is as bad as opGet_foo is I'll delete it right now.

What's wrong with opGet_foo? I like it better than any of the proposed new syntaxes for properties: - It keeps the language simple by not adding more syntactic clutter. - In the (very common) case of calculated read-only properties, opGet_foo means less typing. - With opGet_foo, the semantics of overriding properties in subclasses are obvious. You can override just the getter, just the setter, or even just one setter of many. You might also be able to do this with a dedicated syntax, but it's a lot less obvious.

This seems to me like it adds more syntactic clutter than adding a keyword would: PropertyDecl: PropertyGetter PropertySetter PropertyGetter: Type 'opGet_' Identifier '(' ')' PropertySetter: Type 'opSet_' Identifier '(' Type ')' Unfortunately, this grammar is wrong. It needs to be more complicated. That's because there is no whitespace between 'opGet_' and Identifier or between 'opSet_' and Identifier. This is very unusual since just about any other pair of tokens in the language is separated by either optional or mandatory whitespace (AFAIK). I understand that opGet_XX and opSet_XX are supposed to be parsed as function declarations or somesuch, but I somehow get the feeling that it won't fly. It seems to me like that just makes the semantic analysis do some of the parsing work. That's because the semantic analyzer now has to pull apart the op(G|S)et_ from the Identifier and declare a property with that identifier as its name. That step has to be done at some point and it seems like parsing would be the more appropriate phase for it.
Jul 27 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Jarrett Billingsley wrote:
 On Mon, Jul 27, 2009 at 4:34 PM, Chad
 J<chadjoan __spam.is.bad__gmail.com> wrote:
 
 Nono, I don't think that's really what's being suggested.  It'd work
 more like operator overloading.  "opAdd" and the like aren't parsed
 any different from any other functions, and they're not represented
 differently inside the compiler; they're just functions with "magical"
 names.  Similarly, opGet_foo would be a normal function in any way,
 and its name would only be significant in the case of "obj.foo", which
 *could* be rewritten as "obj.opGet_foo()" (or "obj.opSet_foo").
 

Op overloading is a bit different since the identifier never changes. What you are matching is always one of opAdd, opSub, opNeg, etc. But when matching this there are an infinite number of permutations: opGet_foo, opGet_bar, opGet__, opGet_a, ..., opGet_aa, opGet_ab, etc. I'm not saying it's hard to do, just that it looks to me like it defeats its own virtues.
 Also, if you think D can be parsed without any information from the
 semantic pass?  I've got news for you..

Yeah, that's still not a good reason to make a bad thing worse :/
Jul 27 2009
prev sibling next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
 On Mon, Jul 27, 2009 at 4:34 PM, Chad
 This seems to me like it adds more syntactic clutter than adding a
 keyword would:

 PropertyDecl:
        PropertyGetter
        PropertySetter

 PropertyGetter:
        Type 'opGet_' Identifier '(' ')'

 PropertySetter:
        Type 'opSet_' Identifier '(' Type ')'


Jarrett Billingsley wrote:
 Nono,

<snip>
 they're just functions with "magical" names.

I agree with Chad. The opGet_Xxxxx syntax is terrible, with both syntactic and semantic clutter. To whit: 1) This convention has four syntactic parts: "op", "Get|Set", "_", and an identifier. Adding a new keyword (like "property") would only add one syntactic element to the declaration. 2) A property is not an operator. So the "op" prefix is lying to you. 3) The existence of "magical" identifiers complicates the language design. Because the rules that apply to those magical identifiers is different than the rules applying to non-magical identifiers. There's nothing wrong with the mechanics of the proposal. I especially like how it allows the getter/setter to have different protection attributes, and that it allows each function to be overridden separately. You could even implement the getter in a read-only superclass and implement the setter in a read-write subclass. Nice! But I think the same thing can be more elegantly written using the "property" keyword: private int _x; public property int X() { return _x; } protected property X(int value) { _x = value; } The only disadvantage I see there is the introduction of a keyword. And that's definitely a disadvantage. But, compared to the "op" syntax, I think it's the lesser of two evils. --benji
Jul 27 2009
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language
 design. Because the rules that apply to those magical identifiers is
 different than the rules applying to non-magical identifiers.

I don't see how that's the case. Everywhere opGet_foo appears, it is treated exactly like every other identifier. The only thing "special" about these identifiers is that they can be generated automatically by the compiler. When the compiler sees 'a.b', and 'b' is not a field or method of 'a', it rewrites this to 'a.opGet_b()'. -- Rainer Deyke - rainerd eldwood.com
Jul 27 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:
 Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language
 design. Because the rules that apply to those magical identifiers is
 different than the rules applying to non-magical identifiers.

I don't see how that's the case. Everywhere opGet_foo appears, it is treated exactly like every other identifier. The only thing "special" about these identifiers is that they can be generated automatically by the compiler. When the compiler sees 'a.b', and 'b' is not a field or method of 'a', it rewrites this to 'a.opGet_b()'.

Oh. You stole my thunder. +1 Adnrei
Jul 27 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Mon, Jul 27, 2009 at 11:13 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Rainer Deyke wrote:
 Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language
 design. Because the rules that apply to those magical identifiers is
 different than the rules applying to non-magical identifiers.

treated exactly like every other identifier. The only thing "special" about these identifiers is that they can be generated automatically by the compiler. When the compiler sees 'a.b', and 'b' is not a field or method of 'a', it rewrites this to 'a.opGet_b()'.

+1

While the opGet_foo and opSet_foo are okay, what are your thoughts on the 'property' attribute on a function?

My opinion? I'd like to render it unnecessary.
 I know you said you didn't
 really like the idea of having to name your range's empty function
 'opGet_empty'.

Correct. I'd rather try to disambiguate the rather rare case when a property returns a delegate etc. For me, I get a breath of fresh air whenever I get to not write "()". I can't figure how some are missing it.
 The property attribute also has the nice property
 (heh) that you can call the property setters and getters either as
 properties or as functions (i.e. "r.empty" or "r.empty()").
 Basically, the behavior would be *exactly* as it is now, except you'd
 have to explicitly state with which functions it would be legal.

I guess I'd rather not have to specify that. I'd do that on all of my functions that don't take parameters. To me that's syntactic noise and an unnecessary special case.
 Or is the idea of introducing the 'property' keyword too controversial?

In this case the keyword isn't even the largest aggravation. The largest aggravation is that everybody is with their hand on the syntactic holster when they should look into simplifying and unifying, not adding more baroque adornments for what is really some function calls. Andrei
Jul 27 2009
next sibling parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 I know you said you didn't
 really like the idea of having to name your range's empty function
 'opGet_empty'.

Correct. I'd rather try to disambiguate the rather rare case when a property returns a delegate etc. For me, I get a breath of fresh air whenever I get to not write "()". I can't figure how some are missing it.

It's agains C look and feel to call function without braces. It's not a problem to write code. It's a problem to read and understand it, isn't it? Isn't current programming techniques development aimed to ease maintenance?
 The property attribute also has the nice property
 (heh) that you can call the property setters and getters either as
 properties or as functions (i.e. "r.empty" or "r.empty()").
 Basically, the behavior would be *exactly* as it is now, except you'd
 have to explicitly state with which functions it would be legal.

I guess I'd rather not have to specify that. I'd do that on all of my functions that don't take parameters. To me that's syntactic noise and an unnecessary special case.

r.empty returns an empty instance of a range (especially makes sense for dummy objects). r.empty() empties the range. It's not quite good if your code has such an ambiguity.
Jul 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 I know you said you didn't really like the idea of having to name
 your range's empty function 'opGet_empty'.

property returns a delegate etc. For me, I get a breath of fresh air whenever I get to not write "()". I can't figure how some are missing it.

It's agains C look and feel to call function without braces. It's not a problem to write code. It's a problem to read and understand it, isn't it? Isn't current programming techniques development aimed to ease maintenance?

Well there are quite a few other things that are arguably against C look and feel, such as the scope statement. I've never had a problem understanding code because of lacking "()", and I never ever write them.
 The property attribute also has the nice property (heh) that you
 can call the property setters and getters either as properties or
 as functions (i.e. "r.empty" or "r.empty()"). Basically, the
 behavior would be *exactly* as it is now, except you'd have to
 explicitly state with which functions it would be legal.

my functions that don't take parameters. To me that's syntactic noise and an unnecessary special case.

r.empty returns an empty instance of a range (especially makes sense for dummy objects). r.empty() empties the range. It's not quite good if your code has such an ambiguity.

Actually r.empty() does not empty the range :o). Andrei
Jul 28 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Bill Baxter wrote:
 On Tue, Jul 28, 2009 at 6:54 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Well there are quite a few other things that are arguably against C look and
 feel, such as the scope statement. I've never had a problem understanding
 code because of lacking "()", and I never ever write them.

That may be true, but you are also not an average user by any means. So surveying yourself may not give so accurate a reflection of opinions at large. Like Joel Spoelsky and others say about GUIs -- never take your own opinion that a GUI you have written is "intuitive". You need to do at a minimum a couple of random "hallway checks" -- that is, getting random people passing by in the hallway to try it out without explaining it to them. So far I think we have two people -- you and Walter -- who think that the current system is good. I think you're right that people *can* get used to losing the visual distinction between functions and fields. But I find the distinction to be a useful and unobtrusive indication of the programmer's intent. So I don't see losing the distinction to be worth saving a few keystrokes. If there were a distinction then we could be pretty sure that .empty was a property and .empty() was an action. Sure I can get used to having to learn which is which on a per-library basis, but I don't see why I should consider having to keep more stuff in my head to be a net win. In fact I'm kind of envious of those languages where ? and ! can by used in identifiers to indicate predicates and mutators. For the same reason I started to dislike like the direction some of these syntax proposals were taking. Too much for me to keep in my head. But the "property { ... }" syntax is very easy to remember and doesn't look ugly. Look, if we add a generic attributes syntax (like attr) we could perhaps use it for many of the following: abstract deprecated align case debug default export extern final lazy override package private protected public scope shared unittest volitile Storage classes are, in particular, kinds of attributes of a type. Now we may not want to go so hog wild putting this and that everywhere, but if we did we could get rid of 19 keywords right there, and add property also without adding a new keyword.

Definitely. I think attributes/annotations is the best solution for this. It's also the most extensible way to do it. The lexer and parser doesn't need to change for each new attribute. Maybe just the semantic pass.
Jul 28 2009
parent reply Arthur Lloyd <via google.com> writes:
Ary Borenszweig Wrote:

 Definitely. I think attributes/annotations is the best solution for 
 this. It's also the most extensible way to do it. The lexer and parser 
 doesn't need to change for each new attribute. Maybe just the semantic pass.

That's ingenious. No need to change the lexer and parser when adding new "semi-keywords" and functionality. Since Java existed before C#, apparently this is something that Sun invented?
Jul 28 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Arthur Lloyd wrote:
 Ary Borenszweig Wrote:
 
 Definitely. I think attributes/annotations is the best solution for 
 this. It's also the most extensible way to do it. The lexer and parser 
 doesn't need to change for each new attribute. Maybe just the semantic pass.

That's ingenious. No need to change the lexer and parser when adding new "semi-keywords" and functionality. Since Java existed before C#, apparently this is something that Sun invented?

I think C# added them first, then Java added them too. But Java and C# copied a lot of things from each other in different orders. :)
Jul 28 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 I know you said you didn't really like the idea of having to name
 your range's empty function 'opGet_empty'.

property returns a delegate etc. For me, I get a breath of fresh air whenever I get to not write "()". I can't figure how some are missing it.

It's agains C look and feel to call function without braces. It's not a problem to write code. It's a problem to read and understand it, isn't it? Isn't current programming techniques development aimed to ease maintenance?

Well there are quite a few other things that are arguably against C look and feel, such as the scope statement. I've never had a problem understanding code because of lacking "()", and I never ever write them.
 The property attribute also has the nice property (heh) that you
 can call the property setters and getters either as properties or
 as functions (i.e. "r.empty" or "r.empty()"). Basically, the
 behavior would be *exactly* as it is now, except you'd have to
 explicitly state with which functions it would be legal.

my functions that don't take parameters. To me that's syntactic noise and an unnecessary special case.

r.empty returns an empty instance of a range (especially makes sense for dummy objects). r.empty() empties the range. It's not quite good if your code has such an ambiguity.

Actually r.empty() does not empty the range :o). Andrei
Jul 28 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I 
 can't figure how some are missing it.

Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.
Jul 28 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I 
 can't figure how some are missing it.

Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.

Hmmm... It seems like we're not seeing eye to eye on this :o). Andrei
Jul 28 2009
parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h4mvve$2g5j$3 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I 
 can't figure how some are missing it.

Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.

Hmmm... It seems like we're not seeing eye to eye on this :o).

Guess not ;)
Jul 28 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I 
 can't figure how some are missing it.

Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.

My thoughts exactly. --benji
Jul 30 2009
next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:

 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I 
 can't figure how some are missing it.

Every time I call a parameterless function in D, I curse under my breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.

My thoughts exactly.

+1
Jul 31 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:
 
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I 
 can't figure how some are missing it.

how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.


+1

Maybe we should vote on this too. BTW, seems like the last poll wasn't quite the expected landslide against the dictature :o). Andrei
Jul 31 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Fri, 31 Jul 2009 20:13:55 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Sergey Gromov wrote:
 Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:

 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in 
 message news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write 
 "()". I can't figure how some are missing it.

breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.



Maybe we should vote on this too. BTW, seems like the last poll wasn't quite the expected landslide against the dictature :o). Andrei

I believe that poll question was badly formulated.

I believe the same, but I also believe that in all likelihood the poor formulation didn't influence the vote by a lot: the question was only visible to participants in that thread so there's no risk that people lacking the background discussion would come and vote in confusion. Andrei
Jul 31 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 12:13:55 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Maybe we should vote on this too. BTW, seems like the last poll wasn't 
 quite the expected landslide against the dictature :o).

I think the poll might have been skewed due to context (forget my newsgroup poll, that was worthy of an abortion, but I also didn't mean to submit it :), I'm talking about Ary's) The question was asked, what do you think this code means. In the context of D, where you know a symbol without parentheses can mean either a function or a property/field, I'm certain there were several respondants who didn't understand it was asking what they think is best, not *what D currently does*. Ask that same questions to C++ developers and see what you get... It's hard to phrase the question properly without bias to a group of people who already know the current behavior. Maybe something like: Assume the D programming language required parentheses for normal parameter-less functions, and required no parentheses for parameter-less functions that returned a property. For example, the following code should imply a getter for a filter inside x: auto tmp = x.filter; And the following code should imply performing a filtering action using x, returning the result: auto tmp = x.filter(); Do you think it's worth adding such a capability, given that you will then no longer be able to call ordinary parameter-less functions without parentheses, an author of a property function must properly indicate that the function is a property, and the compiler must trust the author for this implication?

There's one way to figure it out: Ask away! Andrei
Jul 31 2009
prev sibling next sibling parent reply Marianne Gagnon <auria.mg gmail.com> writes:
 
 I think the poll might have been skewed due to context (forget my  
 newsgroup poll, that was worthy of an abortion, but I also didn't mean to  
 submit it :), I'm talking about Ary's)
 
 The question was asked, what do you think this code means.  In the context  
 of D, where you know a symbol without parentheses can mean either a  
 function or a property/field, I'm certain there were several respondants  
 who didn't understand it was asking what they think is best, not *what D  
 currently does*.  Ask that same questions to C++ developers and see what  
 you get...
 
 It's hard to phrase the question properly without bias to a group of  
 people who already know the current behavior.  Maybe something like:
 
 Assume the D programming language required parentheses for normal  
 parameter-less functions, and required no parentheses for parameter-less  
 functions that returned a property.  For example, the following code  
 should imply a getter for a filter inside x:
 
      auto tmp = x.filter;
 
 And the following code should imply performing a filtering action using x,  
 returning the result:
 
      auto tmp = x.filter();
 
 Do you think it's worth adding such a capability, given that you will then  
 no longer be able to call ordinary parameter-less functions without  
 parentheses, an author of a property function must properly indicate that  
 the function is a property, and the compiler must trust the author for  
 this implication?
 

IMP, the parenthesis thing is not about parameters vs function. I think the question is about whether the function can modify my object or not. e.g. if I call foo = object.x; I assume 'object' was not modified. But if x can be like a function, disguised as a parameter, I can modify my object without knowing. In C++, I'd say this behaviour is ok for 'const' functions. Now I haven't taken the time to study D constness, so I can't readily tell what is the direct equivalent, but I guess you understand what I mean. In short, IMO everything that can modify my object should require () to stress that this is an action with possible side effects, not merely a getter.
Jul 31 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 13:34:13 -0400, Marianne Gagnon <auria.mg gmail.com> 
 wrote:
 
 I think the poll might have been skewed due to context (forget my
 newsgroup poll, that was worthy of an abortion, but I also didn't 
 mean to
 submit it :), I'm talking about Ary's)

 The question was asked, what do you think this code means.  In the 
 context
 of D, where you know a symbol without parentheses can mean either a
 function or a property/field, I'm certain there were several respondants
 who didn't understand it was asking what they think is best, not *what D
 currently does*.  Ask that same questions to C++ developers and see what
 you get...

 It's hard to phrase the question properly without bias to a group of
 people who already know the current behavior.  Maybe something like:

 Assume the D programming language required parentheses for normal
 parameter-less functions, and required no parentheses for parameter-less
 functions that returned a property.  For example, the following code
 should imply a getter for a filter inside x:

      auto tmp = x.filter;

 And the following code should imply performing a filtering action 
 using x,
 returning the result:

      auto tmp = x.filter();

 Do you think it's worth adding such a capability, given that you will 
 then
 no longer be able to call ordinary parameter-less functions without
 parentheses, an author of a property function must properly indicate 
 that
 the function is a property, and the compiler must trust the author for
 this implication?

IMP, the parenthesis thing is not about parameters vs function. I think the question is about whether the function can modify my object or not. e.g. if I call foo = object.x; I assume 'object' was not modified. But if x can be like a function, disguised as a parameter, I can modify my object without knowing. In C++, I'd say this behaviour is ok for 'const' functions. Now I haven't taken the time to study D constness, so I can't readily tell what is the direct equivalent, but I guess you understand what I mean. In short, IMO everything that can modify my object should require () to stress that this is an action with possible side effects, not merely a getter.

Hm... this is somewhat similar to const, be we already have const in D. I think you and I or on the same page -- parentheses implies action, no parentheses implies no action (and therefore, no change to the object). However, I can envision properties that do take actions (such as logging) and may even change the object (such as caching), and functions that perform actions but do not modify the object. I wouldn't say modification of the object is a direct 1-to-1 mapping with parens or lack of parens, but I'd definitely say that lack of parens implies no "public" modification. However, none of this would be enforcible via the compiler. For that, we have const. A const property would make loads of sense, but unfortunately, it modifies the contract you have with the object members when calling it (see DIP2 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2). So to sum up, with this feature lack of parentheses would imply no action, but would not be enforced. However, it would be considered incorrect logic if the rule was not followed, similar to naming your functions something other than what they do.

I am leery of such a feature. It essentially introduces a way to define conventions that are in no way useful to, or checked by, language rules. In my experience this has been a bad idea more often than not. Of course, simple conventions such as capitalized types, camel case values, and so on, are useful and easy to follow. But as soon as complexity of conventions becomes only a bit higher, their usefulness becomes a downward step function. In C++ there were two ways to define a template: template <class T> ... and template <typename T> ... The existence of "typename" as a keyword has an interesting history of its own, but in here it was allowed for the reason that T may be any type, not a class type. So, people thought, it would be less confusing if people wrote "typename" for type template parameters. So far so good. When I wrote Modern C++ Design, I decided to make a bold move and use "typename" in code samples wherever it could have been any type, and "class" wherever the type was indeed restricted to a class type. I documented that convention in the introduction and off I went. The experiment was an unqualified failure. First of all, people got confused. Then some found actual "bugs" because I used one keyword when I had promised to use the other. Of course I had bugs - there's plenty of template code and no automated means to check it! If I could turn back in time, I'd just use "class" everywhere. There are similar cases in other communities, probably Perl being a prime example because it allows most everything to mean something, so conventions are very important. My reading of the experience on espousing complex, unchecked, and unused reified conventions? Don't. Andrei
Jul 31 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 Hm... in C++, I don't think that convention is checked at all.  For 
 example, I can do template<class T> and specify int as the T, and 
 everything compiles.

Yah.
 But in the case of properties only allowed without parens, functions 
 require parens, you are defining a rule for the compiler.  Think of the 
 parentheses as an extension of the function name, like punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.
 Like the word "so":
 
 so!
 so?

so? :o)
 Two different meanings, same word.   Analogously to our property
 discussion, the compiler can know that one is an exclamation, and one is 
 a question, but doesn't really know the meaning of "so!" or "so?".  It 
 can enforce that you use a question where a question is needed, and an 
 exclamation where an exclamation is needed.
 
 But a person sees it immediately and understands the difference in the 
 implied meaning.  The parens-means-function and 
 lack-of-parens-means-field convention is well well established (except 
 for D) as something that works, I don't think you would have the same 
 confusion as your typename/class example.

Maybe less confusion, definitely more burden. Andrei
Jul 31 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 But in the case of properties only allowed without parens, functions 
 require parens, you are defining a rule for the compiler.  Think of 
 the parentheses as an extension of the function name, like punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.

But we already have sheer unchecked convention! I could make a function called sort that reverses an array.

Of course we do. My point is that there's no need to add gratuitous mechanisms fostering conventions that go unchecked.
 I don't get why it makes any 
 difference to you that the meaning of parentheses and no parentheses is 
 used by the author of the function.  How is this bad or somehow worse 
 than what we have now?  If you don't trust the author's functions do 
 what they are named for, don't use his functions and properties.

Well you can trivialize all you want but the matters are different. It's one thing to have good names, good designs, trusted code etc. and a whole different thing to define a feature of which entire existence only serves only an unchecked convention.
 Since C was invented, we have had the convention that () means function, 
 lack of () means property.  You are acting like the last 37 years of 
 programming languages never existed, and this is some "new radical" 
 convention.  D is of C lineage, so using long standing C conventions 
 should not confuse people.

Well C never had properties that executed code, so following the lineage is a moot point. C also didn't have a variety of other things, such as member functions. But we do have now. All I want is to not add undue burden. To me, it would be a mistake if D defined a special syntax for defining properties as if they were some big deal, to then not check in any way that they behave any different than regular functions.
 Maybe less confusion, definitely more burden.

The burden is on the author to come up with meaningful function names already. With real properties, at least that task is easier because you don't need to add extra context to ensure a word is treated as a verb or a noun (e.g. 'isEmpty' in order to make sure someone doesn't mistake 'empty' for an action). The compiler enforces the requirement of property syntax vs. function syntax, so no burden there.

No, you add burden by posing the question, do I want people to call with parens or without? There's always going to be a gray area and there's always going to be surprising APIs (see e.g. Daniel Keep's point about range APIs that must actually do stuff in r.empty). With a uniform convention, all of these issues vanish. To clarify: if there was any extra checking by the compiler, any guarantee that the feature would provide at all, I'd be glad to pay the price of thinking more when putting together a design. But you want to define a language feature that allows people to require "()" or not as they please, and that's all. It's a frivolous detail to be spending time on when designing an API. I simply don't believe that's good language design. Andrei
Jul 31 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu escribió:
 Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 But in the case of properties only allowed without parens, functions 
 require parens, you are defining a rule for the compiler.  Think of 
 the parentheses as an extension of the function name, like punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.

But we already have sheer unchecked convention! I could make a function called sort that reverses an array.

Of course we do. My point is that there's no need to add gratuitous mechanisms fostering conventions that go unchecked.
 I don't get why it makes any difference to you that the meaning of 
 parentheses and no parentheses is used by the author of the function.  
 How is this bad or somehow worse than what we have now?  If you don't 
 trust the author's functions do what they are named for, don't use his 
 functions and properties.

Well you can trivialize all you want but the matters are different. It's one thing to have good names, good designs, trusted code etc. and a whole different thing to define a feature of which entire existence only serves only an unchecked convention.

Like... ddoc?
Jul 31 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig escribió:
 Andrei Alexandrescu escribió:
 Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 But in the case of properties only allowed without parens, 
 functions require parens, you are defining a rule for the 
 compiler.  Think of the parentheses as an extension of the function 
 name, like punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.

But we already have sheer unchecked convention! I could make a function called sort that reverses an array.

Of course we do. My point is that there's no need to add gratuitous mechanisms fostering conventions that go unchecked.
 I don't get why it makes any difference to you that the meaning of 
 parentheses and no parentheses is used by the author of the 
 function.  How is this bad or somehow worse than what we have now?  
 If you don't trust the author's functions do what they are named for, 
 don't use his functions and properties.

Well you can trivialize all you want but the matters are different. It's one thing to have good names, good designs, trusted code etc. and a whole different thing to define a feature of which entire existence only serves only an unchecked convention.

Like... ddoc?

Partially kidding with this, partially not. Sometimes comments get old: after some refactors they don't get updated and they say the code does something when it actually doing something different. So maybe ddoc shouldn't have been introduced, maybe not even comments, because they could not match with what the code actually does. But in the case of name vs. name() it's much simple: it's a really simple convention *that already exists in almost every other language*. Ok, people can choose not to follow it, just like naming functions with silly names, or not adopting naming conventions, but... why would they do that?
Jul 31 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Ary Borenszweig wrote:
 But in the case of name vs. name() it's much simple: it's a really
 simple convention *that already exists in almost every other language*.
 Ok, people can choose not to follow it, just like naming functions with
 silly names, or not adopting naming conventions, but... why would they
 do that?

+1 It's pure convention that 'a = x.b' reads a property, 'x.b = a' writes a property, and 'a + b' performs addition. However, these are /useful/ conventions that aid understanding. The 'a + b' case is apparently useful enough to merit special language support, so why not the others? And if properties somehow manage to solve the rvalue return problem, so much the better. -- Rainer Deyke - rainerd eldwood.com
Jul 31 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 22:37:06 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 But in the case of properties only allowed without parens, 
 functions require parens, you are defining a rule for the 
 compiler.  Think of the parentheses as an extension of the function 
 name, like punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.

function called sort that reverses an array.

Of course we do. My point is that there's no need to add gratuitous mechanisms fostering conventions that go unchecked.

We already had those conventions. D took them away by allowing any function to be treated as a property.

In C and C++ there was no convention: a.b was a field name and a.b() was a function call. It was a language reality. C# added properties that allow establishing a convention.
 You could argue the same points 
 for the current D property system -- specifying x = y translating to x = 
 y() doesn't add any extra checking or benefit at all except for you like 
 the way it looks better.

That's why we need to restrict it.
 I still am amazed that you see no benefit to 
 punctuation differences in names.

I do see benefit, but I also see cost.
 I don't get why it makes any difference to you that the meaning of 
 parentheses and no parentheses is used by the author of the 
 function.  How is this bad or somehow worse than what we have now?  
 If you don't trust the author's functions do what they are named for, 
 don't use his functions and properties.

Well you can trivialize all you want but the matters are different. It's one thing to have good names, good designs, trusted code etc. and a whole different thing to define a feature of which entire existence only serves only an unchecked convention.

It serves a purpose -- one that is not functionally checkable or definable, but is interface to a human being.

The problem is that it's all loss, no gain: the callee must make the decision whether the call must be with or without parens, and the caller must obey that decision. There is no guarantee gained, only effort.
 Look, if D decided to make function calls case insensitive because "some 
 people like to call with their own case", nobody would go for it.  But 
 let's say it did happen, and people requested that we make things case 
 sensitive again.  The argument that it doesn't serve any checked 
 convention is ludicrous!  I don't want a checked convention, I just want 
 to name my classes with capital letters for my conventions dammit!  The 
 ability to name things how we want and expect them to be called by the 
 name we give them is fundamental in human interface definition!  Not 
 being able to specify the calling convention makes you A) come up with 
 ugly verbose names like isEmpty, getProperty, C_classname, or B) deal 
 with the ensuing bug reports "how come you named it empty instead of 
 isEmpty because if you call it like empty(), it looks like you are 
 emptying something".

I was careful to specify that things like naming conventions are useful when/because they are simple. There are naming conventions that don't scale and are mentioned mostly derisively, such as the Hungarian notation. Apparently I wasn't careful enough, I should have stressed that point. Again: beyond the simplest ones, unchecked conventions in programming languages are a dicey proposition. I believe a good language should not define features that serve solely for cute but useless conventions.
 How about I just start calling you Andray because it's the same to me as 
 Andrei.
 
 Since C was invented, we have had the convention that () means 
 function, lack of () means property.  You are acting like the last 37 
 years of programming languages never existed, and this is some "new 
 radical" convention.  D is of C lineage, so using long standing C 
 conventions should not confuse people.

Well C never had properties that executed code, so following the lineage is a moot point. C also didn't have a variety of other things, such as member functions. But we do have now. All I want is to not add undue burden. To me, it would be a mistake if D defined a special syntax for defining properties as if they were some big deal, to then not check in any way that they behave any different than regular functions.

The check is in the implication the human sees. x.empty() => empty x; x.empty => is x empty.

I bet money someone somewhere will want to define an API where x.sort() sorts something in-place and x.sort returns a sorted copy; or where x.empty() clears something and x.empty tells whether it's empty. Kind of interesting I guess :o).
 No functional check is necessary just like no 
 check is necessary to ensure that empty doesn't print "asshole" to the 
 screen.  The implication is in the meaning of the word coupled with 
 punctuation long perceived *by the user* as defining an action.  C had 
 properties, but they were limited to only returning a value and setting 
 a value.

So that distinction got lost once C# introduced properties as a distinct language feature. What was gained?
 Why do you think Java defines properties as getX and setX instead of 
 just x?  Because they don't have a way to get rid of the parentheses.  
 So they want to make it clear because parantheses imply action that the 
 action is getting or setting x, not x'ing.

"Convention are good if they're simple."
 Maybe less confusion, definitely more burden.

names already. With real properties, at least that task is easier because you don't need to add extra context to ensure a word is treated as a verb or a noun (e.g. 'isEmpty' in order to make sure someone doesn't mistake 'empty' for an action). The compiler enforces the requirement of property syntax vs. function syntax, so no burden there.

No, you add burden by posing the question, do I want people to call with parens or without? There's always going to be a gray area and there's always going to be surprising APIs (see e.g. Daniel Keep's point about range APIs that must actually do stuff in r.empty). With a uniform convention, all of these issues vanish.

I grant you that people will certainly stray from the norm, gray areas are unavoidable. Sometimes you have to bend the rules a little bit to achieve what you want, this is no exception. But for 99.99% of the time, the convention can be used. That one or two times you have to implement something weird that doesn't follow the convention doesn't make the whole convention invalid! You note the exception and move on. For example, look at Rebindable!(T) where you clearly violate the rules of const, does that make all of const invalid? Oops, I can't implement Rebindable without breaking the rules, this const shit can't be guaranteed, so I reject the idea of const altogether. Daniel's point about range APIs doing stuff in r.empty has nothing to do with it, since the meaning is "is this range empty." Some would like that to mean "you're just giving me a simple value so you shouldn't have to mutate the object," but to me it *reads* "is this thing empty, do whatever it takes to answer that question, including mutating the object if you have to." Guess what, you still have to deal with that problem, even without property syntax.
 To clarify: if there was any extra checking by the compiler, any 
 guarantee that the feature would provide at all, I'd be glad to pay 
 the price of thinking more when putting together a design. But you 
 want to define a language feature that allows people to require "()" 
 or not as they please, and that's all. It's a frivolous detail to be 
 spending time on when designing an API. I simply don't believe that's 
 good language design.

Yeah, those moronic language designers who make C#, Java, Python, etc. don't know what they're talking about. I give up. I don't see any way to break through to you. Hopefully someday someone whose opinion you *do* value criticizes D for having ambiguous calling conventions, and then you are forced to change it.

I don't think you can reasonably conclude there's anything personal in this. What you need in order to be convincing are better arguments, not more clout. Andrei
Jul 31 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Steven Schveighoffer escribió:
 On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 What you need in order to be convincing are better arguments

From the responses from everyone else in this newsgroup, I think you may be alone in that opinion.

I agree. And I also think it's now worthless to continue discussing this. Properties won't get implemented in any of the ways discussed in the newsgroup. But, man, am I so excited to be able to overload my functions and templated functions!
Aug 01 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 What you need in order to be convincing are better arguments

From the responses from everyone else in this newsgroup, I think you may be alone in that opinion.

http://poll.pollcode.com/Iy0_result?v Andrei
Aug 01 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:

 To clarify: if there was any extra checking by the compiler, any 
 guarantee that the feature would provide at all, I'd be glad to pay the 
 price of thinking more when putting together a design. But you want to 
 define a language feature that allows people to require "()" or not as 
 they please, and that's all. It's a frivolous detail to be spending time 
 on when designing an API. I simply don't believe that's good language 
 design.

That's not "all." To me it's mostly maintainability. If there is a property 'foo' and you allow to set it both as 'foo = 5' and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard, or even impossible for you, the maintainer, to switch from a property back to a regular field for 'foo'. If you allow to call function 'bar()' both with and without parentheses, and a project is maintained by more than one person, they *will* call it differently making the source look inconsistent. Dropping the 'omittable parentheses' thing happens to solve these, and the delegate return problem, and helps to disambiguate words with overloaded meanings.
Aug 01 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sergey Gromov wrote:
 Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:
 
 To clarify: if there was any extra checking by the compiler, any 
 guarantee that the feature would provide at all, I'd be glad to pay the 
 price of thinking more when putting together a design. But you want to 
 define a language feature that allows people to require "()" or not as 
 they please, and that's all. It's a frivolous detail to be spending time 
 on when designing an API. I simply don't believe that's good language 
 design.

That's not "all." To me it's mostly maintainability. If there is a property 'foo' and you allow to set it both as 'foo = 5' and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard, or even impossible for you, the maintainer, to switch from a property back to a regular field for 'foo'. If you allow to call function 'bar()' both with and without parentheses, and a project is maintained by more than one person, they *will* call it differently making the source look inconsistent. Dropping the 'omittable parentheses' thing happens to solve these, and the delegate return problem, and helps to disambiguate words with overloaded meanings.

Thanks for these great points. As an additional example, most ranges define the method bool empty() { ... } whereas infinite ranges define the enum enum bool empty = false; It follows that if a range user wants to be compatible with finite and infinite ranges, they always must use no "()". It would be nice if the range's definition could enforce that. Andrei
Aug 01 2009
next sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:

 Thanks for these great points. As an additional example, most ranges 
 define the method
 
 bool empty() { ... }
 
 whereas infinite ranges define the enum
 
 enum bool empty = false;
 
 It follows that if a range user wants to be compatible with finite and 
 infinite ranges, they always must use no "()". It would be nice if the 
 range's definition could enforce that.
 
 
 Andrei

Huh. How does this reconcile with your previous posts, where you said it'd probably be a bad idea for the API designer to mandate the function calling style of the API consumer? Is this the same issue, and you've changed your mind? Or do you see this as a different issue? --benji
Aug 01 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 Andrei Alexandrescu wrote:
 
 Thanks for these great points. As an additional example, most ranges 
 define the method

 bool empty() { ... }

 whereas infinite ranges define the enum

 enum bool empty = false;

 It follows that if a range user wants to be compatible with finite and 
 infinite ranges, they always must use no "()". It would be nice if the 
 range's definition could enforce that.


 Andrei

Huh. How does this reconcile with your previous posts, where you said it'd probably be a bad idea for the API designer to mandate the function calling style of the API consumer? Is this the same issue, and you've changed your mind? Or do you see this as a different issue?

I found the way he put it - avoiding gratuitous inconsistency between fields and properties - a compelling perspective. Andrei
Aug 01 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Huh. How does this reconcile with your previous posts, where you said 
 it'd probably be a bad idea for the API designer to mandate the 
 function calling style of the API consumer?

 Is this the same issue, and you've changed your mind? Or do you see 
 this as a different issue?

I found the way he put it - avoiding gratuitous inconsistency between fields and properties - a compelling perspective.

That's improper netiquette. The correct netiquette is to never give an iota, regardless.
Aug 02 2009
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-08-01 23:36:57 -0400, "Robert Jacques" <sandford jhu.edu> said:

 Hmm... I just had a crazy thought, regarding Andrei's enum bool empty = 
  false; example. What if in addition to functions as fields (aka  
 properties) D allowed fields as functions? i.e.
 c.foo(5); => c.foo = 5
 when method foo doesn't exist.

Sure, you could make fields behave as function. For instance: int foo; foo(5); // same as foo = 5; int bar(foo()); // same as bar = foo; But then you'll have some problems with delegates and types that define opCall: void delegate(int) foo; foo(5); // foo = 5 or a call to the delegate? foo()(5); // should the delegate be called this way? and this: void delegate() foo; void delegate() bar(foo()); // same as bar = foo, or a call to the delegate? You'll need to always write foo()() to call the delegate, which I admit is more coherent that what we have now with properties, but also somewhat counterintuitive. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 02 2009
prev sibling parent Sergey Gromov <snake.scaly gmail.com> writes:
Sat, 01 Aug 2009 23:36:57 -0400, Robert Jacques wrote:

 On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:

 To clarify: if there was any extra checking by the compiler, any  
 guarantee that the feature would provide at all, I'd be glad to pay  
 the price of thinking more when putting together a design. But you  
 want to define a language feature that allows people to require "()"  
 or not as they please, and that's all. It's a frivolous detail to be  
 spending time on when designing an API. I simply don't believe that's  
 good language design.

If there is a property 'foo' and you allow to set it both as 'foo = 5' and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard, or even impossible for you, the maintainer, to switch from a property back to a regular field for 'foo'. If you allow to call function 'bar()' both with and without parentheses, and a project is maintained by more than one person, they *will* call it differently making the source look inconsistent. Dropping the 'omittable parentheses' thing happens to solve these, and the delegate return problem, and helps to disambiguate words with overloaded meanings.

Thanks for these great points. As an additional example, most ranges define the method

Great points? Sorry, but all it takes is one person to subclass and overload foo, and then it can never be turned back into a field. That is, if you're worrying about maintainability.

Yes, I agree, properties are still not fields, and subtle differences in behavior may lead to problems when switching implementation. One can overload a getter, or take an address of a setter, or pass a field by reference. Though the less such differences exist, the less bugs you're going to cause in user code when actually switching. We can even avoid some of these potential problems: * User cannot overload a property in a final class, or when getter and setter are declared final. Therefore it's up to an interface designer whether they want to allow overloading * Taking a getter/setter address should not be allowed, at all * Passing a property by reference should only work for ref-returning getters, and produce a nice compile-time error otherwise If the last two were implemented then we'd be left with only one gotcha which manifests itself at compile time, is trivial to fix, and may even be resolved by compiler in the future---see discussions about functions returning structs.
 As for source code consistency, I view no-(), () and not caring as part  
 whole code format/variable issue. I mean, code::block has 5 different  
 layout styles (+custom definitions). What about variable names, hmm?  
 e/empty/isEmpty/is_empty? I would think any project than can maintain code  
 consistency of those other issues, they can also manage ()/no-()/mixed.

This is exactly Nick's point: you have to establish yet another arbitrary convention instead of relying on the language rules. Sure most of us are used to obeying such conventions but it would be better not to compilcate them even more.
Aug 02 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Very sensible points.
Aug 02 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Sun, 02 Aug 2009 01:13:45 -0700, Walter Bright wrote:

 Very sensible points.

I'm really glad I can help.
Aug 02 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 So to sum up, with this feature lack of parentheses would imply no 
 action, but would not be enforced.  However, it would be considered 
 incorrect logic if the rule was not followed, similar to naming your 
 functions something other than what they do.

I am leery of such a feature. It essentially introduces a way to define conventions that are in no way useful to, or checked by, language rules. In my experience this has been a bad idea more often than not.

Like it or not, that's exactly the situation we have now, with the (sometimes)-optional parentheses. Some people are using a convention of never using the optional parens. Other people use the parens only when a function an action, and avoiding them otherwise. And some other people (like me) always use the parens. So the clusterfuck of unenforceable and useless conventions is already here. Here's my suggestions: if you think putting parentheses on a no-arg function is stupid, then it should be a syntax error for them to exist. That wouldn't be my first choice, but it'd be a thousand times better than the situation with optional parens. --benji
Jul 31 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Benji Smith wrote:
 So the clusterfuck of unenforceable and useless conventions is already
 here. Here's my suggestions: if you think putting parentheses on a
 no-arg function is stupid, then it should be a syntax error for them to
 exist. That wouldn't be my first choice, but it'd be a thousand times
 better than the situation with optional parens.

+1 -- Rainer Deyke - rainerd eldwood.com
Jul 31 2009
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:
 On Fri, Jul 31, 2009 at 10:09 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Benji Smith wrote:
 So the clusterfuck of unenforceable and useless conventions is already
 here. Here's my suggestions: if you think putting parentheses on a no-arg
 function is stupid, then it should be a syntax error for them to exist. That
 wouldn't be my first choice, but it'd be a thousand times better than the
 situation with optional parens.

 --benji

think of it for a second: a full-blown language feature has been proposed to not fix that, but reify it.


D already has a *truckload* of such features. Aliases, typedefs, renamed imports, and overloaded operators all exists solely so that a programmer can pretend that one thing is another thing, so that an API designer can more precisely express the *intent* of the code, and with semantics that are enforced by the compiler. Compared with those other features, I don't see what's so different about the properties proposals. --benji
Aug 01 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Jul 31, 2009 at 9:13 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:

 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I
 can't figure how some are missing it.

at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.



the expected landslide against the dictature :o).

I was on vacation the last two days so I didn't see any of these polls till today. But the poll I did see was like 8 to 5 in favor of a change. It doesn't really seem like a statistically significant sample. Seems like the "I don't care enough" vote is the vast majority there. Assuming D has significantly more than 13 users, that is. Or perhaps it's the "you guys have gone on about this for far too long and and I now have no idea what this is about anymore" vote.

I've seen a vote in which more than 50 voted. Still doesn't say anything statistically significant, but it's more than a handful. Andrei
Aug 01 2009
parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 I've seen a vote in which more than 50 voted. Still doesn't say anything 
 statistically significant, but it's more than a handful.

The polls miss those gave up on D.
Aug 03 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 I've seen a vote in which more than 50 voted. Still doesn't say anything 
 statistically significant, but it's more than a handful.

The polls miss those gave up on D.

And those who will come :o). Andrei
Aug 04 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jul 31, 2009 at 10:09 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Benji Smith wrote:
 Andrei Alexandrescu wrote:
 Steven Schveighoffer wrote:
 So to sum up, with this feature lack of parentheses would imply no
 action, but would not be enforced. =A0However, it would be considered
 incorrect logic if the rule was not followed, similar to naming your
 functions something other than what they do.

I am leery of such a feature. It essentially introduces a way to define conventions that are in no way useful to, or checked by, language rules=



 my experience this has been a bad idea more often than not.

Like it or not, that's exactly the situation we have now, with the (sometimes)-optional parentheses. Some people are using a convention of never using the optional parens. Other people use the parens only when a function an action, and avoiding them otherwise. And some other people (=


 me) always use the parens.

 So the clusterfuck of unenforceable and useless conventions is already
 here. Here's my suggestions: if you think putting parentheses on a no-ar=


 function is stupid, then it should be a syntax error for them to exist. =


 wouldn't be my first choice, but it'd be a thousand times better than th=


 situation with optional parens.

 --benji

I agree that it's not good to have two ways of doing the same thing. Now think of it for a second: a full-blown language feature has been proposed=

 not fix that, but reify it.

Not quite right. We *already* have a language feature that reifies it. The proposal is to adjust that feature to *remove* the arbitrary choice from the caller and give the choice to the API designer, which is a much more sensible place for it to reside. The logical conclusion if you stick by that argument is that we should remove the optional () rule and go back to the simpler C/C++ rule. --bb
Aug 01 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 On Mon, Jul 27, 2009 at 11:57 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 
 The property attribute also has the nice property
 (heh) that you can call the property setters and getters either as
 properties or as functions (i.e. "r.empty" or "r.empty()").
 Basically, the behavior would be *exactly* as it is now, except you'd
 have to explicitly state with which functions it would be legal.

functions that don't take parameters. To me that's syntactic noise and an unnecessary special case.

Then on this we disagree ;)

I appreciate the asking.
 Or is the idea of introducing the 'property' keyword too controversial?

aggravation is that everybody is with their hand on the syntactic holster when they should look into simplifying and unifying, not adding more baroque adornments for what is really some function calls.

Oh? And what's the solution, then, if you don't like opGet/opSet and don't want to pull out your syntactic pistol? The status quo? I think the sheer volume of messages on this subject alone - not only on these last few threads but over a period of *years* - shows that many people aren't satisfied with it.

My perception is that there are a few vocal people. The protests have been historically against the stupid "writeln = 42" which we must get rid of. I have a dream. * Parameterless functions still can be called without "()". People will realize that it's a prejudice to believe that this impedes code understanding, and their eyes and wrists will thank them. * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the expression "auto __x = foo, __x = bar" is compilable. * The non-uniformity regarding parameterless functions returning parameterless functions is acknowledged but considered minor. Yum. Andrei
Jul 28 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-28 10:08:17 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 My perception is that there are a few vocal people. The protests have 
 been historically against the stupid "writeln = 42" which we must get 
 rid of.

For the record, I'm not even bothered by such things. Returning function pointers and delegates, and types having an opCall can't use the property syntax for purely syntaxical reasons, this bother me much more. Then it'd be better to have operator overloading for properties. And in the last position it'd be that you can write stupid code like the above.
 I have a dream.
 
 * Parameterless functions still can be called without "()". People will 
 realize that it's a prejudice to believe that this impedes code 
 understanding, and their eyes and wrists will thank them.

I like calling parameterless functions without "()", but it isn't very clear what you're doing with some callable return types.
 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF 
 the expression "auto __x = foo, __x = bar" is compilable.

Answered to that one in another thread. I think it's worse than what we have now.
 * The non-uniformity regarding parameterless functions returning 
 parameterless functions is acknowledged but considered minor.

I do consider this minor, but still an annoyance. I don't dislike the current function/property syntax, I just don't like it as much as I though I'd do at first. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 28 2009
prev sibling next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 
 My perception is that there are a few vocal people. The protests have
 been historically against the stupid "writeln = 42" which we must get
 rid of.
 

Seems odd to me. I thought the unpopular bit was the lack of lvalue-ness and how "array.length++;" did not work. No idiot would write "writefln = 42;" in serious code. It's easy to avoid since you have be rather intentional about it.
 I have a dream.
 

I feel like ranting ;)
 * Parameterless functions still can be called without "()". People will
 realize that it's a prejudice to believe that this impedes code
 understanding, and their eyes and wrists will thank them.
 

Earlier I was thinking yeah ok w/e that's fine. Now I'm thinking these are just evil. But only when the function returns a value-type. void functions are alright. Ref returns may or may not be alright. It's not because of "writefln = 42;". It's because of this: // Library code struct Rectangle { float x,y,w,h; // etc blah blah } class Widget { Rectangle _rect; // eww no optional backing storage Rectangle rect() { return _rect; } //... } // User code (probably test code in this case...) auto widget = new Widget(...); widget.rect.w = 200; widget.rect.h = 100; // End A few hours later this poor library developer takes a break from the debugger and writes a small experiment. The conclusion is "AARRGGGHHH!". He runs to the news group to bitch and moan, and someone responds, "yeesh use ref return and RTFM already". Bad day. This is only the example that pops to mind. I am sure there are cases where the library writer may intentionally NOT ref return, and the user will miss this and get bitten. When the library writer and user are the same, things only goes downhill.
 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the
 expression "auto __x = foo, __x = bar" is compilable.
 

I seem to know exactly what you said with great mathematical precision and certainty. I have no idea what this actually DOES though :/ (In another post you mentioned this being a guarantee of a getter, but there seems to be more to it, such as type equality between foo and bar.)
 * The non-uniformity regarding parameterless functions returning
 parameterless functions is acknowledged but considered minor.
 

O.O R-R-Really?! So you're just going to give up? So fields can return functions but properties cannot?
 Yum.
 
 
 Andrei

At the end of all of this "array.length++;" still does not work like one would hope. That's because ref int length() { ... } // int length(int foo) { ... } // hint: this is not used length++; is not the same as int length() { ... } int length(int foo) { ... } length(length()+1); I don't know if ref returns are expected to be the be-all-end-all solution to the lvalueness problem of properties, but it won't work here. The length property will be incremented, but the unfortunate user will find out later that some dead stack variable changed but no new space was ever made. Not unless they are lucky and such things remain as compiler errors.
Jul 28 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 Andrei Alexandrescu wrote:
 My perception is that there are a few vocal people. The protests have
 been historically against the stupid "writeln = 42" which we must get
 rid of.

Seems odd to me. I thought the unpopular bit was the lack of lvalue-ness and how "array.length++;" did not work. No idiot would write "writefln = 42;" in serious code. It's easy to avoid since you have be rather intentional about it.

Oh, yes. That needs fixing too!
 I have a dream.

I feel like ranting ;)
 * Parameterless functions still can be called without "()". People will
 realize that it's a prejudice to believe that this impedes code
 understanding, and their eyes and wrists will thank them.

Earlier I was thinking yeah ok w/e that's fine. Now I'm thinking these are just evil. But only when the function returns a value-type. void functions are alright. Ref returns may or may not be alright. It's not because of "writefln = 42;". It's because of this: // Library code struct Rectangle { float x,y,w,h; // etc blah blah } class Widget { Rectangle _rect; // eww no optional backing storage Rectangle rect() { return _rect; } //... } // User code (probably test code in this case...) auto widget = new Widget(...); widget.rect.w = 200; widget.rect.h = 100; // End A few hours later this poor library developer takes a break from the debugger and writes a small experiment. The conclusion is "AARRGGGHHH!". He runs to the news group to bitch and moan, and someone responds, "yeesh use ref return and RTFM already". Bad day.

This serious problem has already been mentioned once. Incidentally I think it was Steve who mentioned it. It is big and relates to the fact that you could call member functions against rvalues. Could you please add it to bugzilla?
 This is only the example that pops to mind.  I am sure there are cases
 where the library writer may intentionally NOT ref return, and the user
 will miss this and get bitten.  When the library writer and user are the
 same, things only goes downhill.
 
 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the
 expression "auto __x = foo, __x = bar" is compilable.

I seem to know exactly what you said with great mathematical precision and certainty. I have no idea what this actually DOES though :/ (In another post you mentioned this being a guarantee of a getter, but there seems to be more to it, such as type equality between foo and bar.)
 * The non-uniformity regarding parameterless functions returning
 parameterless functions is acknowledged but considered minor.

O.O R-R-Really?! So you're just going to give up?

Well that kind of sucks. I agree. Andrei
Jul 28 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 Chad J wrote:
 Andrei Alexandrescu wrote:
 My perception is that there are a few vocal people. The protests have
 been historically against the stupid "writeln = 42" which we must get
 rid of.

Seems odd to me. I thought the unpopular bit was the lack of lvalue-ness and how "array.length++;" did not work. No idiot would write "writefln = 42;" in serious code. It's easy to avoid since you have be rather intentional about it.

Oh, yes. That needs fixing too!
 I have a dream.

I feel like ranting ;)
 * Parameterless functions still can be called without "()". People will
 realize that it's a prejudice to believe that this impedes code
 understanding, and their eyes and wrists will thank them.

Earlier I was thinking yeah ok w/e that's fine. Now I'm thinking these are just evil. But only when the function returns a value-type. void functions are alright. Ref returns may or may not be alright. It's not because of "writefln = 42;". It's because of this: // Library code struct Rectangle { float x,y,w,h; // etc blah blah } class Widget { Rectangle _rect; // eww no optional backing storage Rectangle rect() { return _rect; } //... } // User code (probably test code in this case...) auto widget = new Widget(...); widget.rect.w = 200; widget.rect.h = 100; // End A few hours later this poor library developer takes a break from the debugger and writes a small experiment. The conclusion is "AARRGGGHHH!". He runs to the news group to bitch and moan, and someone responds, "yeesh use ref return and RTFM already". Bad day.

This serious problem has already been mentioned once. Incidentally I think it was Steve who mentioned it. It is big and relates to the fact that you could call member functions against rvalues. Could you please add it to bugzilla?
 This is only the example that pops to mind.  I am sure there are cases
 where the library writer may intentionally NOT ref return, and the user
 will miss this and get bitten.  When the library writer and user are the
 same, things only goes downhill.

 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the
 expression "auto __x = foo, __x = bar" is compilable.

I seem to know exactly what you said with great mathematical precision and certainty. I have no idea what this actually DOES though :/ (In another post you mentioned this being a guarantee of a getter, but there seems to be more to it, such as type equality between foo and bar.)
 * The non-uniformity regarding parameterless functions returning
 parameterless functions is acknowledged but considered minor.

O.O R-R-Really?! So you're just going to give up?

Well that kind of sucks. I agree. Andrei

bindun. http://d.puremagic.com/issues/show_bug.cgi?id=3008
Jul 28 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Whoops forgot to edit.  Sorry.

 This serious problem has already been mentioned once. Incidentally I
 think it was Steve who mentioned it. It is big and relates to the fact
 that you could call member functions against rvalues. Could you please
 add it to bugzilla?


bindun. http://d.puremagic.com/issues/show_bug.cgi?id=3008
Jul 28 2009
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:
 I have a dream.
 
 * Parameterless functions still can be called without "()". People will 
 realize that it's a prejudice to believe that this impedes code 
 understanding, and their eyes and wrists will thank them.
 
 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the 
 expression "auto __x = foo, __x = bar" is compilable.

I like this. Would it also make sense to require that the getter is declared as const or immutable? -Lars
Jul 29 2009
parent Kagamin <spam here.lot> writes:
Lars T. Kyllingstad Wrote:

 Andrei Alexandrescu wrote:
 I have a dream.
 
 * Parameterless functions still can be called without "()". People will 
 realize that it's a prejudice to believe that this impedes code 
 understanding, and their eyes and wrists will thank them.
 
 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the 
 expression "auto __x = foo, __x = bar" is compilable.

I like this. Would it also make sense to require that the getter is declared as const or immutable?

Not quite. See DIP2.
Jul 29 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley escribi:
 On Mon, Jul 27, 2009 at 11:13 PM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Rainer Deyke wrote:
 Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language
 design. Because the rules that apply to those magical identifiers is
 different than the rules applying to non-magical identifiers.

treated exactly like every other identifier. The only thing "special" about these identifiers is that they can be generated automatically by the compiler. When the compiler sees 'a.b', and 'b' is not a field or method of 'a', it rewrites this to 'a.opGet_b()'.

+1

While the opGet_foo and opSet_foo are okay, what are your thoughts on the 'property' attribute on a function? I know you said you didn't really like the idea of having to name your range's empty function 'opGet_empty'. The property attribute also has the nice property (heh) that you can call the property setters and getters either as properties or as functions (i.e. "r.empty" or "r.empty()"). Basically, the behavior would be *exactly* as it is now, except you'd have to explicitly state with which functions it would be legal. Or is the idea of introducing the 'property' keyword too controversial? I mean, if it is, there are plenty of keywords in D that *only* have one meaning. I'm sure one of them could be repurposed ;)

Another problem with the opGet_foo approach (which I find quite ugly to my eyes) is that it's less backward compatible. As Andrei said, he'll have to rename empty() to opGet_empty(). The compiler will also be a little slower because for each function it'll have to make a match to see if it starts with opGet or opSet. There's also the thing to worry about not letting "int foo" and "int opGet_foo" to coexist. And currently D has 106 keywords. I think no one will care if it has 107. :-P
Jul 28 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:
 And currently D has 106 keywords. I think no one will care if it has 107. :-P<

So far the idea of adding the "property" keyword looks like a nice solution. But adding semantic annotations (Java-style, C#-style, or something different) to D2 may be a better solution to this problem. Such annotations are also quite useful to improve the interaction from D and IDEs, and to express lot of other semantics (often absent from C# too) that will allow D compilers to do their job more efficiently (I am now thinking about annotation like ones present in the Splint lint). Once annotations are used for properties, some of those 106 keywords can then be removed from the language and replaced by other annotations. This is positive. I hope people here will not settle for a suboptimal solution again, just to have "some" solution to this problem. If Walter doesn't understand why such annotations are useful then the blame is partially of people (like me) that aren't able enough to explain such usefulness :-) Bye, bearophile
Jul 28 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.188.1248746883.14071.digitalmars-d puremagic.com...
On Mon, Jul 27, 2009 at 6:33 PM, Benji Smith<dlanguage benjismith.net> 
wrote:
 What prevents us from doing
 more generic annotations with syntax like  property?

Walter. No one's been able to convince him they're useful.
Jul 27 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Nick Sabalausky escribi:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.188.1248746883.14071.digitalmars-d puremagic.com...
 On Mon, Jul 27, 2009 at 6:33 PM, Benji Smith<dlanguage benjismith.net> 
 wrote:
 What prevents us from doing
 more generic annotations with syntax like  property?

Walter. No one's been able to convince him they're useful.

Annotations not useful? I think the main problem with D is its developers still live in the 90's... :)
Jul 27 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message 
 news:mailman.188.1248746883.14071.digitalmars-d puremagic.com...
 On Mon, Jul 27, 2009 at 6:33 PM, Benji Smith<dlanguage benjismith.net> 
 wrote:
 What prevents us from doing
 more generic annotations with syntax like  property?

Walter. No one's been able to convince him they're useful.

Then someone better put forward a good argument. Andrei
Jul 27 2009
parent reply Kagamin <spam here.lot> writes:
Andrei Alexandrescu Wrote:

 What prevents us from doing
 more generic annotations with syntax like  property?

Walter. No one's been able to convince him they're useful.

Then someone better put forward a good argument.

.Net framework is one big good argument, here are some usecases: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=94070 http://msdn.microsoft.com/en-us/library/xtwkdas5.aspx How do you plan to control serialization? Renaming elements? Serializing to attributes? Defining namespaces? List of attributes and their usage: http://msdn.microsoft.com/en-us/library/system.attribute.aspx#familyToggle
Jul 28 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Kagamin wrote:
 Andrei Alexandrescu Wrote:
 
 What prevents us from doing
 more generic annotations with syntax like  property?



.Net framework is one big good argument, here are some usecases: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=94070 http://msdn.microsoft.com/en-us/library/xtwkdas5.aspx How do you plan to control serialization? Renaming elements? Serializing to attributes? Defining namespaces? List of attributes and their usage: http://msdn.microsoft.com/en-us/library/system.attribute.aspx#familyToggle

Sorry, I misread - I was still referring to properties in particular. Andrei
Jul 28 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language 
 design. Because the rules that apply to those magical identifiers is 
 different than the rules applying to non-magical identifiers.

Well I agree with some of your points but this is factually incorrect. There's nothing special about opXxx identifiers. The compiler simply rewrites certain operations into regular calls to those operators. That's all. I happen to find that very elegant, and in fact I'd want D to rely more often on simple rewrites instead of sophisticated special casing. Andrei
Jul 27 2009
parent Benji Smith <dlanguage benjismith.net> writes:
Andrei Alexandrescu wrote:
 Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language 
 design. Because the rules that apply to those magical identifiers is 
 different than the rules applying to non-magical identifiers.

Well I agree with some of your points but this is factually incorrect. There's nothing special about opXxx identifiers. The compiler simply rewrites certain operations into regular calls to those operators. That's all. I happen to find that very elegant, and in fact I'd want D to rely more often on simple rewrites instead of sophisticated special casing. Andrei

I should have been more clear. I understand the rewriting part of the proposal. What I was referring to was the fact that an opGet_x identifier would shadow the declaration of a variable named "x", making it impossible, within the type itself, to directly reference the variable itself. So, in this case... class MyClass { private int x; public int opGet_x() { return x; } } ...either the compiler would issue an error (my preference) or the private field would take precedence (within the class) in any name resolution logic. From outside the class, there would be no problem. Also related, is this case: class MyClass { public int x; public int opGet_x(); } I assume the compiler would have to throw an error. Eventually, people would learn to give their fields different names than their properties (probably with an underscore prefix or something). Anyhow, in both cases, I'd consider these to be changes to the language's identifier semantics. They're not *huge* changes, but the introduction of those magical rewriting rules is still something a programmer would have to be aware of. And those are the reasons I'd rather shy away from magical name-rewriting mechanisms. (NOTE: I have no problem with the implementation of the other operator overloading names. They work exactly as expected.) --benji
Jul 27 2009
prev sibling next sibling parent reply sclytrack <sclytrack pi.be> writes:
 The property keyword looks nice though.  What prevents us from doing
 more generic annotations with syntax like  property?
 --bb

I don't know. Also I don't know where to put this post, so I'll just reply to yours :-) ------------- Maybe Property is too general. a) Prop (Yeah, I know, the short version) b) ToBeDisplayedInTheObjectInspectorOrPropertyEditorOfTheIDE How about something less specific than (a) and not too specific like (b) something that replaces the combination published and property from Delphi. (b) Would only be used in GUI api's, and not everywhere there is a setter or getter, mutator or accessor, reader or writer. ------------- Since I don't like the naming convention of above. (too loooong) PublishedProperty
Jul 28 2009
parent Kagamin <spam here.lot> writes:
sclytrack Wrote:

 -------------
 	Maybe  Property is too general.
 
 	b)  ToBeDisplayedInTheObjectInspectorOrPropertyEditorOfTheIDE
 
 	(b) Would only be used in GUI api's, and not
 	everywhere there is a setter or getter, mutator or
 	accessor, reader or writer.
 -------------

Metadata is used not only in GUI. It's used in debugging, in C# it's also used to mark obsolete API which is done by keyword in D, it's used to control serialization and for example in webservices to mark methods as callable and in proxies to specify namespace and address. Everywhere, where someone makes use of metadata.
Jul 28 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 01 Aug 2009 01:04:49 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 What you need in order to be convincing are better arguments

From the responses from everyone else in this newsgroup, I think you may be alone in that opinion. -Steve
Aug 01 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jul 31, 2009 at 9:13 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:

 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write "()". I
 can't figure how some are missing it.

at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.

My thoughts exactly.

+1

Maybe we should vote on this too. BTW, seems like the last poll wasn't quite the expected landslide against the dictature :o).

I was on vacation the last two days so I didn't see any of these polls till today. But the poll I did see was like 8 to 5 in favor of a change. It doesn't really seem like a statistically significant sample. Seems like the "I don't care enough" vote is the vast majority there. Assuming D has significantly more than 13 users, that is. Or perhaps it's the "you guys have gone on about this for far too long and and I now have no idea what this is about anymore" vote. --bb
Aug 01 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 01 Aug 2009 20:48:58 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 Sergey Gromov wrote:
 Fri, 31 Jul 2009 21:37:06 -0500, Andrei Alexandrescu wrote:

 To clarify: if there was any extra checking by the compiler, any  
 guarantee that the feature would provide at all, I'd be glad to pay  
 the price of thinking more when putting together a design. But you  
 want to define a language feature that allows people to require "()"  
 or not as they please, and that's all. It's a frivolous detail to be  
 spending time on when designing an API. I simply don't believe that's  
 good language design.

If there is a property 'foo' and you allow to set it both as 'foo = 5' and 'foo(5)' then somebody *will* use the foo(5) form. Making it hard, or even impossible for you, the maintainer, to switch from a property back to a regular field for 'foo'. If you allow to call function 'bar()' both with and without parentheses, and a project is maintained by more than one person, they *will* call it differently making the source look inconsistent. Dropping the 'omittable parentheses' thing happens to solve these, and the delegate return problem, and helps to disambiguate words with overloaded meanings.

Thanks for these great points. As an additional example, most ranges define the method bool empty() { ... } whereas infinite ranges define the enum enum bool empty = false; It follows that if a range user wants to be compatible with finite and infinite ranges, they always must use no "()". It would be nice if the range's definition could enforce that. Andrei

Great points? Sorry, but all it takes is one person to subclass and overload foo, and then it can never be turned back into a field. That is, if you're worrying about maintainability. As for source code consistency, I view no-(), () and not caring as part whole code format/variable issue. I mean, code::block has 5 different layout styles (+custom definitions). What about variable names, hmm? e/empty/isEmpty/is_empty? I would think any project than can maintain code consistency of those other issues, they can also manage ()/no-()/mixed. Hmm... I just had a crazy thought, regarding Andrei's enum bool empty = false; example. What if in addition to functions as fields (aka properties) D allowed fields as functions? i.e. c.foo(5); => c.foo = 5 when method foo doesn't exist.
Aug 01 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 28, 2009 at 10:08 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 * The syntax "foo = bar" is rewritten into "foo(bar)" IF AND ONLY IF the
 expression "auto __x = foo, __x = bar" is compilable.

// returns number of characters written int write(...) { ... } write = 42; // legal. // auto x = write; declares x as int set to 0. // x = 42; is fine. ;) I know, I know.
Jul 28 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 28, 2009 at 6:54 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Well there are quite a few other things that are arguably against C look and
 feel, such as the scope statement. I've never had a problem understanding
 code because of lacking "()", and I never ever write them.

That may be true, but you are also not an average user by any means. So surveying yourself may not give so accurate a reflection of opinions at large. Like Joel Spoelsky and others say about GUIs -- never take your own opinion that a GUI you have written is "intuitive". You need to do at a minimum a couple of random "hallway checks" -- that is, getting random people passing by in the hallway to try it out without explaining it to them. So far I think we have two people -- you and Walter -- who think that the current system is good. I think you're right that people *can* get used to losing the visual distinction between functions and fields. But I find the distinction to be a useful and unobtrusive indication of the programmer's intent. So I don't see losing the distinction to be worth saving a few keystrokes. If there were a distinction then we could be pretty sure that .empty was a property and .empty() was an action. Sure I can get used to having to learn which is which on a per-library basis, but I don't see why I should consider having to keep more stuff in my head to be a net win. In fact I'm kind of envious of those languages where ? and ! can by used in identifiers to indicate predicates and mutators. For the same reason I started to dislike like the direction some of these syntax proposals were taking. Too much for me to keep in my head. But the "property { ... }" syntax is very easy to remember and doesn't look ugly. Look, if we add a generic attributes syntax (like attr) we could perhaps use it for many of the following: abstract deprecated align case debug default export extern final lazy override package private protected public scope shared unittest volitile Storage classes are, in particular, kinds of attributes of a type. Now we may not want to go so hog wild putting this and that everywhere, but if we did we could get rid of 19 keywords right there, and add property also without adding a new keyword. --bb
Jul 28 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Jul 2009 22:37:06 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 But in the case of properties only allowed without parens, functions  
 require parens, you are defining a rule for the compiler.  Think of  
 the parentheses as an extension of the function name, like  
 punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.

function called sort that reverses an array.

Of course we do. My point is that there's no need to add gratuitous mechanisms fostering conventions that go unchecked.

We already had those conventions. D took them away by allowing any function to be treated as a property. You could argue the same points for the current D property system -- specifying x = y translating to x = y() doesn't add any extra checking or benefit at all except for you like the way it looks better. I still am amazed that you see no benefit to punctuation differences in names.
 I don't get why it makes any difference to you that the meaning of  
 parentheses and no parentheses is used by the author of the function.   
 How is this bad or somehow worse than what we have now?  If you don't  
 trust the author's functions do what they are named for, don't use his  
 functions and properties.

Well you can trivialize all you want but the matters are different. It's one thing to have good names, good designs, trusted code etc. and a whole different thing to define a feature of which entire existence only serves only an unchecked convention.

It serves a purpose -- one that is not functionally checkable or definable, but is interface to a human being. Look, if D decided to make function calls case insensitive because "some people like to call with their own case", nobody would go for it. But let's say it did happen, and people requested that we make things case sensitive again. The argument that it doesn't serve any checked convention is ludicrous! I don't want a checked convention, I just want to name my classes with capital letters for my conventions dammit! The ability to name things how we want and expect them to be called by the name we give them is fundamental in human interface definition! Not being able to specify the calling convention makes you A) come up with ugly verbose names like isEmpty, getProperty, C_classname, or B) deal with the ensuing bug reports "how come you named it empty instead of isEmpty because if you call it like empty(), it looks like you are emptying something". How about I just start calling you Andray because it's the same to me as Andrei.
 Since C was invented, we have had the convention that () means  
 function, lack of () means property.  You are acting like the last 37  
 years of programming languages never existed, and this is some "new  
 radical" convention.  D is of C lineage, so using long standing C  
 conventions should not confuse people.

Well C never had properties that executed code, so following the lineage is a moot point. C also didn't have a variety of other things, such as member functions. But we do have now. All I want is to not add undue burden. To me, it would be a mistake if D defined a special syntax for defining properties as if they were some big deal, to then not check in any way that they behave any different than regular functions.

The check is in the implication the human sees. x.empty() => empty x; x.empty => is x empty. No functional check is necessary just like no check is necessary to ensure that empty doesn't print "asshole" to the screen. The implication is in the meaning of the word coupled with punctuation long perceived *by the user* as defining an action. C had properties, but they were limited to only returning a value and setting a value. Why do you think Java defines properties as getX and setX instead of just x? Because they don't have a way to get rid of the parentheses. So they want to make it clear because parantheses imply action that the action is getting or setting x, not x'ing.
 Maybe less confusion, definitely more burden.

already. With real properties, at least that task is easier because you don't need to add extra context to ensure a word is treated as a verb or a noun (e.g. 'isEmpty' in order to make sure someone doesn't mistake 'empty' for an action). The compiler enforces the requirement of property syntax vs. function syntax, so no burden there.

No, you add burden by posing the question, do I want people to call with parens or without? There's always going to be a gray area and there's always going to be surprising APIs (see e.g. Daniel Keep's point about range APIs that must actually do stuff in r.empty). With a uniform convention, all of these issues vanish.

I grant you that people will certainly stray from the norm, gray areas are unavoidable. Sometimes you have to bend the rules a little bit to achieve what you want, this is no exception. But for 99.99% of the time, the convention can be used. That one or two times you have to implement something weird that doesn't follow the convention doesn't make the whole convention invalid! You note the exception and move on. For example, look at Rebindable!(T) where you clearly violate the rules of const, does that make all of const invalid? Oops, I can't implement Rebindable without breaking the rules, this const shit can't be guaranteed, so I reject the idea of const altogether. Daniel's point about range APIs doing stuff in r.empty has nothing to do with it, since the meaning is "is this range empty." Some would like that to mean "you're just giving me a simple value so you shouldn't have to mutate the object," but to me it *reads* "is this thing empty, do whatever it takes to answer that question, including mutating the object if you have to." Guess what, you still have to deal with that problem, even without property syntax.
 To clarify: if there was any extra checking by the compiler, any  
 guarantee that the feature would provide at all, I'd be glad to pay the  
 price of thinking more when putting together a design. But you want to  
 define a language feature that allows people to require "()" or not as  
 they please, and that's all. It's a frivolous detail to be spending time  
 on when designing an API. I simply don't believe that's good language  
 design.

Yeah, those moronic language designers who make C#, Java, Python, etc. don't know what they're talking about. I give up. I don't see any way to break through to you. Hopefully someday someone whose opinion you *do* value criticizes D for having ambiguous calling conventions, and then you are forced to change it. Until then, I have better things to do. -Steve
Jul 31 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 27, 2009 at 11:57 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:

 The property attribute also has the nice property
 (heh) that you can call the property setters and getters either as
 properties or as functions (i.e. "r.empty" or "r.empty()").
 Basically, the behavior would be *exactly* as it is now, except you'd
 have to explicitly state with which functions it would be legal.

I guess I'd rather not have to specify that. I'd do that on all of my functions that don't take parameters. To me that's syntactic noise and an unnecessary special case.

Then on this we disagree ;)
 Or is the idea of introducing the 'property' keyword too controversial?

In this case the keyword isn't even the largest aggravation. The largest aggravation is that everybody is with their hand on the syntactic holster when they should look into simplifying and unifying, not adding more baroque adornments for what is really some function calls.

Oh? And what's the solution, then, if you don't like opGet/opSet and don't want to pull out your syntactic pistol? The status quo? I think the sheer volume of messages on this subject alone - not only on these last few threads but over a period of *years* - shows that many people aren't satisfied with it.
Jul 28 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 28 Jul 2009 19:43:04 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Chad J wrote:
 Andrei Alexandrescu wrote:
 My perception is that there are a few vocal people. The protests have
 been historically against the stupid "writeln = 42" which we must get
 rid of.

lvalue-ness and how "array.length++;" did not work. No idiot would write "writefln = 42;" in serious code. It's easy to avoid since you have be rather intentional about it.

Oh, yes. That needs fixing too!

It seems to be fixed in D2.031: writefln = 42; Error: writefln is not an lvalue Error: cannot implicitly convert expression (42) of type int to void Same goes with writeln.
Jul 28 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Jul 2009 16:53:12 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 But in the case of properties only allowed without parens, functions  
 require parens, you are defining a rule for the compiler.  Think of the  
 parentheses as an extension of the function name, like punctuation.

But you say no parens means query, parens means action. This is sheer unchecked convention.

But we already have sheer unchecked convention! I could make a function called sort that reverses an array. I don't get why it makes any difference to you that the meaning of parentheses and no parentheses is used by the author of the function. How is this bad or somehow worse than what we have now? If you don't trust the author's functions do what they are named for, don't use his functions and properties. Since C was invented, we have had the convention that () means function, lack of () means property. You are acting like the last 37 years of programming languages never existed, and this is some "new radical" convention. D is of C lineage, so using long standing C conventions should not confuse people.
 Maybe less confusion, definitely more burden.

The burden is on the author to come up with meaningful function names already. With real properties, at least that task is easier because you don't need to add extra context to ensure a word is treated as a verb or a noun (e.g. 'isEmpty' in order to make sure someone doesn't mistake 'empty' for an action). The compiler enforces the requirement of property syntax vs. function syntax, so no burden there. -Steve
Jul 31 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 7:43 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Leandro Lucarella wrote:
 Leandro Lucarella, el 27 de julio a las 11:15 me escribiste:
 If dip5 is as bad as opGet_foo is I'll delete it right now.

I think DIP5 should be removed, no matter how good or bad it is. If the DIP has some consensus here, then somebody should add it to DIP4 as an alternative.

And BTW, *please* add an author to the proposal!

It might be good to define a sort of an ombudsman for any given DIP. The ombudsman would collect suggestions by email or NG and fold the relevant ones in the DIP text.

I think it might also be good to have a two-tier system. "DIPs in training" can be made by anyone on the wiki. And then after some period of discussion, editing, and perhaps an informal community vote, *then* they can earn the official title of DIP and be moved to a different section of the wiki for DIPs that have significant community support. Or at least which are agreed to surpass some minimal editorial threshold. I think this could help prevent DIPs from turning into a Wiki form of the Eigenpoll. --bb
Jul 27 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 27, 2009 at 4:34 PM, Chad
J<chadjoan __spam.is.bad__gmail.com> wrote:
 Rainer Deyke wrote:
 Kagamin wrote:
 If dip5 is as bad as opGet_foo is I'll delete it right now.

What's wrong with opGet_foo? =A0I like it better than any of the propose=


 new syntaxes for properties:
 =A0 - It keeps the language simple by not adding more syntactic clutter.
 =A0 - In the (very common) case of calculated read-only properties,
 opGet_foo means less typing.
 =A0 - With opGet_foo, the semantics of overriding properties in subclass=


 are obvious. =A0You can override just the getter, just the setter, or ev=


 just one setter of many. =A0You might also be able to do this with a
 dedicated syntax, but it's a lot less obvious.

This seems to me like it adds more syntactic clutter than adding a keyword would: PropertyDecl: =A0 =A0 =A0 =A0PropertyGetter =A0 =A0 =A0 =A0PropertySetter PropertyGetter: =A0 =A0 =A0 =A0Type 'opGet_' Identifier '(' ')' PropertySetter: =A0 =A0 =A0 =A0Type 'opSet_' Identifier '(' Type ')' Unfortunately, this grammar is wrong. =A0It needs to be more complicated. =A0That's because there is no whitespace between 'opGet_' and Identifier or between 'opSet_' and Identifier. =A0This is very unusual since just about any other pair of tokens in the language is separated by either optional or mandatory whitespace (AFAIK). I understand that opGet_XX and opSet_XX are supposed to be parsed as function declarations or somesuch, but I somehow get the feeling that it won't fly. =A0It seems to me like that just makes the semantic analysis d=

 some of the parsing work. =A0That's because the semantic analyzer now has
 to pull apart the op(G|S)et_ from the Identifier and declare a property
 with that identifier as its name. =A0That step has to be done at some
 point and it seems like parsing would be the more appropriate phase for i=

Nono, I don't think that's really what's being suggested. It'd work more like operator overloading. "opAdd" and the like aren't parsed any different from any other functions, and they're not represented differently inside the compiler; they're just functions with "magical" names. Similarly, opGet_foo would be a normal function in any way, and its name would only be significant in the case of "obj.foo", which *could* be rewritten as "obj.opGet_foo()" (or "obj.opSet_foo"). Also, if you think D can be parsed without any information from the semantic pass? I've got news for you..
Jul 27 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 27, 2009 at 8:16 PM, Chad
J<chadjoan __spam.is.bad__gmail.com> wrote:
 Jarrett Billingsley wrote:
 On Mon, Jul 27, 2009 at 4:34 PM, Chad
 J<chadjoan __spam.is.bad__gmail.com> wrote:

 Nono, I don't think that's really what's being suggested. =A0It'd work
 more like operator overloading. =A0"opAdd" and the like aren't parsed
 any different from any other functions, and they're not represented
 differently inside the compiler; they're just functions with "magical"
 names. =A0Similarly, opGet_foo would be a normal function in any way,
 and its name would only be significant in the case of "obj.foo", which
 *could* be rewritten as "obj.opGet_foo()" (or "obj.opSet_foo").

Op overloading is a bit different since the identifier never changes. What you are matching is always one of opAdd, opSub, opNeg, etc. =A0But when matching this there are an infinite number of permutations: opGet_foo, opGet_bar, opGet__, opGet_a, ..., opGet_aa, opGet_ab, etc. I'm not saying it's hard to do, just that it looks to me like it defeats its own virtues.

I'm just saying it doesn't require any change to the grammar, is all.
 Also, if you think D can be parsed without any information from the
 semantic pass? =A0I've got news for you..

Yeah, that's still not a good reason to make a bad thing worse :/

I wasn't suggesting that ;)
Jul 27 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jul 27, 2009 at 6:33 PM, Benji Smith<dlanguage benjismith.net> wrot=
e:
 On Mon, Jul 27, 2009 at 4:34 PM, Chad
 This seems to me like it adds more syntactic clutter than adding a
 keyword would:

 PropertyDecl:
 =A0 =A0 =A0 PropertyGetter
 =A0 =A0 =A0 PropertySetter

 PropertyGetter:
 =A0 =A0 =A0 Type 'opGet_' Identifier '(' ')'

 PropertySetter:
 =A0 =A0 =A0 Type 'opSet_' Identifier '(' Type ')'



Well, you could think of it as "operation" instead of "operator" in this ca= se. But anyway I agree. Getters and setters are ubiquitous. I don't want to have to see half a dozen instances of that eyesore in every class I write. The property keyword looks nice though. What prevents us from doing more generic annotations with syntax like property? --bb
Jul 27 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 27, 2009 at 9:33 PM, Benji Smith<dlanguage benjismith.net> wrot=
e:

 But I think the same thing can be more elegantly written using the
 "property" keyword:

 =A0private int _x;
 =A0public property int X() { return _x; }
 =A0protected property X(int value) { _x =3D value; }

 The only disadvantage I see there is the introduction of a keyword. And
 that's definitely a disadvantage. But, compared to the "op" syntax, I thi=

 it's the lesser of two evils.

Oh, I agree with you; out of all the proposals, the 'property' attribute is the cleanest. I just wanted to clear up some misconceptions about the opGet/Set proposal :)
Jul 27 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, Jul 27, 2009 at 11:13 PM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Rainer Deyke wrote:
 Benji Smith wrote:
 3) The existence of "magical" identifiers complicates the language
 design. Because the rules that apply to those magical identifiers is
 different than the rules applying to non-magical identifiers.

I don't see how that's the case. =A0Everywhere opGet_foo appears, it is treated exactly like every other identifier. The only thing "special" about these identifiers is that they can be generated automatically by the compiler. =A0When the compiler sees 'a.b'=


 and 'b' is not a field or method of 'a', it rewrites this to
 'a.opGet_b()'.

Oh. You stole my thunder. +1

While the opGet_foo and opSet_foo are okay, what are your thoughts on the 'property' attribute on a function? I know you said you didn't really like the idea of having to name your range's empty function 'opGet_empty'. The property attribute also has the nice property (heh) that you can call the property setters and getters either as properties or as functions (i.e. "r.empty" or "r.empty()"). Basically, the behavior would be *exactly* as it is now, except you'd have to explicitly state with which functions it would be legal. Or is the idea of introducing the 'property' keyword too controversial? I mean, if it is, there are plenty of keywords in D that *only* have one meaning. I'm sure one of them could be repurposed ;)
Jul 27 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Tue, 28 Jul 2009 04:57:57 -0400, Kagamin thusly wrote:

 Andrei Alexandrescu Wrote:
 
 I know you said you didn't
 really like the idea of having to name your range's empty function
 'opGet_empty'.

Correct. I'd rather try to disambiguate the rather rare case when a property returns a delegate etc. For me, I get a breath of fresh air whenever I get to not write "()". I can't figure how some are missing it.

It's agains C look and feel to call function without braces. It's not a problem to write code. It's a problem to read and understand it, isn't it? Isn't current programming techniques development aimed to ease maintenance?

Yes, the C syntax has been scientifically proven to be the optimal for humans to read. All the extra braces and semicolons are there to guide your eye movement. I simply don't get why anyone would use a language without those. In fact I see one problem in D when compared to C++: C++: class Foo {}; vs D: class Foo {} The missing semicolon makes me vomit. I wish the syntax will be fixed some day. It would probably also ease the maintenance in case of syntactic errors.
Jul 28 2009
prev sibling next sibling parent language_fan <foo bar.com.invalid> writes:
Mon, 27 Jul 2009 22:57:09 -0500, Andrei Alexandrescu thusly wrote:

 Correct. I'd rather try to disambiguate the rather rare case when a
 property returns a delegate etc. For me, I get a breath of fresh air
 whenever I get to not write "()". I can't figure how some are missing
 it.

You would likely love Scala, then. In addition, those guys decided to make the semicolons optional and support first class tuples and traits. Revolutionary, I'd say.
Jul 28 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 31 Jul 2009 20:13:55 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Sergey Gromov wrote:
 Fri, 31 Jul 2009 00:02:16 -0400, Benji Smith wrote:

 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in  
 message news:h4lsuo$aut$1 digitalmars.com...
 For me, I get a breath of fresh air whenever I get to not write  
 "()". I can't figure how some are missing it.

breath at how incredibly sloppy it is. Great, just what I need: Yet another thing that forces me to make the completely unnecessary choice between using something inconsistently or making up and sticking to a completely arbitrary convention that can't be enforced. Sloppy, sloppy, sloppy. Especially considering it's all for the sake of a "feature" that doesn't accomplish a damn thing, doesn't solve any problem, not even a trivial one, doesn't do anything but clutter the language.



Maybe we should vote on this too. BTW, seems like the last poll wasn't quite the expected landslide against the dictature :o). Andrei

I believe that poll question was badly formulated.
Jul 31 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Jul 2009 12:13:55 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Maybe we should vote on this too. BTW, seems like the last poll wasn't  
 quite the expected landslide against the dictature :o).

I think the poll might have been skewed due to context (forget my newsgroup poll, that was worthy of an abortion, but I also didn't mean to submit it :), I'm talking about Ary's) The question was asked, what do you think this code means. In the context of D, where you know a symbol without parentheses can mean either a function or a property/field, I'm certain there were several respondants who didn't understand it was asking what they think is best, not *what D currently does*. Ask that same questions to C++ developers and see what you get... It's hard to phrase the question properly without bias to a group of people who already know the current behavior. Maybe something like: Assume the D programming language required parentheses for normal parameter-less functions, and required no parentheses for parameter-less functions that returned a property. For example, the following code should imply a getter for a filter inside x: auto tmp = x.filter; And the following code should imply performing a filtering action using x, returning the result: auto tmp = x.filter(); Do you think it's worth adding such a capability, given that you will then no longer be able to call ordinary parameter-less functions without parentheses, an author of a property function must properly indicate that the function is a property, and the compiler must trust the author for this implication? -Steve
Jul 31 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Jul 2009 13:11:45 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Fri, 31 Jul 2009 12:13:55 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Maybe we should vote on this too. BTW, seems like the last poll wasn't  
 quite the expected landslide against the dictature :o).

newsgroup poll, that was worthy of an abortion, but I also didn't mean to submit it :), I'm talking about Ary's) The question was asked, what do you think this code means. In the context of D, where you know a symbol without parentheses can mean either a function or a property/field, I'm certain there were several respondants who didn't understand it was asking what they think is best, not *what D currently does*. Ask that same questions to C++ developers and see what you get... It's hard to phrase the question properly without bias to a group of people who already know the current behavior. Maybe something like: Assume the D programming language required parentheses for normal parameter-less functions, and required no parentheses for parameter-less functions that returned a property. For example, the following code should imply a getter for a filter inside x: auto tmp = x.filter; And the following code should imply performing a filtering action using x, returning the result: auto tmp = x.filter(); Do you think it's worth adding such a capability, given that you will then no longer be able to call ordinary parameter-less functions without parentheses, an author of a property function must properly indicate that the function is a property, and the compiler must trust the author for this implication?

There's one way to figure it out: Ask away!

I'm a little gunshy after the last one I did. Can someone else proofread it and tell me if the question is a good one? -Steve
Jul 31 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Jul 2009 13:34:13 -0400, Marianne Gagnon <auria.mg gmail.com>  
wrote:

 I think the poll might have been skewed due to context (forget my
 newsgroup poll, that was worthy of an abortion, but I also didn't mean  
 to
 submit it :), I'm talking about Ary's)

 The question was asked, what do you think this code means.  In the  
 context
 of D, where you know a symbol without parentheses can mean either a
 function or a property/field, I'm certain there were several respondants
 who didn't understand it was asking what they think is best, not *what D
 currently does*.  Ask that same questions to C++ developers and see what
 you get...

 It's hard to phrase the question properly without bias to a group of
 people who already know the current behavior.  Maybe something like:

 Assume the D programming language required parentheses for normal
 parameter-less functions, and required no parentheses for parameter-less
 functions that returned a property.  For example, the following code
 should imply a getter for a filter inside x:

      auto tmp = x.filter;

 And the following code should imply performing a filtering action using  
 x,
 returning the result:

      auto tmp = x.filter();

 Do you think it's worth adding such a capability, given that you will  
 then
 no longer be able to call ordinary parameter-less functions without
 parentheses, an author of a property function must properly indicate  
 that
 the function is a property, and the compiler must trust the author for
 this implication?

IMP, the parenthesis thing is not about parameters vs function. I think the question is about whether the function can modify my object or not. e.g. if I call foo = object.x; I assume 'object' was not modified. But if x can be like a function, disguised as a parameter, I can modify my object without knowing. In C++, I'd say this behaviour is ok for 'const' functions. Now I haven't taken the time to study D constness, so I can't readily tell what is the direct equivalent, but I guess you understand what I mean. In short, IMO everything that can modify my object should require () to stress that this is an action with possible side effects, not merely a getter.

Hm... this is somewhat similar to const, be we already have const in D. I think you and I or on the same page -- parentheses implies action, no parentheses implies no action (and therefore, no change to the object). However, I can envision properties that do take actions (such as logging) and may even change the object (such as caching), and functions that perform actions but do not modify the object. I wouldn't say modification of the object is a direct 1-to-1 mapping with parens or lack of parens, but I'd definitely say that lack of parens implies no "public" modification. However, none of this would be enforcible via the compiler. For that, we have const. A const property would make loads of sense, but unfortunately, it modifies the contract you have with the object members when calling it (see DIP2 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2). So to sum up, with this feature lack of parentheses would imply no action, but would not be enforced. However, it would be considered incorrect logic if the rule was not followed, similar to naming your functions something other than what they do. -Steve
Jul 31 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 31 Jul 2009 16:16:43 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
  So to sum up, with this feature lack of parentheses would imply no  
 action, but would not be enforced.  However, it would be considered  
 incorrect logic if the rule was not followed, similar to naming your  
 functions something other than what they do.

I am leery of such a feature. It essentially introduces a way to define conventions that are in no way useful to, or checked by, language rules. In my experience this has been a bad idea more often than not. Of course, simple conventions such as capitalized types, camel case values, and so on, are useful and easy to follow. But as soon as complexity of conventions becomes only a bit higher, their usefulness becomes a downward step function. In C++ there were two ways to define a template: template <class T> ... and template <typename T> ... The existence of "typename" as a keyword has an interesting history of its own, but in here it was allowed for the reason that T may be any type, not a class type. So, people thought, it would be less confusing if people wrote "typename" for type template parameters. So far so good. When I wrote Modern C++ Design, I decided to make a bold move and use "typename" in code samples wherever it could have been any type, and "class" wherever the type was indeed restricted to a class type. I documented that convention in the introduction and off I went. The experiment was an unqualified failure. First of all, people got confused. Then some found actual "bugs" because I used one keyword when I had promised to use the other. Of course I had bugs - there's plenty of template code and no automated means to check it! If I could turn back in time, I'd just use "class" everywhere. There are similar cases in other communities, probably Perl being a prime example because it allows most everything to mean something, so conventions are very important. My reading of the experience on espousing complex, unchecked, and unused reified conventions? Don't.

Hm... in C++, I don't think that convention is checked at all. For example, I can do template<class T> and specify int as the T, and everything compiles. But in the case of properties only allowed without parens, functions require parens, you are defining a rule for the compiler. Think of the parentheses as an extension of the function name, like punctuation. Like the word "so": so! so? Two different meanings, same word. Analogously to our property discussion, the compiler can know that one is an exclamation, and one is a question, but doesn't really know the meaning of "so!" or "so?". It can enforce that you use a question where a question is needed, and an exclamation where an exclamation is needed. But a person sees it immediately and understands the difference in the implied meaning. The parens-means-function and lack-of-parens-means-field convention is well well established (except for D) as something that works, I don't think you would have the same confusion as your typename/class example. -Steve
Jul 31 2009
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-27 04:54:57 -0400, Kagamin <spam here.lot> said:

 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5
 
 As namespaces were proposed, a variant of them is in DIP5 now.

Hum, what's the difference between: int width { private int val; int opGet() { return val; } int opSet(int newVal) { return val = newVal; } } and namespace width { private int val; int opGet() { return val; } int opSet(int newVal) { return val = newVal; } } ? I mean, what's the purpose of giving a type to the namespace when you already have a type for the opGet return value? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 27 2009
parent reply Kagamin <spam here.lot> writes:
Michel Fortin Wrote:

 I mean, what's the purpose of giving a type to the namespace when you 
 already have a type for the opGet return value?

It's more of property than namespace, so opGet return type can be inferred from the property type. See the paragraph about type inference for getter and setter.
Jul 27 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-27 09:40:04 -0400, Kagamin <spam here.lot> said:

 Michel Fortin Wrote:
 
 I mean, what's the purpose of giving a type to the namespace when you
 already have a type for the opGet return value?

It's more of property than namespace, so opGet return type can be inferred from the property type. See the paragraph about type inference for getter and setter.

Ah, I see. Makes sense. But personally I think I prefer the basic namespace approach. I just don't like functions with some magic names that have a special syntax in some special context, even if that syntax optional. Especially since there is some risk of incoherency; for instance should this be illegal? int width { float opGet(); } or even this? float width { void opSet(int); } And if so, what about this: float width { void opSet(int); // version with int-optimized calculations void opSet(float); } With the namespace approach (renamed the keyword to "property" here) there is no such ambiguity possible: property width { float opGet(); void opSet(int); // version with int-optimized calculations void opSet(float); } -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 27 2009
prev sibling parent reply "Jimbob" <jim bob.com> writes:
"Kagamin" <spam here.lot> wrote in message 
news:h4jq11$1jvq$1 digitalmars.com...
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5

 As namespaces were proposed, a variant of them is in DIP5 now.

Why not just.. class Foo { private: int mx; public: int x.opGet() { return mx; } void x.opSet(int i) { mx = i; } void x.opInc() { mx++; } } or instead... class Foo { private: int mx; public: int x:opGet() { return mx; } void x:opSet(int i) { mx = i; } void x:opInc() { mx++; } } So that foo.x++; Would be compiled as foo.x.opInc(); In the same way foo++; Would is compiled as foo.opInc();
Jul 28 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jimbob wrote:
 "Kagamin" <spam here.lot> wrote in message 
 news:h4jq11$1jvq$1 digitalmars.com...
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP5

 As namespaces were proposed, a variant of them is in DIP5 now.

Why not just.. class Foo { private: int mx; public: int x.opGet() { return mx; } void x.opSet(int i) { mx = i; } void x.opInc() { mx++; } } or instead... class Foo { private: int mx; public: int x:opGet() { return mx; } void x:opSet(int i) { mx = i; } void x:opInc() { mx++; } } So that foo.x++; Would be compiled as foo.x.opInc(); In the same way foo++; Would is compiled as foo.opInc();

Nice. Is x.opGet overridable? This is a trick question hinting at the fact that you'd need to define that. I presume it's reasonable to say it is, unless people say final int x.opGet() { ... } or something. My point is that when you define new syntax you must add a host of ancillary definitions that reveal how it interacts with the existing language. This problem is obviated by the lowering approach. Andrei
Jul 28 2009