www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Another problem with properties

reply Aarti_pl <aarti interia.pl> writes:
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;
}


//--------------------
//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;
}

//--------------------
//Example C
//You can not extend property in derived function

interface I {
         int  prop;
}

class Test : I {
	int prop();
	void prop(int);
}
//--------------------

Above examples *should* work. Current behavior reduces properties 
usefulness.

BR
Marcin Kuszczak
(Aarti_pl)
Aug 24 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Aug 24 2007
next sibling parent reply Tristam MacDonald <swiftcoder gmail.com> writes:
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

Aug 24 2007
next sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
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;
 }

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;
 }

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);
 }

an interface anyway.
 //--------------------

 Above examples *should* work. Current behavior reduces properties
 usefulness.

 BR
 Marcin Kuszczak
 (Aarti_pl)

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.
Aug 24 2007
parent Marcin Kuszczak <aarti interia.pl> writes:
Charles D Hixson wrote:

 I think the conflict is between declaration/definition and
 use. =C2=A0A property is used AS IF it were a field. =C2=A0(Possibly =

 that can only be either read from or written to.) =C2=A0But the
 property when being defined *IS* a function. =C2=A0It 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.

Same access syntax is biggest advantage of properties in D. In my first= post I just demonstrated that not in every case it is really same syntax. It is possible that problem can be solved using rewriting of field as t= wo functions (see my last post). The problem for compiler would be to find= cases where there exist at least one function definition, and then rewr= ite all fields into functions. When there are only fields in derived classe= s it can be left as field... --=20 Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/d= oost/ -------------------------------------
Aug 24 2007
prev sibling parent Marcin Kuszczak <aarti interia.pl> writes:
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?

Yes. I was thinking more less about what you said. But I didn't describe implementation, just use-cases. From implementation point of view maybe it would be possible to translate automatically (by compiler) following definition: interface I { int x; } into: interface I { int x(); void x(); } where necessary. In derived classes this translation could also happen if there is declaration of the symbol x: class A { int x; | // translation happens as x is same symbol as in interface. \|/ int x() { return _x; } void x(int x) { _x=x; } } It seems to solve my initial problem. But above is just from top of my head - probably someone can propose better solution... -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Aug 24 2007
prev sibling parent Marcin Kuszczak <aarti interia.pl> writes:
Daniel Keep wrote:

 As I said, I'm not sure what your argument is. =C2=A0You seem like yo=

 to add fields to an interface which is utterly impossible due to the =

 interfaces work. =C2=A0Virtual functions are stored in offsets in the=

 whilst fields are stored as an offset from the start of the class' ch=

 of allocated memory. =C2=A0I don't know of any language that has prop=

 and interfaces that lets you put regular fields into an interface.
=20
 That said, I've put properties in interfaces lots of times, and I've
 never really seen a problem with it.
=20
 -- Daniel

My main intent was to point out that current D properties implementatio= n is not serving its purpose of hiding differences between fields and method= s very well. There are cases in which current properties just doesn't wor= k. Please notice that when you don't need setters and getters in specific derived class defining two silly methods is rather inconvenient. I was = not trying to find solution, but just define another problem with them. In Java you can put fields in interface, but it doesn't make it necessa= ry to implement field in derived classes/interfaces. Probably because Java interfaces are implemented as abstract classes in D. IMHO such a behavi= our is not proper as interfaces should constrain implementation. --=20 Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/d= oost/ -------------------------------------
Aug 24 2007
prev sibling parent reply BCS <ao pathlink.com> writes:
Reply to Aarti_pl,

 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;
 }
 //--------------------
 //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;
 }
 //--------------------
 //Example C
 //You can not extend property in derived function
 interface I {
 int  prop;
 }
 class Test : I {
 int prop();
 void prop(int);
 }
 //--------------------
 
 Above examples *should* work. Current behavior reduces properties
 usefulness.
 
 BR
 Marcin Kuszczak
 (Aarti_pl)

Short version, proprtties are just function. Interfaces are just functions. That said, It wouldn't be impossible to have interfaces define members (the vtable entry for them would be a pointer offset to get from the interface instance to the member) but then there would be no way to enforce encapsulation.
Aug 24 2007
parent reply Marcin Kuszczak <aarti interia.pl> writes:
BCS wrote:

 Short version, proprtties are just function. Interfaces are just
 functions.
 
 That said, It wouldn't be impossible to have interfaces define members
 (the vtable entry for them would be a pointer offset to get from the
 interface instance to the member) but then there would be no way to
 enforce encapsulation.

What do you mean by "enforce encapsulation"? What would your proposition solve and what not? -- Regards Marcin Kuszczak (Aarti_pl) ------------------------------------- Ask me why I believe in Jesus - http://zapytaj.dlajezusa.pl (en/pl) Doost (port of few Boost libraries) - http://www.dsource.org/projects/doost/ -------------------------------------
Aug 24 2007
parent BCS <ao pathlink.com> writes:
Reply to Marcin,

 BCS wrote:
 
 Short version, proprtties are just function. Interfaces are just
 functions.
 
 That said, It wouldn't be impossible to have interfaces define
 members (the vtable entry for them would be a pointer offset to get
 from the interface instance to the member) but then there would be no
 way to enforce encapsulation.
 

proposition solve and what not?

The idea (I'm not proposing it because I don't really like the idea) would let an interface have a member that is just data, not a function, however there would be no way to prevent code using it from doing arbitrary manipulation. It would be a public field. Also each member of the interface would still need to be done using a function or a field, but the interface definition would pick one not the interface implementation. interface I { int i; } class C1 : I { int i; } // works class C2 : I { int i(){} } // doesn't work even though C2.i does
Aug 25 2007