pyscripter 740 Posted February 22 The following will not compile (error: class property accessor can be a class field or a static class method) : TTest = class private class function GetName: string; virtual; abstract; public class property Name: string read GetName; end; whilst the following does: TTest = class private class function GetName: string; virtual; abstract; public property Name: string read GetName; end; My question is that since you can have virtual class methods, why not properties that behave accordingly? In SmallTalk, the first object oriented language, you have a distinction between: instance variables (aka properties) class variables (aka class properties - one per class including subclasses) class instance variables (one per class, subclasses can change the value) Share this post Link to post
Vincent Parrett 824 Posted February 22 Class property Getter/Setters must be static, however delphi doesn't allow virtual abstract static methods. I don't see a good reason for this, so it's likely technical or an oversight. 1 Share this post Link to post
Uwe Raabe 2129 Posted February 22 46 minutes ago, Vincent Parrett said: I don't see a good reason for this Static class methods miss the implicit Self parameter, which holds the current type called. They are quite similar to global procedures/functions and therefore they cannot be virtual - there is just no VMT available. It is the same reason why static class methods cannot call virtual methods. 2 1 Share this post Link to post
pyscripter 740 Posted February 23 (edited) @Uwe Raabe Sure but why can't you have a class property that has virtual class method accessor. It is just "syntactic sugar". You call the virtual class method to get the value. Edited February 23 by pyscripter Share this post Link to post
Uwe Raabe 2129 Posted February 23 The "why" is probably caused by a specific decision taken a long time ago. The people having taken it are most likely no longer at Embarcadero, so we might not even ask them about it.. Fortunately the "why" is almost irrelevant, as you can issue a feature request for a change. Share this post Link to post
pyscripter 740 Posted February 23 4 hours ago, Uwe Raabe said: Fortunately the "why" is almost irrelevant, as you can issue a feature request for a change. I was really asking whether you see any technical reason that I am missing. Because, otherwise it is such an obvious omission. Share this post Link to post
Uwe Raabe 2129 Posted February 23 While there might be a technical reason for this and it may as well be well thought through at that time, it doesn't hinder us to ask for a change. If that turns out to be impractical, needing too much effort or just impossible without breaking everything, we hopefully get a decent explanation about it. Share this post Link to post
pyscripter 740 Posted February 24 Issue submitted: https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-2959 1 Share this post Link to post
pyscripter 740 Posted February 25 The issue was closed within minutes... Explanation: Quote I assume this change would imply a fairly significant rework for the implementation of this feature in the compiler Share this post Link to post
Uwe Raabe 2129 Posted February 25 That doesn't surprise me. At least we've got some insights now. Share this post Link to post
Anders Melander 1949 Posted February 25 4 hours ago, Uwe Raabe said: At least we've got some insights now. Yes. We now know Marco can read the help. Beyond that I don't know what we learned. Maybe that they don't have any compiler engineers at hand since the product manager had to do first level support and guess about the work required. The issue was filed as a New Feature but treated as a Bug report. Not impressed. 1 Share this post Link to post
Stefan Glienke 2083 Posted February 26 It appears that Marco lacks the technical understanding to evaluate this issue. I left a comment. 2 4 Share this post Link to post