Another problem with properties

Tristam MacDonald swiftcoder at gmail.com
Fri Aug 24 09:00:10 PDT 2007


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




More information about the Digitalmars-d mailing list