[fpc-devel] FPC implementation of attributes for language parts.

[Michael Van Canneyt]

On Wed, 13 Apr 2016, Maciej Izak wrote:

> Moved from: "Initialize/Finalize management operators and Default
> intrinsic". I'd like to keep Initialize/Finalize topic more clear ;P
>
> Small introduction:
>
> for selected language elements in Delphi is possible to use attributes. For
> example in Delphi we have:
>
>  TCustomAttribute = class(TObject)
>  end;
>  WeakAttribute = class(TCustomAttribute);
>  UnsafeAttribute = class(TCustomAttribute);
>  RefAttribute = class(TCustomAttribute);
>  VolatileAttribute = class(TCustomAttribute);
>
> which is used like this:
>
> procedure Foo([ref] const X: TFoo); // AFAIK FPC equivalent is procedure
> Foo(constref X: TFoo);
>
> or like this for TObject field for ref. count for ARC:
>
> [Volatile] FRefCount: Integer;

Sorry. This is simply very bad design.

1. We already have a syntax for this kind of thing, it is called modifiers.
    No need to introduce a second syntax. You just introduce extra modifiers.

2. You make the COMPILER dependent on USER-DEFINED classes.
    What kind of nonsense is that ?
    It is even worse than the enumerator syntax Borland/Embarcadero invented.

If the compiler needs to know about it and act on it (and it does for ARC), 
then it must be a keyword or modifier.

Attributes are meant for user-space information.

The compiler has no business with it, from the point of view of the compiler
the presence or non-presence of attributes is entirely irrelevant. It is
meant to be extracted easily by the user. No more, no less.

Attributes used like this are self-contained. You can use it or not, it
makes no difference to the compiler. This is an example of _good_ design.

If you use attributes to start controlling ARC or whatever other 
_language feature_, this is _bad_ design, because you link one 
feature to another, which simply is not related to it at all.


>
> To clarify: I am not a big fan of the attributes syntax. But...
>
> If attribute is used you already know that it has more "flag idea" (by
> analogy to RTTI attributes, anyway it does not have to be just like a
> flag), as in our example presented in "Initialize/Finalize management
> operators and Default intrinsic" topic - is more visible whole context.
> Introducing many new keyword is the waste and can collide with existing
> keywords.

Clearly, you are missing something very important: Modifiers are _not_ keywords.
You can add as much modifiers as you want.  They will never interfere with the syntax.
That is the whole point of modifiers ?!

Michael.