On 01/26/13 20:10, Maxim Fomin wrote:
> On Saturday, 26 January 2013 at 13:21:37 UTC, Jacob Carlborg wrote:
>> It's always possible to avoid keywords in favor of syntax. Example:
>>
>> Declaring a getter:
>>
>> int foo {}
>>
>> Just as a regular function declaration but without the parentheses.
>>
>> Declaring a setter:
>>
>> void foo= (int value) {}
>>
>> Append an equal sign to the function name.
> 
> This looks nice, but I favor for C# properties.
> 
> The root of the issue is that in C/C++/D there is tremendous difference between object types and functions types (which are incompatible) and property is like a bridge between them - I think that is why the feature is demanded.
> 
> However in D a property is essentially a function. Few characteristics that are intrinsic to data types are typeof(prop) which is data type for properties and parenthesis-less access. There is no property as a special entity per se.
> 
> In C# property and getter/setter are separated, so there is no confusion between data and functions. In D it would look like this:
> 
> class A
> {
>     private int i;
>     @property int foo // may be without @property at all?
>     {
>         get { return i; }
>         set { i = @value; }
>     }
> }
> 
> In this solution property is not defined by naming of two separate functions and is independent of any function in general.

Hmm, the current state of them being defined by two separate functions really isn't ideal. But introducing new keywords or magic identifiers just for this does not seem right.

   class A
   {
       private int i;
       int foo {
           out { return i; }
           in(int v) { i = v; }
       }
   }

or

   class A
   {
       private int i;
       @property foo {
           int out { return i; }
           in(int v) { i = v; }
       }
   }

artur

On Saturday, 26 January 2013 at 21:48:54 UTC, Artur Skawina wrote:
[..]
>
> Hmm, the current state of them being defined by two separate functions really
> isn't ideal. But introducing new keywords or magic identifiers just for this
> does not seem right.
>
>    class A
>    {
>        private int i;
>        int foo {
>            out { return i; }
>            in(int v) { i = v; }
>        }
>    }
>
> or
>
>    class A
>    {
>        private int i;
>        @property foo {
>            int out { return i; }
>            in(int v) { i = v; }
>        }
>    }
>
> artur

In a more pefect world, we'd redefine what a variable and function is, merging the two together as one, let the compiler optimize things appropriately, and make the language issues far more consistent and simple.

For example, typeof(x) is way too simplistic to be of use when you have objects that have more than on type. For example, a property has a setter, getter, and storage type, so what should typeof(prop) return? It can only tell you one thing out of at least 3 things, so it's insufficient.

Great for C, useless for D.

We're basically finding ourselves in the same position C++ has found itself in, where the old concepts are no longer suitable for a modern language, but there's no practical way to resolve the situation without redesigning the whole language into a new one. D tried to make a better C++, and it has done a good job of that up to a point, but since it has made use of many of the old paradigms as its base, it can only do so much.

One solution is to not bother trying to add on any extra complexity that does not fit in.

--rt

We can almost implement properties as a regular struct

struct prop
{
    int _val;
    ref prop opAssign( int a_val )
    {
        writeln("assignment = ", a_val );
        _val = a_val;
        return this;
    }
    int opCall()
    {
        writeln("opcall = ", _val );
        return _val;
    }

    // other op overloads, like ++, --, etc

}

If we change a few things it may work. Instead of struct it could be named prop

eg

prop P
{

   ...

}

opCall needs to be changed so there's no need to specify the (). No dounbt other changes will be needed too to make it more convenient to use and less error prone.

The advantage is that with a "property as a struct" implementation, you can wrap up a lot more than just a setter and getter around only one variable, eg internally there could be several vars or even none at all depending on the needs.

--rt

On Sat, Jan 26, 2013 at 2:24 PM, Rob T <alanb@ucora.com> wrote:

> We're basically finding ourselves in the same position C++ has found itself in, where the old concepts are no longer suitable for a modern language, but there's no practical way to resolve the situation without redesigning the whole language into a new one. D tried to make a better C++, and it has done a good job of that up to a point, but since it has made use of many of the old paradigms as its base, it can only do so much.
>
>
That is what I have been noticing as well, unfortunately.  As a long time lurker, I like many of the concepts that D introduces, but the many little quirks here and there add up and probably make adoption by a large community much less likely.

