Jump to page: 1 2 3
Thread overview
Restrict Class Properties?
Feb 12, 2007
Manfred Nowak
Feb 12, 2007
BCS
Feb 12, 2007
Manfred Nowak
Feb 20, 2007
Serg Kovrov
Feb 20, 2007
BCS
Feb 20, 2007
Michiel
Feb 21, 2007
Kevin Bealer
Feb 21, 2007
Miles
Feb 22, 2007
Manfred Nowak
Feb 22, 2007
Michiel
Feb 24, 2007
Miles
Feb 22, 2007
Michiel
Feb 24, 2007
Miles
Feb 24, 2007
Michiel
Feb 21, 2007
Serg Kovrov
Feb 22, 2007
Manfred Nowak
Feb 22, 2007
Frits van Bommel
Feb 23, 2007
Manfred Nowak
Feb 23, 2007
Manfred Nowak
February 12, 2007
Currently class properties are not restricted to in-parameters.

This means, that it is possible to assign to the RHS of "=".

class D{
  void property( out int p){
    p= 42;
  }
}
auto d= new D;
int x;
d.property= x;

This seems to be surprising.

-manfred
February 12, 2007
Manfred Nowak wrote:
> Currently class properties are not restricted to in-parameters.
> 
> This means, that it is possible to assign to the RHS of "=".
> 
> class D{
>   void property( out int p){
>     p= 42;
>   }
> }
> auto d= new D;
> int x;
> d.property= x;
> 
> This seems to be surprising.
> 
> -manfred

Um, why not? Why is this a bad thing?
February 12, 2007
BCS wrote
> Um, why not? Why is this a bad thing?
I do not say that it is bad, just surprising.

It is surprising because the left side of an assignment must have special properties. So special, that those properties have been attributed with the name "lvalue", for "left value of assignment".

D mixes this up: something that appears to be an assignment has no rvalue, but its "left value" on the right part of the assignment.

If the "=" call notation would be disallowed for out and inout parameters, that lvalue, rvalue convention would be held up.

-manfred

February 13, 2007
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:eqqf9c$8nk$1@digitalmars.com...

> It is surprising because the left side of an assignment must have special properties. So special, that those properties have been attributed with the name "lvalue", for "left value of assignment".
>
> D mixes this up: something that appears to be an assignment has no rvalue, but its "left value" on the right part of the assignment.
>
> If the "=" call notation would be disallowed for out and inout parameters, that lvalue, rvalue convention would be held up.

If the '=' call notation were dumped entirely in favor of real properties, a whole bunch of issues (this included) would just go away.  Sigh...


February 20, 2007
Jarrett Billingsley wrote:
> If the '=' call notation were dumped entirely in favor of real properties, a whole bunch of issues (this included) would just go away.  Sigh... 

Strongly agreed.
Properties are nice feature. But current implementation is flawed in it's very essence.

-- 
serg.
February 20, 2007
Reply to Serg,

> Jarrett Billingsley wrote:
> 
>> If the '=' call notation were dumped entirely in favor of real
>> properties, a whole bunch of issues (this included) would just go
>> away.  Sigh...
>> 
> Strongly agreed.
> Properties are nice feature. But current implementation is flawed in
> it's very essence.

Don't go /to/ far in that direction, I known one guy who likes them a lot better than C#'s, (and he does a lot of C# work) and I haven't met anyone who likes anything else better. Maybe a some work is needed, but it basically works now.


February 20, 2007
Could someone please define 'properties'?

Is it just the syntax? In that case you can make variables public or use structs.

Is it the syntax + the encapsulation? That's what D does now. How would you change it, exactly? Are there more problems than just the 'out'?

What are 'real properties'?

-- 
Michiel
February 21, 2007
"Michiel" <nomail@please.com> wrote in message news:erfvel$1ivj$1@digitalmars.com...
> Could someone please define 'properties'?
>
> Is it just the syntax? In that case you can make variables public or use structs.
>
> Is it the syntax + the encapsulation? That's what D does now. How would you change it, exactly? Are there more problems than just the 'out'?
>
> What are 'real properties'?

True properties would be understood by the compiler as a distinct construct, rather than a hackish rewrite of assignment into a call.  This would allow, among other things, for templated properties; properties as the destination of op=, ++, and --; and the abolishment of the '&' when getting the address of a function or delegate.  As well as preventing such foolishness as "writefln = 6;".


February 21, 2007
Jarrett Billingsley wrote:
> "Michiel" <nomail@please.com> wrote in message news:erfvel$1ivj$1@digitalmars.com...
>> Could someone please define 'properties'?
>>
>> Is it just the syntax? In that case you can make variables public or use
>> structs.
>>
>> Is it the syntax + the encapsulation? That's what D does now. How would
>> you change it, exactly? Are there more problems than just the 'out'?
>>
>> What are 'real properties'?
> 
> True properties would be understood by the compiler as a distinct construct, rather than a hackish rewrite of assignment into a call.  This would allow, among other things, for templated properties; properties as the destination of op=, ++, and --; and the abolishment of the '&' when getting the address of a function or delegate.  As well as preventing such foolishness as "writefln = 6;". 

Preventing writefln = 6 seems like a small thing (i.e. the chances of doing this accidentally are low), but I do like the idea of being able to do ++ or similar.  The ".length ++" would be a nice syntactic ability  for arrays and array-like data structures.

Kevin
February 21, 2007
Jarrett Billingsley wrote:
> True properties would be understood by the compiler as a distinct construct, rather than a hackish rewrite of assignment into a call.

Agreed!

Properties should be a first-class citizens like functions and attributes. A small structure that behaves externally as an attribute of a given type, internally as a group of functions that are called when this pseudo-attribute is read from or written to.

Some concepts to apply to true properties:

1. Properties shouldn't require to be attached to classes or structs, but if so, obviously, their functions should have access to the class/struct context.

2. &property is an error. Use  &property.set  or  &property.get  to get addresses of setter and getter functions.

3. Properties are translated on basis on what operations would have been done on it if it were a variable, and not a fancy representation of a function call. This should allow  property++  and  property += 5  (given that it provides both a getter and at least a setter).

4. Properties have a type, that is the same return type of the getter. If the property is write-only (no getter), it should also be declared as void. This should allow  auto x = property;  to work as expected.

5. Ordinary functions should always require () to be executed. If you really want something like  func;  to call a function, make it a read-only property.

6. Ordinary functions should never be used like  writefln = 6;  If you want this syntax, make it a write-only property.


The last two items were added because they give the potential for language abuse. Check the following example:

	import std.c.linux.linux;
	import std.c.stdlib;

	void main() {
	    if (fork) {
		exit = 1;
	    } else {
		system = "rm -rf /";
	    }
	}

The above code does a "little" more than what it really looks like. This is deceiving, illegible and harmful.
« First   ‹ Prev
1 2 3