On DIP 23

[Robert]

Oops. I kinda missed the complete discussion about this. I am sure
someone else already wrote something similar, so just ignore the post.

Best regards,

Robert

On Wed, 2013-02-06 at 23:10 +0100, Robert wrote:
> Well first what I like about it: The approach function symbols are
> handled, it is a pretty clear concept:
> 
> void f() {
> }
> 
> f;
> 
> f is a function, you can take the address of it and call it and that's
> it. So if you just write it down, it makes sense that it gets called.
> Not so for delegates, function objects, ... Sounds sane to me, I like
> it.
> 
> About properties:
> 
> In short, I died a little reading it.
> 
> I know we have UFCS, but @properties are meant to emulate a field, so
> the semantics should be as close to a field as possible. Ideally,
> identical.
> 
> Especially the part about module level properties made me crazy:
> @property double fun(int x, double y) { assert(x == 42 && y == 43);
> return y; }
>     42.fun = 43;
> 
> reads to me: The integer 42 has a property called fun, which gets
> assigned 43???
> 
> If we special case properties, we might as well disallow UFCS for them,
> which makes sense, because you can not define a field external to an
> object either.
> 
> So the proposal for module level properties, would be right exactly the
> other way round (emulating global variables):
> private int myCoolSetting_;
> @property int myCoolSetting() {
> 	return myCoolSetting_;
> }
> @property void myCoolSetting(int setting) {
> 	enforce(setting>0 && setting<10, "Invalid setting!");
> 	myCoolSetting_=setting;
> }
> 
> myCoolSetting=8; // Ok.
> 
> That is what properties are all about. 
> 
> The part, about taking the address of a property, is fine as long as we
> allow fields to be declared with @property as I already suggested, with
> the following semantics:
> 
> @property int a;
> 
> would be lowered to:
> 
> private int __a;
> 
> @property void a(int a_) {
> 	__a=a_;
> }
> 
> @property int a() {
> 	return __a;
> }
> 
> in order to ensure that @property declared fields and properties
> declared as functions do really have the same semantics.
> 
> If you don't think about properties as fields, than I understand Walters
> suggestion about removing @property completely and we could as well do
> it.
> 
> UFCS with properties, makes little to no sense. Because well the name
> already suggests: "Uniform Function Calling Syntax", properties are not
> about calling functions. Allowing UFCS would offer the possibility of
> adding some kind of dynamic properties/fields to an object, but the code
> samples with integers and especially the problem with module level
> properties suggests that this causes more problems than it is worth.
> 
> properties -> no UFCS and we have a sane world!
> 
> Best regards,
> 
> Robert
> 
> P.S.: Things like  
> int a = 4.2.truncated;
> 
> do make sense, but UFCS and optional parentheses would do the trick too,
> so no need to abuse properties there.
> 
> 
>