Hi,

The getter/setter of a class-property must be "static" (Delphi compatible).
If I understand "static" correctly, then "static" simply omits passing the class as parameter. So a static class procedure is just a dumber version of a normal class procedure.

What is the advantage of using "static" for class property accessors? Aka: Why did Delphi choose static here?

Mattias

2017-02-07 12:10 GMT+01:00 Mattias Gaertner :

Generally "static" means no hidden parameter "self". "static" for methods is used for methods designed for callbacks from external API.

We have 3 possibilities:

===code begin===
type
  TFooClass = class of TFoo;
  TFoo = class
    function A: Int32; // self as instance
    class function B: Int32; // self as meta class of TFoo
    class function C: Int32; static; // no self
    property D: Int32 read A;
    property E: Int32 read B;
    class property F: Int32 read C;
===code end===

"class property" has two advantages. First: you can use "static" methods for properties and second: will work for improper implemented code ;) (which is maybe disadvantage?):

TFoo($1).F;
TFooClass($1).F;

2017-02-07 12:10 GMT+01:00 Mattias Gaertner : [...] Generally "static" means no hidden parameter "self". "static" for methods is used for methods designed for callbacks from external API.

That's an advantage of static methods.
But how is that related to class properties?
How can you use class properties with "methods designed for callbacks from external API"?

Sorry, I don't get it.
Why is using a static method as accessor an advantage?

I don't see why these calls require static instead of normal.

Mattias

2017-02-07 13:11 GMT+01:00 Mattias Gaertner :

Is not related. AFAIK "class property" exist for complexity of language (otherwise usage of "static" methods would be impossible for "property" syntax).

Sorry, I don't get it. Why is using a static method as accessor an advantage?

You can use Get/Set pair of static methods in "property" form. Might be more handy.

In other scenario (for normal "property") this call will raise AV.

btw. "class property" is probably slightly faster ;) because don't pass "self" parameter.

Why is that "more handy"? "static" does not have a Self. That is less handy, isn't it?

I can't follow you here. Are we still talking about why Delphi choose static instead of normal?

btw. "class property" is probably slightly faster ;) because don't pass "self" parameter.

True.
OTOH you loose some possibilities.

Mattias

In other words, there is no real reason why the method must be static.

Michael.

2017-02-07 13:51 GMT+01:00 Mattias Gaertner :

Why is that "more handy"? "static" does not have a Self. That is less handy, isn't it?

by "handy" I mean usage of "class properties" instead of "static methods".

I can't follow you here. Are we still talking about why Delphi choose static instead of normal?

"class property" is used for code where class instance (nor assign to meta class) is not needed. Some variance/idea of singleton pattern. TFoo might be used as namespace:

===code begin===
var
  Foo: TFooClass; // or Foo: TFoo
begin
  WriteLn(Foo.F);
end;
===code end===

for regular "property" with "class methods" you need something like this:

===code begin===
var
  Foo: TFooClass;
begin
  Foo := TFoo;
  WriteLn(Foo.E);
end;
===code end===

and for normal property:

===code begin===
var
  Foo: TFoo;
begin
  Foo := TFoo.Create;
  WriteLn(Foo.D);
end;
===code end===

True. OTOH you loose some possibilities.

True.

Couldn't that simply be....

  Writeln(TFoo.F);

???

I never understood Object Pascal's class methods/properties either? Unlike Java, not everything needs to be in a class. We are allowed to have procedures or functions, and global in Object Pascal we could simply have a unit called FooStuff where everything related to Foo is defined, then have a global function F() and then use it as follows...

  Writeln(F);

Regards,
Graeme

[...] Couldn't that simply be.... Writeln(TFoo.F);

Yes.

Class methods can be overridden.

Mattias

2017-02-07 14:35 GMT+01:00 Mattias Gaertner :

not static. btw. class property is not my idea :P.

Don't forget that you can use property as array and is possible to use index keyword.

type
  TFoo = class
    class function F(i: integer): byte; static;
    class property P1: byte index 10 read F;
    class property P2[idx: integer]: byte read F;
  end;

Mattias Gaertner wrote

Class methods can be overridden.

But then you would have to define a new type first. In that case you can simply have a instance variable too. Personally, it just doesn't make much sense to me in Object Pascal.

But thanks for clarifying the difference.

Regards,
Graeme

Am 07.02.2017 14:31 schrieb "Graeme Geldenhuys" <

It allows for grouping. This way one can directly see (by using the completion window or by peeking at the declaration oneself) that there is a routine F() that belongs somehow to TFoo. If you put that into a separate unit however then it isn't clear by itself that the stuff relates to TFoo. In the end it's a question of taste. I personally like class methods and class properties.
Oh and don't forget that non-static class methods can be virtual (sometimes I really miss that in C++).

Regards,
Sven

[...] Oh and don't forget that non-static class methods can be virtual (sometimes I really miss that in C++).

In FPC static class methods can be virtual as well.

Mattias

2017-02-07 19:49 GMT+01:00 Mattias Gaertner :

In FPC static class methods can be virtual as well.

So we have bug...

Indeed...

Regards,
Sven

A useful bug.

Mattias

Class properties has apperared together with class constants and class variables (which are static by their nature). They were introduced (as I understand) to give access to private/protected static elements.

2017-02-07 23:17 GMT-03:00 Paul Ishenin :

For the record, there was a discussion about the topic years ago:

Luiz