February 24, 2007
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
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
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
1 2 3
Next ›   Last »