I'm writing the Range helper for the List class, which has (roughly) the
following interface:

    template(T)
    {
        public class ListRange
        {
        public:
            boolean open();
            value_type current();
            void advance();
        public:
            int opApply(. . .);
        }
    }

As well as being able to be applied to foreach, a Range may be enumerated individually via the following idiom:

    List!(int)    l = . . .;

    List!(int).range_type    r    =    l[]; // A full slice. Other slices
are available, as well as several kinds of filtering

    for(; r.open; r.advance())
    {
        printf("%d ", r.current);
    }

Anyway, the point I want to put accross is that I think D's implicit properties mechanism is entirely appropriate for open() and current(), but entirely inappropriate for advance(), because it is a mutating method call, and *not* a property. But because it takes no parameters, it could be called in property style, i.e. without the (). I would like some mechanism in the language to proscribe this, perhaps something like:

    template(T)
    {
        public class ListRange
        {
        public:
            boolean open();
            value_type current();
            method void advance();
or
            no property void advance();
        public:
            int opApply(. . .);
        }
    }

or even better would be a requirement to apply the property to any methods that are up for implicit property interpretation, as in:

    template(T)
    {
        public class ListRange
        {
        public:
            property boolean open();
            property value_type current();
            void advance();
        public:
            int opApply(. . .);
        }
    }

I know some people have grokked "the D way", as in the .dup "method" in built-in arrays, but I think it's a mistake not to differentiate between attributes (methods / fields) and modifying methods.

Thoughts everyone?

"Matthew" <matthew.hat@stlsoft.dot.org> wrote:

> I know some people have grokked "the D way", as in the .dup "method" in built-in arrays, but I think it's a mistake not to differentiate between attributes (methods / fields) and modifying methods.
> 
> Thoughts everyone?

In your example, advance is void, so shouldn't be a property anyway, whether it has side effects or not. What's the "property"? (but one could define advance to have a boolean success return value...)

Personally, I like the C# way, where you explicitly write get{} and/or set{} methods:

class Person
    public string Name {
        get { return myName; }
        set { myName = value; }
    }
};

Here, you have to specify a type, and can leave out set{} if it's read only.

But if not that, I think explicitly saying "property" on the declaration would be good -- and without it, you would have to use method call notation. It should be one or the other, but not wishy-washy like Perl's TMTOWTDI, otherwise the language is getting sloppy and Perl already covers that territory (it would be nice to learn not only from C++'s mistakes).

In fact, I might like an explicit keyword better than C#'s way anyway: a property has the keyword "property" (somewhere), and may only be used with property syntax, using the "say what you mean and mean what you say" principle. No one is misled by it. Also makes it easy to search for with your text editor, just like "cast".

-- 
dave

Dave Sieber wrote:
> Personally, I like the C# way, where you explicitly write get{} and/or set{} methods:
> 
> class Person
>     public string Name {
>         get { return myName; }
>         set { myName = value; }
>     }
> };

We have it similarly in the Lux concept-language... a la:

define class Person {
  define public {
    property str Name {
      Name = "Person_Default_Name";
      str get() { return Name; }
      str set(str x) { return Name = x; }
      str set([]str xx) {
        import std.utils.string;
        return Name = xx:join("_");
      }
    }
  }
}

Something worth noting about the Lux syntax, and which I'd like to see in D if it were to adopt an explicit property syntax, is that the get/set methods are defined with full prototypes, allowing you to support multiple types on one property.  And I suppose in D one could even templatize a property thereby making it support all types universally, or at least in theory.

-C. Sauls
-Invironz

That's pretty much how I feel, except that instinct tells me that allowing properties to also be called in method syntax will provide for more genericity down the line.


