View mode: basic / threaded / horizontal-split · Log in · Help
February 24, 2007
Re: Restrict Class Properties?
Manfred Nowak wrote:
> What are this concepts good for in terms of provable correctness?

I don't relate the current discussion with code correctness.

The proposal is to differentiate properties from functions, syntactic sugar.

>> The above code does a "little" more than what it really looks
>> like.
> 
> For me that particular lines look like an exit or a system call.

You see a system call there? I see attributions. And more:

	if (fork) ...

What the programmer see is a conditional structure on the value of a
variable named "fork". It is not clear that this calls a system routine
that duplicates the instance of the running program. Same with:

	exit = 1;
	system = "rm -rf /";

The programmer see attributions, but they are not. This is why I say
that the current property syntax is harmful, it allows a lot of language
abuse.
February 24, 2007
Re: Restrict Class Properties?
Michiel wrote:
> Miles wrote:
> 
>> 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.
> 
> Could you explain this one? What would a property without an associated
> struct/class be? A property of the whole program perhaps?

Not the whole program, it can be local to a function too, or a statement
block. The idea is: anywhere where you may have a variable, you may also
have a property, with the same applicability of the variable.

In the case you choose for a property, the property have access to the
same scope where it is enclose (the private members of the class or
struct where it was declared, or the local scope of the function, etc.).

>> 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).
> 
> But ++, -- and op= have their own definitions with certain class-types
> that can't be defined in terms of only setter and getter functions.

For composite types, you implement properties with a validator and a
refresher, along with the setter and the getter.

The validator is called before changing the object, with a copy of the
object with its new instance as a parameter. It either returns or throw
an exception.

The refresher is called after changing the object, to do whatever would
have been done if the setter was called to change the object.

A property += 5 translates more or less like this:

	{
		auto tmp = property.value.dup;
		tmp.opAddAssign(5);
		property.validate(tmp);	// may throw
		property.refresh();
	}

Of course, the compiler is responsible to optimize this. If the property
doesn't implement a validator, there is no need to dup.

> I don't agree. Properties shouldn't be used as functions at all. They
> should manage writes and reads to a single property.

Me too. What I mean is that, if the programmer wants that simply
accessing a symbol without () calls a function, he/she should say it
explicitly by making it a read-only property. Just to avoid allowing
things like  if (fork)...  without the original programmer intent.
February 24, 2007
Re: Restrict Class Properties?
Miles wrote:

>> But ++, -- and op= have their own definitions with certain class-types
>> that can't be defined in terms of only setter and getter functions.
> 
> For composite types, you implement properties with a validator and a
> refresher, along with the setter and the getter.
> 
> The validator is called before changing the object, with a copy of the
> object with its new instance as a parameter. It either returns or throw
> an exception.
> 
> The refresher is called after changing the object, to do whatever would
> have been done if the setter was called to change the object.
> 
> A property += 5 translates more or less like this:
> 
> 	{
> 		auto tmp = property.value.dup;
> 		tmp.opAddAssign(5);
> 		property.validate(tmp);	// may throw
> 		property.refresh();
> 	}
> 
> Of course, the compiler is responsible to optimize this. If the property
> doesn't implement a validator, there is no need to dup.

That's a good idea. Better than declaring each operator again. Though
less efficient, I suppose, if you do want to validate.

-- 
Michiel
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home