Another problem with properties

[Charles D Hixson]

Tristam MacDonald wrote:
> I hink what he was getting at is that properties are either functions or data members, when in reallity they should be neither. If they are to be useful, they need to be flexible enough that they can be either functions or a straight data member interchangeably, and that a property implemented as data should be overridable with function-type properties.
> 
> How this would be implemented I have no idea, but I believe other languages have propper properties?
> 
> Daniel Keep Wrote:
>> Aarti_pl wrote:
>>> Below examples doesn't compile, but IMHO they should. Especially when
>>> properties are threated as functions like in D...
>>>
>>> //--------------------
>>> //Example A
>>> //You can not make sure that every class will have some property
>>> interface I {
>>>         int prop;
>>> }
>>>
>>> class Test : I {
>>>     int prop;
>>> }
>> That's because that's a field, not a function.  An interface can *only*
>> define the contents of the vtable, which is where virtual functions are
>> stored.
>>
>>> //--------------------
>>> //Example B
>>> //When you define property as functions you have to use them in every
>>> //derived class
>>> interface I {
>>>         int  prop();
>>>     void prop(int);
>>> }
>>>
>>> class Test : I {
>>>     int prop;
>>> }
>> That's sort of the whole point of an interface...
>>
>> Before, you complained that you can't make sure every derived class will
>> have a certain property.  Now you're complaining that every derived
>> class must have a certain property.
>>
>>> //--------------------
>>> //Example C
>>> //You can not extend property in derived function
>>>
>>> interface I {
>>>         int  prop;
>>> }
>>>
>>> class Test : I {
>>>     int prop();
>>>     void prop(int);
>>> }
>> I'm not sure what you're getting at here; again, you can't use fields in
>> an interface anyway.
>>
>>> //--------------------
>>>
>>> Above examples *should* work. Current behavior reduces properties
>>> usefulness.
>>>
>>> BR
>>> Marcin Kuszczak
>>> (Aarti_pl)
>> As I said, I'm not sure what your argument is.  You seem like you want
>> to add fields to an interface which is utterly impossible due to the way
>> interfaces work.  Virtual functions are stored in offsets in the vtable,
>> whilst fields are stored as an offset from the start of the class' chunk
>> of allocated memory.  I don't know of any language that has properties
>> and interfaces that lets you put regular fields into an interface.
>>
>> That said, I've put properties in interfaces lots of times, and I've
>> never really seen a problem with it.
>>
>> 	-- Daniel
> 

That may have been his intent...but properties need to be 
implemented as functions...if they aren't, then they're fields.

FWIW, I may have said that a bit too dogmatically.  Properties 
that appear in interfaces must be functions.  That has to do 
with why an interface isn't a class, and why inheritance using 
interfaces isn't multiple inheritance.
Also, if an item were in a class, rather than an interface, 
and weren't implemented as a function...why would you think of 
it as a property rather than as a field?

I think the conflict is between declaration/definition and 
use.  A property is used AS IF it were a field.  (Possibly one 
that can only be either read from or written to.)  But the 
property when being defined *IS* a function.  It becomes a 
property by being defined in a particular form, which allows 
the compiler to recognize as uses of it code that appear to be 
  uses of a field.