January 20, 2012
On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> I think MSDN has some decent advice on when to use properties vs
> methods:
> http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpconpropert
> yusageguidelinesanchor1

Those do seem like pretty good guidelines.

- Jonathan M Davis
January 20, 2012
On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@spam.invalid> wrote:
>>> If the type of byKeys is Range, I would expect to be able to treat it
>>> like one. Not like one, then another, then another, then another... ad
>>> infinitum.
>>
>> I don't know what you mean. You can treat it like one.
>>
>> -Steve
>
> It's the rvalue aspect. byKey does not hold a range inside the hashtable (as a member variable would do). Each use of byKey gives you a range that you get to iterate from the beginning.

The point of a property is to allow for read-only access on something that is logically a property but can only be implemented via a function.  byKeys is such a property.  There is no way to specify a field that behaves the same.  This doesn't make properties invalid or useless.

But Torhu, your use of terminology doesn't make sense.  The type of byKeys is a Range, and you can use it as a Range.  A range on a container is a shallow view, it fundamentally does not affect the container topology.

-Steve
January 20, 2012
Am 19.01.2012, 21:53 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Thursday, January 19, 2012 20:56:39 Marco Leise wrote:
>> I just came across some C++ code and came to the conclusion, that
>> properties and indexed access should not modify the structure. In other
>> words all my @property and opIndex will probably also by const. An
>> exception to that being caching and access counting.
>
> I don't know why you came to that concluson. I don't agree at all. Obviously,
> you're free to do what you want with your code, but that seems overly
> restrictive to little or no benefit. Properties can be both getters and setters
> for a reason. It would be horrible if all you had were getters.
>
> - Jonathan M Davis

Ah, I meant to say that getters should not modify their object. When I see "a = abc.x[i]" I would be a little surprised to find that it changes the observable state of abc. The same goes for "a = b.length()". Now it is clearer, isn't is? :p
January 20, 2012
On Friday, January 20, 2012 09:58:42 Marco Leise wrote:
> Ah, I meant to say that getters should not modify their object. When I see "a = abc.x[i]" I would be a little surprised to find that it changes the observable state of abc. The same goes for "a = b.length()". Now it is clearer, isn't is? :p

Yes. Generally, setters should be used to set rather than getters doing it one way or another, though I have no idea how either of your examples there would result in the getter changing anything. However, if a getter property returns a ref, then it's both a getter and a setter. But whether exposing the underlying variable like that makes sense depends on the property - generally not, I think.

The one major place where you essentially have a getter being able to modifer the original through its return value in C++ that I'm aware of is the subscript operator, and it has to in order to function like the built-in substript operator, so that's a special case.

- Jonathan M Davis
January 20, 2012
On 20/01/12 12:57 AM, Steven Schveighoffer wrote:
> On Thu, 19 Jan 2012 18:41:44 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@spam.invalid> wrote:
>>>> If the type of byKeys is Range, I would expect to be able to treat it
>>>> like one. Not like one, then another, then another, then another... ad
>>>> infinitum.
>>>
>>> I don't know what you mean. You can treat it like one.
>>>
>>> -Steve
>>
>> It's the rvalue aspect. byKey does not hold a range inside the
>> hashtable (as a member variable would do). Each use of byKey gives you
>> a range that you get to iterate from the beginning.
>
> The point of a property is to allow for read-only access on something
> that is logically a property but can only be implemented via a function.
> byKeys is such a property. There is no way to specify a field that
> behaves the same. This doesn't make properties invalid or useless.

Can you define what "is logically a property means"? (I assume you meant "field" there)

That means different things to different people. For example, in my mind, something that is logically a field would have an address. From what I can see, byKeys is logically a function (not a field) in every way (because it *is* a function).
January 20, 2012
On Friday, January 20, 2012 09:29:12 Peter Alexander wrote:
> Can you define what "is logically a property means"? (I assume you meant
> "field" there)
> 
> That means different things to different people. For example, in my mind, something that is logically a field would have an address. From what I can see, byKeys is logically a function (not a field) in every way (because it *is* a function).

