- refactoring may break your code
- typos may break your code
- no possible compiler checks for correctness
- no code completion support
type TFunc<T> = reference to function: T;As you also may know this is a reference counted type. Guess how it is implemented? Correct, with an interface. This is similar to:
type IFunc<T> = interface function Invoke(): T; end;You can even use those method reference types as Interface when you implement a class:
type TMyFuncClass = class(TInterfacedObject, TFunc<Integer>) public function Invoke: Integer; end;Or you can inherit your interface from it (and of course implement that interface into your class):
type IFunc<T> = interface(TFunc<T>) end;Ok, but we were talking about properties, right? Well a property basically is not much more than the combination of a function and a procedure - the getter and the setter.
We could define it like this:
type IProp<T> = interface function GetValue: T; procedure SetValue(Value: string); property Value: T read GetValue write SetValue; end;So it is nothing more than (of course this does not work):
type IProp<T> = interface(TFunc<T>, TProc<T>) property Value: T read Invoke write Invoke; end;But what you can do is this:
type TProp<T> = class(TInterfacedObject, TFunc<T>, TProc<T>) private function Invoke: T; overload; procedure Invoke(Value: T); overload; public property Value: T read Invoke write Invoke; end;We can take this and use it as property reference passing it around, getting and setting values using RTTI but there we are again, how to create an instance? Yes, specifying the instance and the property by string. Another possibility would be with anonymous methods wrapping the property.
How about some built in type like this?
type TProp<T> = reference to property: T;So I could write something like this:
procedure ShowAndInc(AProp: TProp<NativeInt>); begin ShowMessageFmt('%d', [AProp]); AProp := AProp + 1; end; procedure Form1Button1Click(Sender: TObject); begin ShowAndInc(Self.Tag); end;
What the compiler actually needs to do is something like this (ignoring possible read or write only properties for now):
ShowAndInc(TProp<NativeInt>.Create( function: NativeInt begin Result := Self.Tag; end, procedure(Value: NativeInt) begin Self.Tag := Value; end));This is the code of my actual working TProp class and interface:
type IProp<T> = interface function Invoke: T; overload; procedure Invoke(Value: T); overload; property Value: T read Invoke write Invoke; end; TProp<T> = class(TInterfacedObject, IProp<T>) private FGetter: TFunc<T>; FSetter: TProc<T>; function Invoke: T; overload; procedure Invoke(Value: T); overload; public constructor Create(Getter: TFunc<T>; Setter: TProc<T>); property Value: T read Invoke write Invoke; end; { TProp<T> } constructor TProp<T>.Create(Getter: TFunc<T>; Setter: TProc<T>); begin FGetter := Getter; FSetter := Setter; end; function TProp<T>.Invoke: T; begin Result := FGetter; end; procedure TProp<T>.Invoke(Value: T); begin FSetter(Value); end;The compiler could do it way better by directly putting the call to the getter and setter into the right places.
So what do you think? Do you want reference to property in one of the next Delphi versions? Any drawbacks I am not seeing right now?
Cool!
ReplyDeleteBut for binding and other stuff I would be happy to have at least a simple compiler magic function like we have for TypeOf() and TypeInfo(), say PropInfo():
TObject = class
TestProp: Integer;
end;
var
p: PPropInfo;
p := PropInfo(TObject.TestProp);
But with your "property reference" more cool stuff can be done! Then you can use a property like an object (or pointer): change it in one place and all "pointers" read the same value.
The compiler could check for read/write properties. For read only properties a "reference to readonly property" could be used.
One problem is that the default property reference doesn't have a Getter.
ReplyDeleteFor now, I've ended up using explicit anonymous setters and getters for each property, which do have other benefits such as allowing for conditional value trimming.
In a way, the string reference issue could be worked around by introcuing what I imagine to be a fairly simple compiler magic function RefNameToStr(SomeProperty) that returns 'SomeProperty'.
I'd like a CurrentMethodName function as well :P.
Direct access to field variables would not be a big problem if the whole feature was implemented into the compiler.
ReplyDeleteCurrentMethodName? JclDebug.ProcByLevel() is your friend. :)