It would be great if we had more programming languages competing to change the systems programming landscape. The popular systems languages we have been stuck with (namely C and C++) are a mess, and the "replacements" I see announced every once in a while never seem to become bigger than side projects. Currently, the only other potential option I see is Rust.

Why not take it all the way? Start with a proper release plan, be willing to break backward compatibility (maybe even by changing the name of the language -- perception matters), take into account all what was learned from the past 10+ years of D's history, potentially try to get corporate backing, and maybe we will have something that is practically viable to push aside C and C++.

Then again, maybe I dream too much...

--
Ziad

On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
> We can almost implement properties as a regular struct
[...]

You do it like this:

	import std.stdio;

	struct IntProp {
		int __impl;

		@property /* <-- ah, the irony! */ int value() {
			return __impl + 123;
		}
		alias value this;	// watch this magic

		void opAssign(int val) {
			__impl = val - 123;
		}
	}

	struct S {
		IntProp prop;
	}

	void main() {
		S s;
		writeln(s.prop);
		s.prop = 321;
		writeln(s.prop);
	}


T

-- 
Gone Chopin. Bach in a minuet.

On 1/26/2013 5:21 AM, Jacob Carlborg wrote:
> On 2013-01-25 22:20, Andrei Alexandrescu wrote:
>
>> That's right with the amendment that we're looking for a solution, not
>> pushing one. Even the title of the thread is a question.
>>
>> Clearly properties are good to have. In an ideal world we wouldn't need
>> a keyword for them and we'd have some simple rules for determining
>> property status (especially when it comes to writes). If syntactic help
>> is necessary, so be it. We want to make the language better, not worse.
>
> It's always possible to avoid keywords in favor of syntax. Example:
>
> Declaring a getter:
>
> int foo {}
>
> Just as a regular function declaration but without the parentheses.

Problems if you want to declare the getter but not provide an implementation.

> Declaring a setter:
>
> void foo= (int value) {}
>
> Append an equal sign to the function name.

It is rather similar to a variable declaration with initializer:

   T foo = expression;

On Sunday, 27 January 2013 at 01:11:05 UTC, H. S. Teoh wrote:
> On Sun, Jan 27, 2013 at 01:15:29AM +0100, Rob T wrote:
>> We can almost implement properties as a regular struct
> [...]
>
> You do it like this:
>
> 	import std.stdio;
>
> 	struct IntProp {
> 		int __impl;
>
> 		@property /* <-- ah, the irony! */ int value() {
> 			return __impl + 123;
> 		}
> 		alias value this;	// watch this magic
>
> 		void opAssign(int val) {
> 			__impl = val - 123;
> 		}
> 	}
>
> 	struct S {
> 		IntProp prop;
> 	}
>
> 	void main() {
> 		S s;
> 		writeln(s.prop);
> 		s.prop = 321;
> 		writeln(s.prop);
> 	}
>
>
> T

Ah cool! You don't really need @property however if we adopt the optional () unless that's to be enforced.

The really nice thing about this, is we can return the struct as a ref, and it still works, and also take the address of the struct and it continues to work.

Even better I can add more member functions to it and expand on what it can do. The "property as a function" approach is far more limiting and has issues, such as ref returns and taking the address.

Anyone know what's missing or what won't work with this approach?

--rt

It would be cool if we could declare variables with anonymous types;

struct { opAssign() {} } foo;

On Sunday, 27 January 2013 at 02:54:55 UTC, Adam D. Ruppe wrote:
> It would be cool if we could declare variables with anonymous types;
>
> struct { opAssign() {} } foo;

This would be much easier to understand:

alias foo struct { opAssign() {} };

Is "singleton structures", a.k.a. properties, a good name for these?

On Sunday, 27 January 2013 at 05:32:25 UTC, Zach the Mystic wrote:
> On Sunday, 27 January 2013 at 02:54:55 UTC, Adam D. Ruppe wrote:
>> It would be cool if we could declare variables with anonymous types;
>>
>> struct { opAssign() {} } foo;
>
> This would be much easier to understand:
>
> alias foo struct { opAssign() {} };
>
> Is "singleton structures", a.k.a. properties, a good name for these?

Actually, I don't even think you need alias:

foo struct { opAssign() {} }