Leaderboard

Hi, this is definitely on the hacky side. Is there a way to gain access to private class var of a class defined in an implementation section ? More precisely, I'm trying to gain access to TDX11Context private class vars, which is defined in the implementation section of FMX.Context.DX11, and the vertex & pixel shaders more specifically. My best attempt so far is to obtain the address of TDX11Context.DoSetShaderVariable (easy, it's virtual and just protected), and there the first line is just if (CurrentVertexShader <> nil) and (Length(FVSBuf) > 0) then begin which is simple enough to "disassemble", get the FVSBuf address, from which the other vars can be inferred. It's all quite fragile though 🙂

The moral here is that private variables are almost as evil as threads. No one knows, forever and for all time, what anyone else might need to access in the future.

@Mike Warren All the feedback above is valid, but will add more comments... Just a comment on your interface where you flagged an error: IapShape = interface procedure SetThing(AThing: Boolean); function GetThing : boolean; // this is what was missing property Thing: Boolean read GetThing write SetThing; end; TapRectangle = class(TRectangle, IapShape) // If you want reference counting, TRectangle should inherit from TInterfacedObject, or else, you need to add the ref counting methods somewhere like TRectangle or here... private FThing: Boolean; function GetThing : boolean; // this can be as trivial as: result := FThing; procedure SetThing(AThing: Boolean); public property Thing: Boolean read FThing write SetThing; // this can actually be different to the interface, but ideally, to be consistent, it should be identical to ensure consistent behaviour end; Hope the comments help. It is possible to have a class implement multiple interfaces, and then in code, you can use methods like supports() to check if an interface supports other interfaces... Anyways, as Arnaud mentioned, composition is generally better, but depending on the scenario, having class/interface hierarchies have their uses.... Having a collection of shapes is a scenario which consist of a rectangles, circles, etc, benefits form the inheritance scenario you described, so if there are generic methods that take place on the shape, it may make sense... e.g. shape.draw, shape.area, shape.position ... but to get to the specific details of a shape, much as with classes, you can get an interface specific to the specialisation (TRectangle, IRectangle...) Anyways, the design topic is vast, and can be very opionated as well 😉 My suggestion in line with Arnaud is something like: in the above, your TRectangle or TCircle would be contained in the FShape field

Interfaces can only have methods, not fields. Your Thing property needs a GetThing method as read accessor and the implemention can then refer to the FThing field of the class implementing the interface. Interfaces also imply lifetime management by reference counting (that comes from their original purpose in Delphi to work with COM). All classes derived from TInterfacedObject have the necessary infrastructure build in, but beware: classes derived from TComponent inherit an implementation of the relevant methods (_AddRef and _Release) that is not reference-counted, since the lifetime of components is controlled by their Owner. So do never store an interface reference obtained from a component in a field/variable that may outlive the component itself, that is a sure way to produce access violations when the compiler-generated code tries to finalize said reference when the field/variable goes out of scope!

This is not yet clean OOP for sure, since it would break the Liskov principle. IMHO there is no way to make it "elegant". My guess is that the "elegant" way is to use composition. That is, compose a "shared object", available to your function, which would have a circle and a rectangle properties, then additional properties. OOP should be as natural as possible. If you are fighting against your types, some refactoring may be needed. Multiple inheritance is IMHO never mandatory, for a clean OOP model. And always refer the the SOLID principles!

@Kas Ob. yes, but the code has not changed in a long while AFAICT. On practical approach might be for EMBT to "officially" allow FMX.Context.XXX open-source forks. This would allow reimplementation projects to be kickstarted, and after a few iterations, there would probably be little left from the original EMBT source code anyway (at least from what I can see in the TDX11Context). The OpenGL context seems less "private", but it still has a lot of private vars in key areas. One of the first things forks would do would probably be to turn those private vars into fields, and support multiple contexts (and eventually multiple threads)

@Eric Grange How about hooking TDX11Context.DoSetShaders ? Wait a second !, TDX11Context is private and non accessible, at least on my XE8, that is bad design to hide a critical and OS dependent class, was the designer so confident it is bug free and it does include everything could be needed from DirectX11 even in the future. From the name DX11, there will be DX12 and even DX13, and they will break compatibility in huge way, so a private one is like, NO update your IDE framework and wait for our updated design...

I guess you already know the answer. Enter a ticket on the Quality Portal to request access to the fields you want. Give a good explanation why whould you want those fields to be public or protected in order to reach MFGA (Make Firemonkey Great Again).