On Sun, 08 Nov 2009 09:33:39 -0500
Mehmet Erol Sanliturk wrote:
> Marco van de Voort wrote:
> > On Sun, Nov 08, 2009 at 12:17:35AM +, Howard Page-Clark wrote:
> On Sat, 7 Nov 2009, Marco van de Voort wrote:
> > This is not orthogonal. VAR parameters are generally updated
> > inst
Marco van de Voort wrote:
On Sun, Nov 08, 2009 at 12:17:35AM +, Howard Page-Clark wrote:
On Sat, 7 Nov 2009, Marco van de Voort wrote:
This is not orthogonal. VAR parameters are generally updated
instantaniously. By delaying the update over a temp variable you break
another aspect of the VA
On Sun, Nov 08, 2009 at 12:17:35AM +, Howard Page-Clark wrote:
> > > On Sat, 7 Nov 2009, Marco van de Voort wrote:
> > >> This is not orthogonal. VAR parameters are generally updated
> > >> instantaniously. By delaying the update over a temp variable you break
> > >> another aspect of the VAR p
Howard Page-Clark wrote:
On Sun, 8 Nov 2009 08:13:28 +1000
Alexander Klenin wrote:
On Sat, 7 Nov 2009, Marco van de Voort wrote:
This is not orthogonal. VAR parameters are generally updated
instantaniously. By delaying the update over a temp variable you break
another aspect of the VAR parame
Alexander Klenin schrieb:
Using temporary variables, there will be one call to each.
Where would you place such temporary variables, in your sample code? Into an
invisible layer between the caller and MyInc2?
Eh... on the stack, as usual. I am not sure what do you mean by
"invisible layer".
On Sun, 8 Nov 2009 08:13:28 +1000
Alexander Klenin wrote:
> > On Sat, 7 Nov 2009, Marco van de Voort wrote:
> >> This is not orthogonal. VAR parameters are generally updated
> >> instantaniously. By delaying the update over a temp variable you break
> >> another aspect of the VAR parameter.
I do
On Sun, Nov 8, 2009 at 03:07, Michael Van Canneyt
wrote:
> On Sat, 7 Nov 2009, Marco van de Voort wrote:
>> This is not orthogonal. VAR parameters are generally updated
>> instantaniously. By delaying the update over a temp variable you break
>> another aspect of the VAR parameter.
>
> Not to ment
On Sat, 7 Nov 2009, Marco van de Voort wrote:
On Sat, Nov 07, 2009 at 01:44:39PM +1000, Alexander Klenin wrote:
1) The change was correct in the sense that all properies should be treated
begin
temp := MyObj.MyIntProperty;
Inc(temp);
MyObj.MyIntProperty := temp;
end;
Of course, if the
On Sat, Nov 07, 2009 at 01:44:39PM +1000, Alexander Klenin wrote:
> 1) The change was correct in the sense that all properies should be treated
> begin
> temp := MyObj.MyIntProperty;
> Inc(temp);
> MyObj.MyIntProperty := temp;
> end;
>
> Of course, if the compiler determines that the propert
Vincent Snijders wrote:
Graeme Geldenhuys schreef:
2009/11/7 Marc Weustink :
At that time I proposed this too and there was a valid reason not to
generate such code.
And that valid reason would be? I agree with Alexander and Mattias,
why can't the compiler generate such code behind the scen
On Sat, Nov 7, 2009 at 23:24, Hans-Peter Diettrich wrote:
> Alexander Klenin schrieb:
>> Using temporary variables, there will be one call to each.
>
> Where would you place such temporary variables, in your sample code? Into an
> invisible layer between the caller and MyInc2?
Eh... on the stack,
Alexander Klenin wrote:
On Sat, Nov 7, 2009 at 14:15, Martin wrote:
The answer was that properties are meant to change the value on the object
immediately. Also a property setter can raise an exception, or additional
actions can take place or the value can be substituted
All this wouldn
Martin schrieb:
Inc(MyObj.MyIntProperty);
=>
var
temp: Integer;
begin
temp := MyObj.MyIntProperty;
Inc(temp);
MyObj.MyIntProperty := temp;
end;
Of course, if the compiler determines that the property is an alias
for a field,
it is free to pass the field directly -- but this is only an
Alexander Klenin schrieb:
The answer was that properties are meant to change the value on the object
immediately. Also a property setter can raise an exception, or additional
actions can take place or the value can be substituted
All this wouldn't happen with a temp variable (or at best defe
Graeme Geldenhuys schrieb:
At that time I proposed this too and there was a valid reason not to
generate such code.
And that valid reason would be? I agree with Alexander and Mattias,
why can't the compiler generate such code behind the scenes?
IMO "such" code (with temporary variables) is
Alexander Klenin schrieb:
IMHO:
1) The change was correct in the sense that all properies should be treated
equally, regardless of their implementation. If that means (temporarily) loss
of features, than so be it.
2) However, there is an obvious room for improvement here:
not only Inc/Dec, but
Paul Ishenin schrieb:
Alexander Klenin wrote:
Inc(MyObj.MyIntProperty);
=>
var
temp: Integer;
begin
temp := MyObj.MyIntProperty;
Inc(temp);
MyObj.MyIntProperty := temp;
end;
Property does not need to have a reader.
A compiler magic can check for both read and write access to a prop
Graeme Geldenhuys schreef:
2009/11/7 Marc Weustink :
At that time I proposed this too and there was a valid reason not to
generate such code.
And that valid reason would be? I agree with Alexander and Mattias,
why can't the compiler generate such code behind the scenes?
It is better to h
2009/11/7 Marc Weustink :
>
> At that time I proposed this too and there was a valid reason not to
> generate such code.
And that valid reason would be? I agree with Alexander and Mattias,
why can't the compiler generate such code behind the scenes?
--
Regards,
- Graeme -
Alexander Klenin wrote:
For each property argument, the compiler should create temporary variable,
set it by reading the property before the function call, and set
property to the new value
after the call.
Inc(MyObj.MyIntProperty);
=>
var
temp: Integer;
begin
temp := MyObj.MyIntProperty;
I
On Sat, 7 Nov 2009 13:44:39 +1000
Alexander Klenin wrote:
>[...]
> 2) However, there is an obvious room for improvement here:
> not only Inc/Dec, but any procedure accepting var parameter
> should be able to accept writeable property of the same type.
Var parameters must fit exactly for typecast
21 matches
Mail list logo
