TSimpleModel = class(TPersistent)
  protected
    class function GetResourceClient: IResourceClient; virtual;
    class property ResourceClient: IResourceClient read GetResourceClient;
  public
  end;

Trying to compile the above code i get the following error: Error: Illegal symbol for property access

Changing the GetResourceClient method from virtual to static works

Is this a bug or by design?

Luiz

By design.

Michael.

As Michael said this is by design. If you want to use a non-static class procedure you must not use "class property", but only "property" (yes, that works).

Regards,
Sven

So what's the special use of a *class* property? If it exists for Delphi compatibility only, why then is it handled differently from "property"?

DoDi

The reason is explained in the upcoming docs.

Namely: a static method cannot be overridden.
The class property is part of this particular class, and descendent classes should not be able to override it's behaviour.

Michael.

2014-02-27 5:25 GMT-03:00 Sven Barth :

Thanks.

Removing class before property compiles. But if i try to access the property using TSimpleModel.ResourceClient gives the following error:

Error: Only class methods, class properties and class variables can be referred with class references

Technically there's some obstacle to allow such construct? Or is as today only to be delphi compatible?

Luiz

Sure, but virtual methods (including class methods) can be overridden.

The class property is part of this particular class, and descendent classes should not be able to override it's behaviour.

A static class method can call another virtual class method, so this protection looks very artifical to me.

BTW Delphi XE allows to call a virtual class method, but when called from a static class method it calls it like a static method, overrides are simply ignored. Calling the same method directly honors overrides.

Also "self" is no more known inside class methods in XE. In D7 it was the class type instead of the instance pointer. Thus a too restrictive compiler, geared towards compatibilitiy with *new* Delphi versions, may break existing code.

DoDi

No, it cannot. Try it.
It was explained to me using this exact example.

so this protection looks very artifical to me.

Nevertheless, this is the reason.

Michael.

You have to declare an instance and then call its property. You don't have to instantiate the instance if the property maps to a class method.

Technically there's some obstacle to allow such construct?

Class properties should be accessible from within static class methods. Having them accessible depending on the getter/setter they use (static or not) would break orthogonality (the visibility/ usability must depend on the interface, not on the implementation of the interface).

Non-static class methods cannot be called from static class methods because you don't know the original class type that was used to call it (and hence this could have unexpected results).

Jonas

2014-02-27 12:35 GMT-03:00 Jonas Maebe :

Got it.

Thanks

Luiz

Hans-Peter Diettrich wrote

Also "self" is no more known inside class methods in XE. In D7 it was the class type instead of the instance pointer. Thus a too restrictive compiler, geared towards compatibilitiy with *new* Delphi versions, may break existing code.

Source please. This compiles and runs without problems in XE:

=== source begin ===

type
   TTest = class
     class procedure Test;
   end;
class procedure TTest.Test;
begin
   Writeln(Self.ClassName);
end;
begin
   TTest.Test;
   Readln;
end.

=== source end ===

=== output begin ===

TTest

=== output end ===

It would be very strange if Embarcadero would have changed that.

Regards,
Sven

Then I missed the "static;" directive in the posted example, added to the getter/setter methods. Delphi introduced that directive after D7, and I found no useful description for it yet. Now it looks to me as if we have to distinguish ordinary static (non-virtual) methods from explicit "static;" methods.

DoDi

As long as a method doesn't use Self, directly or implicitly, the absence of an object reference does not cause problems.

Class properties should be accessible from within static class methods. Having them accessible depending on the getter/setter they use (static or not) would break orthogonality (the visibility/usability must depend on the interface, not on the implementation of the interface).

This would mean that in legacy code the non-virtual methods have to be separated now, into non-virtual, static, class and static class methods, in order to keep the code compiling?

Non-static class methods cannot be called from static class methods because you don't know the original class type that was used to call it (and hence this could have unexpected results).

Does this mean that the new static class methods don't have an Self parameter?

DoDi

When you add "static;", as required for class property getters/setters, the following won't compile:

class procedure TTest.Test; begin Writeln(Self.ClassName); end;

So the lack of "Self" seems to apply to "static;" methods, not to "class" methods. I'll ask in an EMBT group for a description of "static;", the OH seems to reflect the C++ meaning only, without mentioning the impact on OPL classes.

DoDi

That's why I asked for source. The term "class methods" always implies "no static" while those with static are "static class methods".

A static class method is a method that is basically a normal global procedure/function that simply happens to be declared inside a class. They are even assignment compatible to normal procvars.

Regards,
Sven

Hans-Peter Diettrich wrote

So the lack of "Self" seems to apply to "static;" methods, not to "class" methods. I'll ask in an EMBT group for a description of "static;", the OH seems to reflect the C++ meaning only,

