View mode: basic / threaded / horizontal-split · Log in · Help
February 12, 2007
Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
"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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
"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
Re: Restrict Class Properties?
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
Re: Restrict Class Properties?
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
Top | Discussion index | About this forum | D home