www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - property and interfaces

reply BLS <windevguy hotmail.de> writes:


  public interface IBindingList   {

     bool AllowEdit {
       get;
     }
}

//D2
interface IBindingList {
	
	 property bool allowEdit();
}


implement a setter. Seems to be impossible in D.

Thanks Bjoern
Jun 29 2010
next sibling parent BLS <windevguy hotmail.de> writes:
sorry for making so much noise.. figured it out by myse4lf.
interface IBindingList {
		
	 property bool AllowEdit();
	// property bool AllowEdit(bool enable);
	//remove // to enable setter
}

class A : IBindingList {
	private bool _allowEdit;

	 property {
		bool AllowEdit() { return _allowEdit;	}
		//bool AllowEdit(bool enable) { return _allowEdit = enable; }
	}	
}
bjoern

On 29/06/2010 12:11, BLS wrote:



 public interface IBindingList {

 bool AllowEdit {
 get;
 }
 }

 //D2
 interface IBindingList {

  property bool allowEdit();
 }


 implement a setter. Seems to be impossible in D.

 Thanks Bjoern
Jun 29 2010
prev sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Tuesday 29 June 2010 03:11:34 BLS wrote:



   public interface IBindingList   {
 
      bool AllowEdit {
        get;
      }
 }
 
 //D2
 interface IBindingList {
 
 	 property bool allowEdit();
 }
 

 implement a setter. Seems to be impossible in D.
 
 Thanks Bjoern


Well, with the way that properties are implemented in D, I don't think that the 
getters and setters have any real relation with one another. If a getter is 
declared, you can use the property as an rvalue. If a setter is declared, you 
can use it as an lvalue. AFAIK, they don't really have any effect on each other 
and aren't really related. So, there certainly won't be any restriction on 
having a getter or setter in a class if an interface it implements declared
only 
one. It's just that you'll only be able to use the one that's part of the 
interface if you're using a reference of the interface type rather than the 
implementing class.

And really, I see no point in it being more restrictive. The interface itself 
should be properly restrictive if you use it since it only declares one of the 
two. And if you're using the class directly, then what does what the interface 
does and doesn't have matter? You're using the class at that point, not the 
interface.

- Jonathan M Davis
Jun 29 2010
parent reply BLS <windevguy hotmail.de> writes:
On 29/06/2010 12:32, Jonathan M Davis wrote:

 So, there certainly won't be any restriction on
 having a getter or setter in a class if an interface it implements declared
only
 one. It's just that you'll only be able to use the one that's part of the
 interface if you're using a reference of the interface type rather than the
 implementing class.


Hi Jonathan,
interesting : this snippet compiles.

interface IBindingList {
		
	 property bool AllowEdit();


class A : IBindingList {
	private bool _allowEdit;

	 property {
		bool AllowEdit() { return _allowEdit;	}
		bool AllowEdit(bool enable) { return _allowEdit = enable; }
	}	
}

But this one NOT.

interface IBindingList {
		
	 property bool AllowEdit();
	 property bool AllowEdit(bool enable);
}
class A : IBindingList {
	private bool _allowEdit;

	 property {
		bool AllowEdit() { return _allowEdit;	}
	}	
}
IMO this is bad design.
bjoern
Jun 29 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 29 Jun 2010 06:58:54 -0400, BLS <windevguy hotmail.de> wrote:


 On 29/06/2010 12:32, Jonathan M Davis wrote:

 So, there certainly won't be any restriction on
 having a getter or setter in a class if an interface it implements  
 declared only
 one. It's just that you'll only be able to use the one that's part of  
 the
 interface if you're using a reference of the interface type rather than  
 the
 implementing class.


 Hi Jonathan,
 interesting : this snippet compiles.

 interface IBindingList {
 		
 	 property bool AllowEdit();


 class A : IBindingList {
 	private bool _allowEdit;

 	 property {
 		bool AllowEdit() { return _allowEdit;	}
 		bool AllowEdit(bool enable) { return _allowEdit = enable; }
 	}	
 }

 But this one NOT.

 interface IBindingList {
 		
 	 property bool AllowEdit();
 	 property bool AllowEdit(bool enable);
 }
 class A : IBindingList {
 	private bool _allowEdit;

 	 property {
 		bool AllowEdit() { return _allowEdit;	}
 	}	
 }
 IMO this is bad design.


Classes are always able to add functionality beyond what the interface  

setters even if the interface declares only a getter.

If you access an A instance through the IBindingList, you only have access  
to a getter, so it is properly implementing the interface.  I don't see  
why adding a setter detracts from it.



interface I1
{
    int x { get; }
}

interface I2
{
    int x {get; set;}
}


you implement interfaces
{
   ???
}



 property int value() {return _x;}
 property int value(int x) { return _x = x;}
 property int value(string s) { return _x = to!int(s);}

:)  D's properties are so much better...

-Steve
Jun 29 2010
parent BLS <windevguy hotmail.de> writes:
On 29/06/2010 14:08, Steven Schveighoffer wrote:



  property int value() {return _x;}
  property int value(int x) { return _x = x;}
  property int value(string s) { return _x = to!int(s);}

 :)  D's properties are so much better...

 -Steve


Ok, convinced ;)
Jun 29 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BLS:

 But this one NOT.
 
 interface IBindingList {
 		
 	 property bool AllowEdit();
 	 property bool AllowEdit(bool enable);
 }
 class A : IBindingList {
 	private bool _allowEdit;
 
 	 property {
 		bool AllowEdit() { return _allowEdit;	}
 	}	
 }
 IMO this is bad design.
 bjoern



Is this good for you?

interface IBindingList {
     property bool AllowEdit();
     property bool AllowEdit(bool);
}

class A : IBindingList {
    bool _allowEdit;
     property bool AllowEdit() { return _allowEdit; }
     disable  property bool AllowEdit(bool) { return true; }
}

void main() {}

Bye,
bearophile
Jun 29 2010
parent reply BLS <windevguy hotmail.de> writes:
Hi bearophile,
sorry for my ignorance, but what is the difference between  disable and 
simply deleting the line ?
where can I read more about  disable ?
thanks, bjoern
Jun 29 2010
parent reply "Rory McGuire" <rmcguire neonova.co.za> writes:
On Tue, 29 Jun 2010 14:42:33 +0200, BLS <windevguy hotmail.de> wrote:


 Hi bearophile,
 sorry for my ignorance, but what is the difference between  disable and  
 simply deleting the line ?
 where can I read more about  disable ?
 thanks, bjoern


 disable propagates throughout the objects hierarchy (all children).

you can use it to disable builtins as well such as opEquals
Jun 29 2010
parent BLS <windevguy hotmail.de> writes:
On 29/06/2010 17:03, Rory McGuire wrote:

  disable propagates throughout the objects hierarchy (all children).

 you can use it to disable builtins as well such as opEquals


  Cool, thanks Rory!
Jun 29 2010