In ANSI C "static" with functions just means "unreachable from outside the current source file" (i.e. by the linker) (I always thought this is a silly name for that meaning.)

Is this different with C++ ?

-Michael

"class" methods. I'll ask in an EMBT group for a description of "static;", the OH seems to reflect the C++ meaning only,

In ANSI C "static" with functions just means "unreachable from outside

the current source file" (i.e. by the linker) (I always thought this is a silly name for that meaning.)

Is this different with C++ ?

In C++ classes you can have static methods that work like static class methods in FPC/Delphi (no "this", need to be called with TypeName::MethodName, can be used for function pointers).

Regards,
Sven

Yes. Some C keywords have multiple different meanings in C++, depending on where they occur in source code.

DoDi

I just came across the same issue and as well got the error "Only class methods, class properties and class variables can be referred with class references".

Hence I cant do "TmyClass.myProperty:=xyz;"
but I _can_ do "TmyClass.SetmyProperty(xyz);"
I in fact directly calling the "class" function that is denoted in the definition of the property.

Hence: I am allowed to use a class variable instead of a property, and I am allowed to call the setter class function, but I am not allowed to use the syntax candy provided by the property keyword.

In fact I don't see why this should make sense.

The error message suggest that it should be possible to define a "class property" similar to a class function. But this syntax seems to be illegal (says the appropriate error message).

-Michael

I found out that I need to add "static" to the "get" class procedure to allow it's usage in a "class property".

Sorry for the noise :-[

If fact I don't understand what the additional "static" is necessary. I was of the op pinion that class procedures are static, anyway.

Can somebody clarify ?

Thanks,
-Michael

A `Class Procedure/Function XXX;` has a hidden parameter that points to the classtype. A `Class Procedure/Function XXX; static;` doesn't have this hidden parameter.

Ewald wrote

A `Class Procedure/Function XXX;` has a hidden parameter that points to the classtype. A `Class Procedure/Function XXX; static;` doesn't have this hidden parameter.

I see.

The hidden parameter would be accessed as "Self" ?

Thanks for the explanation !

Now I came across a "class procedure xyz; virtual;" and was astonished that this does compile.

I suppose this means that the hidden parameter will point to the classtype of the child instead of the parent in a derived class.

correct ?

-Michael

Probably, I access it through `Classtype` (from TObject), as this gives me code that will still do the same thing if I remove the `Class` in front of the procedure/function.

It does here (writes DoIt; on stdout):

===
Program Test;
{$mode objfpc}{$H+}
Type
    TTestClass = Class
    Public
        Class Procedure DoIt; virtual;
    End;
Class Procedure TTestClass.DoIt;
Begin
    WriteLn('DoIt;');
End;
Begin
    TTestClass.DoIt;
End.
===

Or am I missing something?

I suppose this would work independently of virtual, as no "Self" is might be some work to do a test. It could e.g. use two siblings and detect if different classtype values are found in the two siblings.

-Michael

Here... happy now? ;)

=== code begin ===

program tclassvirtual;
{$mode objfpc}
type
   TBase = class
     class procedure Test; virtual;
   end;
   TSub1 = class(TBase)
     class procedure Test; override;
   end;
   TSub2 = class(TBase)
     class procedure Test; override;
   end;
   TBaseClass = class of TBase;
class procedure TBase.Test;
begin
   Writeln(Self.ClassName);
end;
class procedure TSub1.Test;
begin
   Writeln('TSub1');
   inherited;
end;
class procedure TSub2.Test;
begin
   Writeln('TSub2');
   inherited;
end;
var
   b: TBaseClass;
begin
   TBase.Test;
   TSub1.Test;
   TSub2.Test;
   b := TBase;
   b.Test;
   b := TSub1;
   b.Test;
   b := TSub2;
   b.Test;
end.

=== code end ===

=== output begin ===

TBase
TSub1
TSub1
TSub2
TSub2
TBase
TSub1
TSub1
TSub2
TSub2

=== output end ===

Regards,
Sven

Sven Barth wrote

Here... happy now? ;)

Very happy indeed :-) .

(Silly me did not remember the "ClassName" property. With same the test is as easy as you showed.)

Now thinking about why I had been confused is that obviously "self" of an instance _does_ determine the VMT of the class it is an instance of. That is why I erroneously assumed only an instance has a VMT. Now after learning that the VMT is provided already for the class itself seemingly as a static record, I wonder if the dynamic instance record has a just a pointer to the VMT of the class or if the classes VMT gets copied when creating an instance.

-Michael

AFAIK : Just a pointer to the correct VMT.

Michael.

On 05/26/2014 08:25 PM, Sven Barth wrote: [...]I wonder if the dynamic instance record has a just a pointer to the VMT of the class or if the classes VMT gets copied when creating an instance.

The VMT is part of the class. The class is shared by all instances.

Mattias