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.


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.
 

 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 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.


 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?


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.


 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.


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?


 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.


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?


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.


 
 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?


 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.


 
 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?


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.


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.


...

-- 
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.


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.


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.


 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.


Andrei
Jul 27 2009
parent reply 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
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 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
parent reply 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=




d

 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=




es

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




en

 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=


o

 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=


t.

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
next sibling parent reply 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
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 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
parent reply 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
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.


 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


 
 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 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 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'.


 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?


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.


 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.


Actually r.empty() does not empty the range :o).

Andrei
Jul 28 2009
parent reply 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
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

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

this is something that Sun invented?



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'.


 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?


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.


 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.


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
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.


 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


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 reply "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.


 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


 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
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.


 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


 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 reply "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
next sibling parent reply 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
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).


  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!


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 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 "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
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 "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
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 "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
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 "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.


  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.


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.


  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.


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.



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
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.


  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.


 
 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

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.



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.


  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.


 
 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.


 

 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
parent reply "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
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 "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.


  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


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
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.


  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


 
 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 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 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 reply 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=






. 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-ar=




g

 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 th=




e

 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=


 to

 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
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


 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 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 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.


 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


 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
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.


 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


 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.


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 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 parent reply 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
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.


 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 ;)


I appreciate the asking.


 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.


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 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 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
next sibling 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 "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.


  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!


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 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.


 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


 
 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.

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

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 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 ')'




 2) A property is not an operator. So the "op" prefix is lying to you.


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
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?


 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


Sorry, I misread - I was still referring to properties in particular.

Andrei
Jul 28 2009
prev 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.
 -------------



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 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=


nk

 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 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 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 next 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
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 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.


Glad to see I'm not the only one to think like this :-)
Later more semantic attributes can be added, for example to express things that
the compiler can use to parallelize code better, to know about pointer
aliasing, to tell the compiler what asm functions can be inlined (currently
done with a pragma in LDC), etc.

What syntax do you want to use when you want more than one attribute?
 something1  somethingelse
...

Bye,
bearophile
Jul 28 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 28, 2009 at 11:12 AM, bearophile<bearophileHUGS lycos.com> wrot=
e:

 Bill Baxter:

 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.


 Glad to see I'm not the only one to think like this :-)
 Later more semantic attributes can be added, for example to express thing=


s that the compiler can use to parallelize code better, to know about point=
er aliasing, to tell the compiler what asm functions can be inlined (curren=
tly done with a pragma in LDC), etc.

 What syntax do you want to use when you want more than one attribute?
  something1  somethingelse
 ...


I don't know.  I'm actually not too up on how these things are used in

seems like a good idea to solve a more general problem if possible.
And when someone reminded us that "deprecated" is a keyword, that set
me off.


Something else that occurred to me while reading the keyword list is
that "switch" is a horrible keyword hog.  Three keywords just for that
one construct!   If D didn't have a switch statement today and were
looking to add one, somehow I doubt that there would be sufficient
support for dedicating three whole keywords to the thing.    Switch is
a monstrosity pretty much any way you look at it.  Sh had the right
idea there.  Is "case" really necessary there?  Some syntax should
suffice I would thing.  And "default" is probably the world's most
useless keyword.  Why not "else:" or "*:" instead of introducing a
whole new keyword?

--bb
Jul 28 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Switch is a monstrosity pretty much any way you look at it.  Sh had the right
 idea there.  Is "case" really necessary there?  Some syntax should
 suffice I would thing.  And "default" is probably the world's most
 useless keyword.  Why not "else:" or "*:" instead of introducing a
 whole new keyword?


Case of Pascal is better (2 keywords where "of" isn't that useful, begin-end
are optional if you want more than one instruction, Pascal isn't
case-sensitive):

Case X of
  1: Begin
        ...
      End;
  2 .. 10: Begin
        ...
      End;
  ...
  Else Begin
         ...
       End;
End; {CASE}

But D is backward compatible with C (unlike languages like Scala, that
eventually D will need to take a look at), so this is an academic topic.

Bye,
bearophile
Jul 28 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Tue, Jul 28, 2009 at 12:01 PM, bearophile<bearophileHUGS lycos.com> wrot=
e:

 Bill Baxter:

 Switch is a monstrosity pretty much any way you look at it. =A0Sh had th=




e right

 idea there. =A0Is "case" really necessary there? =A0Some syntax should
 suffice I would thing. =A0And "default" is probably the world's most
 useless keyword. =A0Why not "else:" or "*:" instead of introducing a
 whole new keyword?


 Case of Pascal is better (2 keywords where "of" isn't that useful, begin-=


end are optional if you want more than one instruction, Pascal isn't case-s=
ensitive):

 Case X of
 =A01: Begin
 =A0 =A0 =A0 =A0...
 =A0 =A0 =A0End;
 =A02 .. 10: Begin
 =A0 =A0 =A0 =A0...
 =A0 =A0 =A0End;
 =A0...
 =A0Else Begin
 =A0 =A0 =A0 =A0 ...
 =A0 =A0 =A0 End;
 End; {CASE}

 But D is backward compatible with C (unlike languages like Scala, that ev=


entually D will need to take a look at), so this is an academic topic.

