Thread overview
@property and interfaces
Jun 29, 2010
BLS
Jun 29, 2010
BLS
Jun 29, 2010
Jonathan M Davis
Jun 29, 2010
BLS
Jun 29, 2010
BLS
Jun 29, 2010
bearophile
Jun 29, 2010
BLS
Jun 29, 2010
Rory McGuire
Jun 29, 2010
BLS
June 29, 2010
Just wonder how to translate this C# snippet into D..
//C#
 public interface IBindingList   {

    bool AllowEdit {
      get;
    }
}

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

Is this correct ? I think in C# AllowEdit() takes tare that you don't implement a setter. Seems to be impossible in D.

Thanks Bjoern
June 29, 2010
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:
> Just wonder how to translate this C# snippet into D..
> //C#
> public interface IBindingList {
>
> bool AllowEdit {
> get;
> }
> }
>
> //D2
> interface IBindingList {
>
> @property bool allowEdit();
> }
>
> Is this correct ? I think in C# AllowEdit() takes tare that you don't
> implement a setter. Seems to be impossible in D.
>
> Thanks Bjoern

June 29, 2010
On Tuesday 29 June 2010 03:11:34 BLS wrote:
> Just wonder how to translate this C# snippet into D..
> //C#
>   public interface IBindingList   {
> 
>      bool AllowEdit {
>        get;
>      }
> }
> 
> //D2
> interface IBindingList {
> 
> 	@property bool allowEdit();
> }
> 
> Is this correct ? I think in C# AllowEdit() takes tare that you don't 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
June 29, 2010
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
June 29, 2010
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 declares.  IMO, it's actually bad design of C# not to allow you to declare 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.

What if you had this in C#?

interface I1
{
   int x { get; }
}

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

class C : I1, I2 // my C# is a bit rusty, I can't remember if this is how you implement interfaces
{
  ???
}

Besides, try to do this in C#:

@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
June 29, 2010
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
June 29, 2010
On 29/06/2010 14:08, Steven Schveighoffer wrote:
> Besides, try to do this in C#:
>
> @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 ;)
June 29, 2010
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
June 29, 2010
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
June 29, 2010
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!