[Is there any method to either comment on or re-open resolved isses? It is very frustrating to be forced to switch comminication channel]

I think this issue is resolved prematurely.
First, I do not see a reason why normal property can not be implemented by static field.
Second, even is such a reason is provided, compiler should error out instead of generating bogus code
(Optimal solution would be to issue a warning or hint and generate correct code).
Either way, "no change required" is IMHO wrong resolution.

Maybe you should reread Jonas' comment? Apparently something in trunk has been changed regarding this already.

Florian Klaempfl wrote

Am 01.09.2011 17:48, schrieb Alexander Klenin: > [Is there any method to either comment on or re-open resolved isses? > It is very frustrating to be forced to switch comminication channel]

Only the submitter and people with "developer" access (or above) can do that, afaik.

Trunk indeed gives an error if you don't use a class property:

Free Pascal Compiler version 2.7.1 [2011/08/18] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Darwin for i386
Compiling tt.pp
tt.pp(2,2) Warning: Illegal compiler directive "$STATIC" tt.pp(23,50) Error: Illegal symbol for property access tt.pp(24,48) Error: Illegal symbol for property access tt.pp(60) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted

Jonas

Jonas' comment is:

static/class fields can only be read by class properties. Those are not yet supported by FPC 2.4.4, but they are in svn trunk.

I did not deduct from this that the error is now issued instead of wrong code. Testing indicates that it is indeed the case (the error message could be somewhat more descriptive,
but no big deal), so sorry for that.
This leaves the first point, however. Why is it prohibited at all?

Alexander Klenin wrote

This leaves the first point, however. Why is it prohibited at all?

I think because class properties have several limitations that normal properties do not have: http://docwiki.embarcadero.com/RADStudio/en/Properties#Class_Properties

Jonas

That is quite understandable. The question is why FPC limits *normal* properties by disallowing them to be implemented via static fields?

Because those limitations of class properties stem from the fact that those things (stored, default value, published) don't make sense in combination with class methods/fields. It would of course be possible to add special checking code to make sure that they are not used with regular properties if either the setter or the getter maps to a static class methods/fields (that's another thing: a property that mixes & matches like that should probably also be forbidden, so that's another special case that would have to be checked), but overall I think the current way is much cleaner and easier to implement/maintain. And it's Delphi-compatible to boot.

Jonas