"Dave Sieber" <dsieber@spamnot.sbcglobal.net> wrote in message news:Xns94D244BCD2FB8dsiebersbc@63.105.9.61...
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote:
>
> > I know some people have grokked "the D way", as in the .dup "method" in built-in arrays, but I think it's a mistake not to differentiate between attributes (methods / fields) and modifying methods.
> >
> > Thoughts everyone?
>
> In your example, advance is void, so shouldn't be a property anyway, whether it has side effects or not. What's the "property"? (but one could define advance to have a boolean success return value...)
>
> Personally, I like the C# way, where you explicitly write get{} and/or set{} methods:
>
> class Person
>     public string Name {
>         get { return myName; }
>         set { myName = value; }
>     }
> };
>
> Here, you have to specify a type, and can leave out set{} if it's read only.
>
> But if not that, I think explicitly saying "property" on the declaration would be good -- and without it, you would have to use method call notation. It should be one or the other, but not wishy-washy like Perl's TMTOWTDI, otherwise the language is getting sloppy and Perl already covers that territory (it would be nice to learn not only from C++'s mistakes).
>
> In fact, I might like an explicit keyword better than C#'s way anyway: a property has the keyword "property" (somewhere), and may only be used with property syntax, using the "say what you mean and mean what you say" principle. No one is misled by it. Also makes it easy to search for with your text editor, just like "cast".
>
> -- 
> dave

> I know some people have grokked "the D way", as in the .dup "method" in built-in arrays, but I think it's a mistake not to differentiate between attributes (methods / fields) and modifying methods.
>
> Thoughts everyone?

Usually it is clear from the name if a "property" is modifying or doing something fishy. I have grown to like the brevity of .dup and other short-but-sweet calls. It gets rid of those ugly () that would have to get tacked on. And since I'm super-lazy I'd like to suggest using .next instead of .advance in the DTL api.

-Ben

Ben Hinkle wrote:

>>I know some people have grokked "the D way", as in the .dup "method" in
>>built-in arrays, but I think it's a mistake not to differentiate between
>>attributes (methods / fields) and modifying methods.
>>
>>Thoughts everyone?
> 
> 
> Usually it is clear from the name if a "property" is modifying or doing
> something fishy. I have grown to like the brevity of .dup and other
> short-but-sweet calls. It gets rid of those ugly () that would have to get
> tacked on. And since I'm super-lazy I'd like to suggest using .next instead
> of .advance in the DTL api.

I don't agree. The () carries information that is lost if you "abuse" properties for methods.

