www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: poll for properties

reply Dimitar Kolev <DimitarRosenovKolev hotmail.com> writes:
Bill Baxter Wrote:

 On Wed, Jul 29, 2009 at 4:35 AM, Dimitar
 Kolev<DimitarRosenovKolev hotmail.com> wrote:
 Kagamin Wrote:

 bearophile Wrote:

 Dimitar Kolev:
 None. I would call it isEmpty or isEmpty().

This may interest Andrei: lot of people here (me too) seem to think that the name "isEmpty" is better than "empty" for that purpose.


The properties discussion arises from the people who can not think of good names for variables and functions.

Andrei decided to use empty over isEmpty because he wanted names as short as possible for the fundamental ops for ranges. It had nothing to do with not being able "think of" isEmpty. He thought of it and rejected it as too cumbersome for this purpose. And it shouldn't be particularly ambiguous if understood to be an attribute of the range and not an action on the range. Unfortunately we have no way in the language to specify that distinction.
 So they get confused by things like empty. It should be isEmpty the state and
empty the function then there will be no confusion which does what and people
can finally realize that () are optional.

If you don't have dedicated property syntax, then I agree, you probably should avoid the ambiguity and resort to isEmpty.
 This is just an example but good names are the reason for all this weirdness.
Or bad names.

I think having dedicated property syntax makes it easier to choose good names because there are fewer ambiguity landmines to watch out for. --bb

As long as you can call variables and functions the same way with a . and as long as you can dismiss the () there is no way to make a distinction. There are 3 options: 1) Enforce () for all functions. 2) Make () optional and people start choosing good names and not being influenced by laziness or whatever else. 3) Make calling properties in a special way. Some weird syntax like a#a = 9 or a$a = 9.
Jul 29 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jul 29, 2009 at 9:52 AM, Dimitar
Kolev<DimitarRosenovKolev hotmail.com> wrote:
 Bill Baxter Wrote:

 On Wed, Jul 29, 2009 at 4:35 AM, Dimitar
 Kolev<DimitarRosenovKolev hotmail.com> wrote:
 Kagamin Wrote:

 bearophile Wrote:

 Dimitar Kolev:
 None. I would call it isEmpty or isEmpty().

This may interest Andrei: lot of people here (me too) seem to think=










l from those...
 The properties discussion arises from the people who can not think of =



 Andrei decided to use empty over isEmpty because he wanted names as
 short as possible for the fundamental ops for ranges. =A0It had nothing
 to do with not being able "think of" isEmpty. =A0He thought of it and
 rejected it as too cumbersome for this purpose.

 And it shouldn't be particularly ambiguous if understood to be an
 attribute of the range and not an action on the range. =A0Unfortunately
 we have no way in the language to specify that distinction.

 So they get confused by things like empty. It should be isEmpty the st=



and people can finally realize that () are optional.
 If you don't have dedicated property syntax, then I agree, you
 probably should avoid the ambiguity and resort to isEmpty.


 This is just an example but good names are the reason for all this wei=



 I think having dedicated property syntax makes it easier to choose
 good names because there are fewer ambiguity landmines to watch out
 for.

 --bb

As long as you can call variables and functions the same way with a . and=

Exactly. That's what this whole long properties discussion has been about. I guess you haven't had a chance to read all those many posts.
 There are 3 options:

 1) Enforce () for all functions.

This is what "properties" folks are asking for.
 2) Make () optional and people start choosing good names and not being in=

This is status quo.
 3) Make calling properties in a special way. Some weird syntax like
 a#a =3D 9 or a$a =3D 9.

This is just wierd and doesn't solve the basic problem property-like syntax is supposed to solve, which is allowing the designer of a class to change implementation from a simple field to a function without affecting client code. --bb
Jul 29 2009