Virtual class methods and properties

[pyscripter 742]

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)

[Vincent Parrett 831]

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. 

 

[Uwe Raabe 2132]

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.

[pyscripter 742]

@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

[Uwe Raabe 2132]

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.

[pyscripter 742]

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.

[Uwe Raabe 2132]

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.

[pyscripter 742]

Issue submitted:

https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-2959

 

[pyscripter 742]

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

 

[Uwe Raabe 2132]

That doesn't surprise me. At least we've got some insights now.

[Anders Melander 1969]

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.

[Stefan Glienke 2128]

It appears that Marco lacks the technical understanding to evaluate this issue. I left a comment.