Usually when discussing properties, taking the address doesn't come into the equation at all. Part of the reason for this is that many of the languages which have properties don't allow you to take the address of anything in the first place. Also, it completely invalidates property anyway, since by definition, using a property function instead of a member variable makes it so that you can't take its address (or that if you do, it means something completely different). So, taking the address of something really can't come into consideration when talking about properties unless the design requires that you be able to take its address, in which case it must be an actual member variable instead of a property function.

So, when talking about something logically acting like a property or a field, it really can't have anything to do with addressing but rather the other aspects about how a field is used.

- Jonathan M Davis
January 20, 2012
Jose Armando Garcia wrote:

> On Thu, Jan 19, 2012 at 9:41 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> On 1/19/12 4:43 PM, Steven Schveighoffer wrote:
>>>
>>> On Thu, 19 Jan 2012 14:06:00 -0500, torhu <no@spam.invalid> wrote:
>>>>
>>>> If the type of byKeys is Range, I would expect to be able to treat it like one. Not like one, then another, then another, then another... ad infinitum.
>>>
>>>
>>> I don't know what you mean. You can treat it like one.
>>>
>>> -Steve
>>
>>
>> It's the rvalue aspect. byKey does not hold a range inside the hashtable (as a member variable would do). Each use of byKey gives you a range that you get to iterate from the beginning.
>>
>> Andrie
> 
> I think MSDN has some decent advice on when to use properties vs
> methods:
> http://msdn.microsoft.com/en-
us/library/bzwdh01d(v=vs.71).aspx#cpconpropertyusageguidelinesanchor1

Hi Jose,
great that you're still around in the newsgroups. Any news on std.log? Is it
ready for review?
January 20, 2012
Jonathan M Davis wrote:
> On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> > I think MSDN has some decent advice on when to use properties vs
> > methods:
> > http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpconpropert
> > yusageguidelinesanchor1
> 
> Those do seem like pretty good guidelines.

Then why not add these in a condensed form to
http://www.dlang.org/dstyle.html?
Convention may be a way to end these discussions.

Jens
January 20, 2012
On Friday, January 20, 2012 11:01:10 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> > > I think MSDN has some decent advice on when to use properties vs methods: http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpcon propert yusageguidelinesanchor1
> > 
> > Those do seem like pretty good guidelines.
> 
> Then why not add these in a condensed form to
> http://www.dlang.org/dstyle.html?
> Convention may be a way to end these discussions.

Oh, it may be a good idea to add them (or something like them) to the style guide or elsewhere on the site, but it won't really end any discussions. Just like function names are subjective, whether something is a property or not is subjective. You can objectively narrow it down pretty thoroughly based on good naming rules (or good rules on what's a property), but in many cases, it still comes down to a subjective decision. So, there will always be debate. You can't get around that. At best, you can reduce it.

- Jonathan M Davis
January 20, 2012
Jonathan M Davis wrote:
> On Friday, January 20, 2012 11:01:10 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Thursday, January 19, 2012 22:30:46 Jose Armando Garcia wrote:
> > > > I think MSDN has some decent advice on when to use properties vs methods: http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpcon propert yusageguidelinesanchor1
> > > 
> > > Those do seem like pretty good guidelines.
> > 
> > Then why not add these in a condensed form to
> > http://www.dlang.org/dstyle.html?
> > Convention may be a way to end these discussions.
> 
> Oh, it may be a good idea to add them (or something like them) to the style guide or elsewhere on the site, but it won't really end any discussions. Just like function names are subjective, whether something is a property or not is subjective. You can objectively narrow it down pretty thoroughly based on good naming rules (or good rules on what's a property), but in many cases, it still comes down to a subjective decision. So, there will always be debate. You can't get around that. At best, you can reduce it.

I was only hoping for a reduction. If a convention works most of the time it's fine, I think.

Jens