On Wed, Jul 29, 2009 at 9:52 AM, Dimitar
Kolev<[email protected]> wrote:
> Bill Baxter Wrote:
>
>> On Wed, Jul 29, 2009 at 4:35 AM, Dimitar
>> Kolev<[email protected]> 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.

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 
> influenced by laziness or whatever else.

This is status quo.


> 3) Make calling properties in a special way. Some weird syntax like
> a#a = 9 or a$a = 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

Reply via email to