• Dimitar Kolev (7/44) Jul 29 2009 As long as you can call variables and functions the same way with a . an...
• Bill Baxter (20/64) Jul 29 2009 that the name "isEmpty" is better than "empty" for that purpose.

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 very properties discussion comes from D living in the context of C family
languages and their good practices. Python somehow managed to rebel from
those...

 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.

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=





 that the name "isEmpty" is better than "empty" for that purpose.

 The very properties discussion comes from D living in the context of =




C family languages and their good practices. Python somehow managed to rebe=
l from those...
 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. =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=



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



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

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=

fluenced by laziness or whatever else.

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