On 2009-07-24 17:40:37 -0400, Walter Bright <newshound1@digitalmars.com> said:

> It's just that D is complex enough - there needs to be some very good reasons for adding more syntax that has apparently zero semantic information that would be different from the usual function syntax.

You know. I agree with you on that point. Earlier, in a thread no one replied to [1], demonstrated that we already have almost everyting we need to create properties using mixins. Here's an example:

	struct Z
	{
		int valueSquare;

		template Property()
		{
			int value;

			void opAssign(int v) { value = v; valueSquare = value * value; }
			void opAddAssign(int v) { value = v; valueSquare = value * value; }
			int get() { return value; }

			alias get this;
		}

		mixin Property property;
	}

The only really missing part is that "alias get this" doesn't work ("Error: expression has no value" when fetching a value from z.property) so you have to explicitly call the "get" function.

[1]: http://www.digitalmars.com/d/archives/digitalmars/D/properties_using_template_mixins_and_alias_this_87952.html

-- 


Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Andrei Alexandrescu wrote:
> Well I use it sometimes too, but it's so fraught with peril that virtually all coding standards I've ever seen, all books and magazine articles on the topic, all pundits, say one thing: don't. Better use composition.

My take on composition vs inheritance is very simple: always use composition, unless you absolutely need inheritance.  Sometimes I absolutely need inheritance, and D isn't giving it to me.

I don't care about your coding standards.  I know how to use C++.  I have my own rules about how to use it safely and effectively, rules that I have spent a lifetime refining.  I still make mistakes, but almost all of my bugs are of the simple stupid kind that can be made in all languages.  I don't need or want D to protect me from the pitfalls of C++ if this means significantly reducing the expressive power of the language.  I don't want a safe language for little kids, I want a real language for adults.

(And, truly, D is better in this regard than many of its competitors.
Perhaps the awesome power of string mixins will be enough to offset its
 missing features.  I will definitely give D2 a try when it is finished.)


-- 
Rainer Deyke - rainerd@eldwood.com

On 2009-07-24 22:58:33 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> This is pretty clean, and in keep with the opXxx approach. Actually how about defining property foo by defining opGet_foo and opSet_foo.

The problem with this is that it's ugly. What about this

	int foo.opGet();        // getter
	void foo.opAssign(int); // setter

with some support from the compiler.

It could even be exteded to support more:

	int foo.opIndex(int); // foo[1];
	void foo.opAddAssign(int); / foo += 1;
	void foo.invert(); // special function attached to property


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> Well I use it sometimes too, but it's so fraught with peril that
>> virtually all coding standards I've ever seen, all books and magazine
>> articles on the topic, all pundits, say one thing: don't. Better use
>> composition.
> 
> My take on composition vs inheritance is very simple: always use
> composition, unless you absolutely need inheritance.  Sometimes I
> absolutely need inheritance, and D isn't giving it to me.
> 
> I don't care about your coding standards.  I know how to use C++.  I
> have my own rules about how to use it safely and effectively, rules that
> I have spent a lifetime refining.

Whether we like it or not, programming has a large social component.

Andrei

On Fri, 24 Jul 2009 12:30:23 -0300, Leandro Lucarella wrote:

> Adam D. Ruppe, el 23 de julio a las 22:56 me escribiste:

>> Tuple!(int, int) getPoint() { return tuple(5,2); }
>> 
>> That works, but then you have to address the return value as:
>> 
>> auto p = getPoint();
>> p.field[0] == 5
>> p.field[1] == 2
>> 
>> 
>> Still, easy enough to say:
>> 
>> auto x = p.field[0]; auto y = p.field[1]; x == 5
>> y == 2
> 
> And you still think that's not remarkably worse than something like:
> 
> (int, int) getPoint() { return (5, 2); } auto (x, y) = getPoint();

I would say it isn't remarkably worse. The other one though, that was quite a mess.

> I really think that's the difference between happily using tuples or curse them for the rest of your life :)
> 
> I don't think comma expressions should be used for tuples (I don't care much either), but you can add support to the language without breaking them using something like @(1, 2, 3) or ![ 1, 2, 3 ] or whatever.
> 
> But you should support multple assignment, for example. If you don't, you don't have real tuple support, just a toy tuple emulation.

Tuples have nothing to do with multiple assignment, it is just something languages tend to provide.

Rainer Deyke wrote:
> I don't care about your coding standards.  I know how to use C++.  I
> have my own rules about how to use it safely and effectively, rules that
> I have spent a lifetime refining.

I've been writing software for 35 years. I'm still learning new ways of doing things and discarding old ones.


> (And, truly, D is better in this regard than many of its competitors.
> Perhaps the awesome power of string mixins will be enough to offset its
>  missing features.

Probably the most frustrating thing to me when coding C++ is the lack of nested functions. The workaround is awfully ugly.

Walter Bright wrote:
> Rainer Deyke wrote:
>> I don't care about your coding standards.  I know how to use C++.  I
>> have my own rules about how to use it safely and effectively, rules that
>> I have spent a lifetime refining.
> 
> I've been writing software for 35 years. I'm still learning new ways of doing things and discarding old ones.

But goto will never die :o).

Andrei