For example, if I read something like x=b.next I expect "next" to be a field of b (whether it is a variable or derived information returned by a function doesn't matter). I do not expect that b is modified when one of its fields is read! So if I write b.next twice without explictly modifying b in between I expect to get the same result each time.

In contrast, b.next() makes it clear that something may happen during the call that modifies b, like advancing the iterator or something.

Don't get me wrong, I like properties in general. But I think that if the syntax stays the way it is there should be a firm convention that "read-access" to properties does not modify the object. For consistency that should also include iterators and the like.

Hauke

Hauke Duden wrote:

> Ben Hinkle wrote:
>
>>> I know some people have grokked "the D way", as in the .dup "method" in
>>> built-in arrays, but I think it's a mistake not to differentiate between
>>> attributes (methods / fields) and modifying methods.
>>>
>>> Thoughts everyone?
>>
>>
>>
>> Usually it is clear from the name if a "property" is modifying or doing
>> something fishy. I have grown to like the brevity of .dup and other
>> short-but-sweet calls. It gets rid of those ugly () that would have to get
>> tacked on. And since I'm super-lazy I'd like to suggest using .next instead
>> of .advance in the DTL api.
>
>
> I don't agree. The () carries information that is lost if you "abuse" properties for methods.
>
> For example, if I read something like x=b.next I expect "next" to be a field of b (whether it is a variable or derived information returned by a function doesn't matter). I do not expect that b is modified when one of its fields is read! So if I write b.next twice without explictly modifying b in between I expect to get the same result each time.
>
> In contrast, b.next() makes it clear that something may happen during the call that modifies b, like advancing the iterator or something.
>
> Don't get me wrong, I like properties in general. But I think that if the syntax stays the way it is there should be a firm convention that "read-access" to properties does not modify the object. For consistency that should also include iterators and the like.
>
> Hauke

I don't like this idea for read-access.  There are cases where you want to use latent computation, so you don't have to recompute something again (ie cache).  And don't say use a method because often you start of with a public variable and late in the design process make it into a property method.

-- 
-Anderson: http://badmama.com.au/~anderson/

> For example, if I read something like x=b.next I expect "next" to be a field of b (whether it is a variable or derived information returned by a function doesn't matter).

In Matthew's code .advance didn't return anything so writing x=b.advance or x=b.next or whatever would be a compile-time error. If I read "b.next;" used as a statement then I suspect it has side effects because otherwise it would be a no-op. I agree a property name that returns something *and* is ambiguous that it has side effects is nasty. I haven't looked for examples of D code that could be like this but it would be interesting to search around and see how properties are being used and if they are being used for side effects or not.

J Anderson wrote:

> Hauke Duden wrote:
> 
>> Ben Hinkle wrote:
>>
>>>> I know some people have grokked "the D way", as in the .dup "method" in
>>>> built-in arrays, but I think it's a mistake not to differentiate between
>>>> attributes (methods / fields) and modifying methods.
>>>>
>>>> Thoughts everyone?
>>>
>>>
>>>
>>>
>>> Usually it is clear from the name if a "property" is modifying or doing
>>> something fishy. I have grown to like the brevity of .dup and other
>>> short-but-sweet calls. It gets rid of those ugly () that would have to get
>>> tacked on. And since I'm super-lazy I'd like to suggest using .next instead
>>> of .advance in the DTL api.
>>
>>
>>
>> I don't agree. The () carries information that is lost if you "abuse" properties for methods.
>>
>> For example, if I read something like x=b.next I expect "next" to be a field of b (whether it is a variable or derived information returned by a function doesn't matter). I do not expect that b is modified when one of its fields is read! So if I write b.next twice without explictly modifying b in between I expect to get the same result each time.
>>
>> In contrast, b.next() makes it clear that something may happen during the call that modifies b, like advancing the iterator or something.
>>
>> Don't get me wrong, I like properties in general. But I think that if the syntax stays the way it is there should be a firm convention that "read-access" to properties does not modify the object. For consistency that should also include iterators and the like.
>>
>> Hauke
> 
> 
> I don't like this idea for read-access.  There are cases where you want to use latent computation, so you don't have to recompute something again (ie cache).  And don't say use a method because often you start of with a public variable and late in the design process make it into a property method.

I agree. I don't mean that gettor methods should be the same as const methods in C++. The important thing is that the visible(!) state of the object is not changed by reading a field. If you want to cache a result in your property method that's fine, since it doesn't change the way the object behaves to the outside.

What I really want, is not having to look at the source code of each and every class that is used in an expression in order to find out what it does. Is "next" just a plain variable or a property or a method that changes something?

The whole point of properties is that you can treat methods like variables and that the way the property is implemented remains opaque to the user. If you have side-effects during read access that's not opaque at all.

Hauke

Hauke Duden <H.NS.Duden@gmx.net> wrote:

> I don't agree. The () carries information that is lost if you "abuse" properties for methods.

I have to agree here -- if something can be abused, it will be. C taught us that :-)

> For example, if I read something like x=b.next I expect "next" to be a field of b (whether it is a variable or derived information returned by a function doesn't matter). I do not expect that b is modified when one of its fields is read! So if I write b.next twice without explictly modifying b in between I expect to get the same result each time.

That's a good example. A property is really (IMO) a member variable that you want to have access control over. You should be able to change them from methods to member variables (and vice versa) in your class declaration, and the client code should still work. If you can't, it should not be a "property" -- in fact, it isn't one.  In the D spec, it says:

Class and Struct Properties: Properties are member functions that can by syntactically treated as if they were fields.

By this definition, .dup, .sort, and .advance are not properties, and should be invokable only with method call syntax. Doesn't matter whether they modify the object or not, they aren't interchangable with member variables. Also doesn't matter if their value can change between fetches: a Timer class could have a property, .ticks, which of course will change (hopefully :-) every few times you get its value. But it could be implemented as a member variable if the class was built to allow this, and you could also write ".ticks = 0" to reset it. Something like this would be a good use of properties, in case you need to perform some action when resetting the timer, etc.

That's all that those "getter/setter" methods you see in Java code do: control access to some member variable. Unfortunately, Java is not smart enough to encapsulate them in a clean syntax, and this is something C# improved on. The more I think about this, the more I think this is an error in D, although not a serious one. I basically don't like the idea that methods can be invoked with two different syntax options, and that in looking at some code, I don't know if I'm looking at a method call, or a member variable (and no, "guessing" about the name doesn't count).

-- 
dave