Dave Sieber wrote:

>By this definition, .dup, .sort, and .advance are not properties, and should be invokable only with method call syntax.
>  
>
> That's a good example. A property is really (IMO) a member variable that

Oh no, I'm feel another re-fix of dig <g>.  If it must change it must change :(

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

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:c665uf$18ij$1@digitaldaemon.com...
> > 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've reasons for not using .next, since that's part of several Object-based
runtime polymorphic enumeration interfaces that we'll be supporting. Also, Ranges
(as defined in "Imperfect C++" - to the newbies, that's my new Addison-Wesley
book coming out in Sept) defines the method-based form to use advance()/Advance()
when the operator-based form is not used (which it cannot be in D, because we do
not, and will not, have opDeref / operator *()).

Absolutely agreed. I think we could all learn from Ruby in this, which uses !, ? and "nothing at all" suffixes to denote modifying, querying and "other" method types, since it does not require () for 0-parameter method calls

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c669v2$1fd8$1@digitaldaemon.com...
> 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
>
>
>
>
>
>

"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

Sorry for joining late, but there're just too many messages!
A couple of things:
1. TMTOWTDI???
2. In to the subject, I rather prefer the Delphi way, where you do something
like this:

property MyProp : SomeType; read foo; write bar;

Where foo must be a function returning a SomeType, or a variable of type
SomeType, and bar is a variable of type SomeType, or a procedure taking a
SomeType as parameter. They're both optional, so you automatically know if
they're read-only, write-only or read-write. They can have a default
modifier, and IIRC an index modifier or something like that. And, of course,
if you want you can use foo or bar as if MyProp didn't exist.
Ilya suggested this a long time ago, but Walter just didn't like it.
And BTW, I'm writing this as I remember things, so things might not be 100%
accurate. But that's the general idea.

-----------------------
Carlos Santander Bernal

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
news:c669v2$1fd8$1@digitaldaemon.com
| 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

That's your POV. I don't think that omitting () or not, tells you something
additional. From your same example, the name "next" tells me that if b is
some kind of collection or something, it might advance, and that's what I'd
be expecting. I wouldn't care about the ().
Now, I do agree that there should be a way to tell properties and methods
apart. And I do agree that some properties in D built-in types should be
methods rather than properties.
But that's just me.

-----------------------
Carlos Santander Bernal

"Carlos Santander B." <carlos8294@msn.com> wrote:

> Sorry for joining late, but there're just too many messages!
> A couple of things:
> 1. TMTOWTDI???

Perl's guiding principle on how to write unmaintainable software:

"There's More Than One Way To Do It"

> 2. In to the subject, I rather prefer the Delphi way, where you do something like this:
> 
> property MyProp : SomeType; read foo; write bar;

This is similar to what Microsoft provides in their C++ compiler for COM property support. In COM interfaces there are no member variables, so "properties" are implemented via methods. In their C++ compiler, they have a special syntax you can use, similar to the above, to create fake properties. But it doesn't enforce anything, you can still call the methods directly.

> And, of course, if you want you can use foo or
> bar as if MyProp didn't exist.

This is what I don't like (the TMTOWTDI problem again): there should be only ONE access point to fetch a property value, not two. It becomes a maintainence problem: client code can always bypass your Property definition and call methods directly, so you can't change the implementation without potentially breaking client code. Bad design. In C# they corrected this.

-- 
dave