Michel Fortin wrote:

> On 2009-07-24 22:58:33 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
> 
>> This is pretty clean, and in keep with the opXxx approach. Actually how about defining property foo by defining opGet_foo and opSet_foo.
> 
> The problem with this is that it's ugly. What about this
> 
> int foo.opGet();        // getter
> void foo.opAssign(int); // setter
> 
> with some support from the compiler.
> 
> It could even be exteded to support more:
> 
> int foo.opIndex(int); // foo[1];
> void foo.opAddAssign(int); / foo += 1;
> void foo.invert(); // special function attached to property
> 
> 

There is a thread discussing the proposal which is also linked to by the wiki. Posting there would be useful, for future reference too.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:h4d9jt$1hq5$1@digitalmars.com...
> Steven Schveighoffer wrote:
>> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>>> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.
>>
>> If you delineate what can be called how, then you elminate syntax ambiguities from occurring, and eliminate bizarro cases of syntax.  The difficulty is that the "human meaning" of a property is different than the human meaning of a function.  To the compiler, they're all functions, so you as the compiler writer aren't seeing that they are different.  I think we all agree that writefln = "hi"; makes absolutely no sense to a person.  But it makes complete sense to the compiler, because it has no idea what the word "writefln" means to a person.
>
> But when I suggest a restriction on properties, I get complaints that someone might want to have them do what functions do. So I fail to see what rule distinguishes them from functions, even for people.
>

I'm not sure what restriction you're talking about, but here's the difference:

Function: Abstracted to a Verb ("write" "sort" "play" "decompress")

Property: Abstracted to a Noun/Adjective ("position" "width" "color" "turret" "ball")

Variable: *Special case of Property*, where the *underlying storage* is never lazy at all and is always exactly the same as what's presented to the class's user.


Here's another (psuedocode) way to describe the difference:

Thing2D ball1, ball2;

ball1.moveTo( [10, 7] ); // Function
ball1.position = [10, 7]; // Property

ball1.moveTo = [10, 7]; // Meaningless bullshit
ball1.position( [10, 7] ); // Meaningless bullshit

ball1.moveTo(ball2.position); // Sensible
ball1.position = ball2.position; // Sensible

ball1.moveTo(ball2.moveTo); // Meaningless bullshit ball1.position = ball2.moveTo; // Meaningless bullshit

>
>> It's the exact same reason + is not the concatenation operator. Semantically, making + concatenate two strings together would be completely unambiguous from adding two integers together because strings do not define addition, and integers do not define concatenation.  From your own documentation, someone seeing "10" + 3 might think that he would get 13 or "103".  Even if the compiler defines what "should" happen, and the rules are unambiguous, it looks incorrect to the user.
>
> Using + for concatenation is syntactically ambiguous with vector addition.

Are you saying that were it not for vector operations you would have used + for concatenation? If not, then you're dodging the point Steven is making.

"Nick Sabalausky" <a@a.a> wrote in message news:h4eg2c$sn8$1@digitalmars.com...
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:h4d9jt$1hq5$1@digitalmars.com...
>> Steven Schveighoffer wrote:
>>> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>>>> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.
>>>
>>> If you delineate what can be called how, then you elminate syntax ambiguities from occurring, and eliminate bizarro cases of syntax.  The difficulty is that the "human meaning" of a property is different than the human meaning of a function.  To the compiler, they're all functions, so you as the compiler writer aren't seeing that they are different.  I think we all agree that writefln = "hi"; makes absolutely no sense to a person.  But it makes complete sense to the compiler, because it has no idea what the word "writefln" means to a person.
>>
>> But when I suggest a restriction on properties, I get complaints that someone might want to have them do what functions do. So I fail to see what rule distinguishes them from functions, even for people.
>>
>
> I'm not sure what restriction you're talking about, but here's the difference:
>
> Function: Abstracted to a Verb ("write" "sort" "play" "decompress")
>
> Property: Abstracted to a Noun/Adjective ("position" "width" "color" "turret" "ball")
>
> Variable: *Special case of Property*, where the *underlying storage* is never lazy at all and is always exactly the same as what's presented to the class's user.
>
>
> Here's another (psuedocode) way to describe the difference:
>
> Thing2D ball1, ball2;
>
> ball1.moveTo( [10, 7] ); // Function
> ball1.position = [10, 7]; // Property
>
> ball1.moveTo = [10, 7]; // Meaningless bullshit
> ball1.position( [10, 7] ); // Meaningless bullshit
>
> ball1.moveTo(ball2.position); // Sensible
> ball1.position = ball2.position; // Sensible
>
> ball1.moveTo(ball2.moveTo); // Meaningless bullshit ball1.position = ball2.moveTo; // Meaningless bullshit
>

With that ball/moveTo/position stuff, I should also clarify that for most of the code/languages across my programming career (save for the occasional cases of deliberate obfuscation and blatanty bad coding standards...oh, and asm of course ;) ) up until D, things have pretty much always worked like this:

IDENTIFIER PARENS: Verb
IDENTIFIER: Noun/Adjective

And especially now, that's becoming more and more the standard convention. (And yea, I'm sure there's a bunch of languages from the 80's and before that were completely different...)