Except that it's very much not backwards compatible with C syntax in
constructs that are very frequent in C: typedef/alias, #define.
Changing the keywords used in a switch would be a very mechanical
transformation, like changing typedef to alias everywhere it appears
in C code you're translating.

--bb
Jul 28 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Changing the keywords used in a switch would be a very mechanical
 transformation, like changing typedef to alias everywhere it appears
 in C code you're translating.


Once you have changed the keyword used in the case/switch, then you (and me)
probably want to fix other problems of switch (fall through).
Recently here I have suggested the creation of a small tool (written in Python,
not in D) like 2to3 (used to convert Python2 to Python3) to convert C to D :-)
I don't know how much long such program may become (2to3 uses a parser of the
std lib).

Bye,
bearophile
Jul 28 2009
prev sibling next sibling parent reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
language_fan Wrote:


 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.


The missing semicolon makes you vomit? Come on that is an exaggeration. 

I had problems in C++ with that stupid semicolon that was there for no apparent
reason but to be forgotten by the programmers and to cause a bunch of
non-understandable mistakes to be generated by the stupid debuggers.

{} - should be a end point of its own without requiring people to tell it that
there is nothing beyond it.

It is like saying that you should put ";" after function definition.

What errors will the missing ";" cause?

As I said {} should be an end of its own.
Jul 28 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 28, 2009 at 4:49 PM, Dimitar
Kolev<DimitarRosenovKolev hotmail.com> wrote:

 language_fan Wrote:

 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.


 The missing semicolon makes you vomit? Come on that is an exaggeration.

 I had problems in C++ with that stupid semicolon that was there for no
apparent reason but to be forgotten by the programmers and to cause a bunch of
non-understandable mistakes to be generated by the stupid debuggers.

 {} - should be a end point of its own without requiring people to tell it that
there is nothing beyond it.

 It is like saying that you should put ";" after function definition.

 What errors will the missing ";" cause?

 As I said {} should be an end of its own.


His post was *extremely* sarcastic.  ;)
Jul 28 2009
parent Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Jarrett Billingsley Wrote:


 On Tue, Jul 28, 2009 at 4:49 PM, Dimitar
 Kolev<DimitarRosenovKolev hotmail.com> wrote:

 language_fan Wrote:

 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.


 The missing semicolon makes you vomit? Come on that is an exaggeration.

 I had problems in C++ with that stupid semicolon that was there for no
apparent reason but to be forgotten by the programmers and to cause a bunch of
non-understandable mistakes to be generated by the stupid debuggers.

 {} - should be a end point of its own without requiring people to tell it that
there is nothing beyond it.

 It is like saying that you should put ";" after function definition.

 What errors will the missing ";" cause?

 As I said {} should be an end of its own.


 
 His post was *extremely* sarcastic.  ;)


Thank you for the clarification. :)
Jul 28 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Chad J Wrote:


 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.



managed to not fail so miserably. Maybe because there's so much experience to
share? Or something is not right with library designers?
Jul 29 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

But, man, am I so excited to be able to overload my functions and templated
functions!<


The "support for fast and reliable build tools to the frontend" is a first step
of one of the things people have asked for for a lot of time, so once in a
while Walter listens to people, so it's not wise to stop asking things.

Recently we have written a list of things to be done before D2 comes out of
alpha state (and the top of the wish list there are Stack tracing and
Reflection API). Overloading functions & templates was not asked by anyone.

There are some things in the design of D1/D2 that aren't that useful, while
there are some things that are quite useful but absent. The only way to remove
the things that aren't much useful is to break backwards compatibility, this is
hard to do in a language that's already in beta stage.

I suggest Walter to write some real program using D1, programs that future D
programmers may really want to write, for example using Descent. This may show
him some of the things people ask for and why they ask for them. Also taking a

is designed for quite practical purposes).

Bye,
bearophile
Aug 01 2009
parent reply Arthur Lloyd <via google.com> writes:
bearophile Wrote:






Scala is built by impractical computer scientists, D is a masterpiece coming
from the software engineering community. Is there really anything worth
learning from it? If you implement features that come from a scientific
language, laymen can't use D anymore or it becomes unusably slow.

I've tried Scala and the language was too much different from C/C++/D to be
useful in real world programming:
def foo = 1 + 4 vs int foo() { return 1 + 4; }
val foo: String = "bar" vs string foo = "bar";
Aug 03 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 03 Aug 2009 14:40:20 +0400, Arthur Lloyd <via google.com> wrote:


 bearophile Wrote:






 Scala is built by impractical computer scientists, D is a masterpiece  
 coming from the software engineering community. Is there really anything  
 worth learning from it? If you implement features that come from a  
 scientific language, laymen can't use D anymore or it becomes unusably  
 slow.

 I've tried Scala and the language was too much different from C/C++/D to  
 be useful in real world programming:
 def foo = 1 + 4 vs int foo() { return 1 + 4; }
 val foo: String = "bar" vs string foo = "bar";


I don't see that much of a difference. You just got used to C family  
languages, learn something new (Lisp, Haskel, Ruby, Erlang etc).
Aug 03 2009