Feature Request: Passing properties to var parameters should be possible ?

[Skybuck Flying]

Hello,

It would great if Delphi somehow managed to pass properties to var
parameters and have the routines call the properties set methods instead of
directly working on some variable field.

Seems like the language is now half broken...

Gotta be fixed ! :D

Bye,
Skybuck.

[Skybuck Flying]

Maybe add some keyword directive for parameters:

procedure Test( Var Property ModifyMe : uint64 );
begin
ModifyMe := 1000;
end;

Means:
Variables and Properties can be passed to the routine.

Bye,
Skybuck.

[Skybuck Flying]

I had an idea: problem might be solvable by adding an extra setter method to
routines to have the routine call the property.

Unfortunately the compiler can't handle it:

type
TsetUint64 = procedure( Value : uint64 ); // incompatible with record
procedures ?
TsetUint64 = procedure( Value : uint64 ) of record; // not supported
TsetUint64 = procedure( Value : uint64 ) of object; // leads to internal
compiler error.


procedure Test( ModifyMe : uint64; Setter : TsetUint64 );
begin
ModifyMe := 1000;

if Assigned(Setter) then
begin
Setter(ModifyMe);
end;
end;

Test( vPacket.Header[vBitMode].Number, vPacket.Header[vBitMode].SetNumber );
// boom.

Bye,
Skybuck.

[Skybuck Flying]

Hello,

Here is a solution how the compiler could pass properties to var parameters:

As long as the property is an integer native type it's allowed to be passed
to the var parameter:

procedure Test( var Para : integer );
begin
Para := 1000;
end;

// the call is what needs to change:

The property is simply read into a register, passed to the routine, and
updated after the call.

call PropertyRead( cpu_register )
call Test( cpu_register );
call PropertyWrite( cpu_register )

See as long as 32 bit registers are used and hopefully in the future 64 bit
registers possible this will work just fine.

Not a big deal ! ;)

Ofcourse replace the read/write calls with a move if the property don't have
setter and getter methods.

Bye,
Skybuck.

[Nicholas Sherlock]

Post by Skybuck Flying
The property is simply read into a register, passed to the routine, and
updated after the call.
call PropertyRead( cpu_register )
call Test( cpu_register );
call PropertyWrite( cpu_register )

Which is totally worthless. The setter will see things as they are after
the call, not as they would be during the call. So this code:

procedure DoStuff(var i:integer);
begin
i:=2;
i:=3;
end;

procedure TMyClass.setI(i:integer);
begin
showmessage(inttostr(i));
end;

Would show 3, and would never show 2.

Cheers,
Nicholas Sherlock

[Skybuck Flying]

DoStuff works on integers, not on properties.

The concept of the routine is:

<take input>

do some magical stuff that nobody really cares about, like a blackbox.

<return output>

I would be quite happy with this, saves me lots of trouble.

The parameter could be considered a temporarely variable which kind of
breaks the "var" concept.

Properties don't really have memory cells or variables, they can behind the
scenes, but it's not required.

Delphi apperently has this weird syntax which allows:

procedure Test( var I : integer );
begin
@I;
end;

var
a : integer;

Test( A );
@A

Address of I = Address of A.

This would no longer be true with the proposed solution.

Instead

Address of I = address of temporarely variable
Address of A = does not exist.

So what if the routine is fooled... there is no real variable to start with.

The only thing the compiler could do is hint at/warn the programmer that the
routine is taking the address of a compiler generated temporarely variable
which was created to be able to pass the property to the routine/parameter.

So the compiler warns:

The compiler generated a temporarely variable to be able to pass the
property to the var parameter of the routine. Address of parameter is
address of temporarely variable. After routine exists temp variable is
assigned to property and temp variable goes out of scope/is cleaned up.

The compiler could detect this at compile time, or if this is too complex,
use debugging code to detect this, however I think it's probably pretty easy
for the compiler, because it can already detect that the programmer is
trying to pass a property to a var parameter which is currently not allowed.

So if properties are now allowed to be passed, the compiler knows it has to
scan the routine for any "address of" operators.
If the compiler finds any "address of" operators it warns the programmer the
routine is possibly taking the address of the parameter.
Further scanning of the routine and it's code could give certainty.

This feature would save me lots trouble and thus time and the same would
probably apply to many other programmers as well.

And it would create nice and powerfull possibilities.

This is definetly NUMBER ONE feature I would like to see implemented for
next version of Delphi ;)

If it is not implemented I will end up in "update" hell:

For example:

vTemp := Tsomething.SomeWhere.WhoKnows.Property;
SomeRoutine( vTemp );
Tsomething.SomeWhere.WhoKnows.Property := vTemp;

I would rather just write:

SomeRoutine( Tsomething.SomeWhere.WhoKnows.Property );

1. It's shorter, saves many lines.
2. It's easier, the compiler creates the temporarely variables instead of
the programmer.
3. It's safer, no stupid mistakes, like:

3.1 Forgot to read the property into the temp variable.
3.2 Forgot to write the temp variable back to the property.

4. It's easier to write consistent code, instead of which one shall I use
for next line: temp variable or property ?

5. Properties allow the value returned from the routine to be modified
further because the compiler immediatly calls the setter before throwing
away the temp variable.

Performance wise it doesn't matter that much unless the temporarely variable
was re-used for many lines of code by the programmer
this would save some property getters/setters calls.

This is a trade-off which the programmer will have to decide about:

"It's it worth using a explicit temp variable for multiple lines of code to
get a performance improvement ?"

"Or shall I let the compiler take care of it ;) and have the benefits
mentioned above"

My solution now looks like:

Tsomething.SomeWhere.WhoKnows.ReadRealFieldIntoTempField; // procedure
SomeRoutine( Tsomething.SomeWhere.WhoKnows.TempField ); // field
Tsomething.SomeWhere.WhoKnows.WriteTempFieldToRealField; // procedure

This prevents having to use local temp variables on the stack, and instead
temp variables are in the record itself.

But still needs the update hell.

And it's not handy for temp arrays... because that's bad for performance.

So I used index properties to access array elements.

That means I can't pass the array elements to var parameters... because they
are "propertied".

In other words currently properties can be a big drawback while coding.

This feature/solution would erradicate this very nasty drawback.

Bye,
Skybuck.

[Rob Kennedy]

Post by Nicholas Sherlock
Which is totally worthless. The setter will see things as they are after
procedure DoStuff(var i:integer);
begin
i:=2;
i:=3;
end;
procedure TMyClass.setI(i:integer);
begin
showmessage(inttostr(i));
end;
Would show 3, and would never show 2.

Incidentally, that shortcoming is built in to Delphi for .Net's
implementation of untyped parameters.

http://hallvards.blogspot.com/2007/10/dn4dp24-net-vs-win32-untyped-parameters.html

[Skybuck Flying]

Very Good Rob.

You found an example which shows the compiler can already do it, to solve
other similiar problems, that's interesting.

You call it a drawback, but really it is a feature !

This proves it can be done, and I believe it should be done.

What do you believe ? ;)

If you believe this is a very good idea and if you are sick of having to use
temp variables to work with properties and var parameters then please
request this feature to be added to a next version of Delphi and hopefully
it will have it that would make me really happy !

What about you !? ;)

Bye,
Skybuck.