Hacking "method variables"

Frank Heckenbach ih8mj at fjf.gnu.de
Sun Jun 18 20:57:33 CEST 2006

Forwarded from marcov at stack.nl (Marco van de Voort):

In gmane.comp.compilers.gpc, you wrote:
>> Forwarded from marcov at stack.nl (Marco van de Voort):
>> A slight advantage of the delphi method is that it requires dirty syntax to
>> do dirty things. That could be seen as a deterrent.
> As a general principle, I agree -- though some (optional) warnings
> would also be fine. However, AIUI, what Markus want to do isn't
> actually dirty stuff, i.e. all type-safe.

One could argue that this leads to partial initialisation(method inited,
instantiation not). However that is just a detail.

I'd have doubts because I don't think it really is worth inventing new
syntax that is marginally cleaner (typesafe), since this form of usage is
probably rare, and usually limited to the innerworkings of frameworks

(at least that is the only place I have ever seen such code in Delphi, e.g.
central dispatch routines deep in the classes framework)

>> Not this moment. But IMHO it should, though we would probably call it a
>> "hint" (something that is not _always_ wrong).
> Doesn't this apply to most warnings?

No. E.g. portability warnings are not a problem if you are writing a
non-portable app. But the compiler doesn't know this intention. Solution,
put it on a different level.

Also compiletime warnings about possible range problems (e.g. assigning
integer to byte) can be very handy to track if you have problems, but
generate a lot of noise.

All old hat probably, since I assume GPC has a deep warning system?

So my remark was more a musing where I would put it in our three level
warning system (the three types have names; warnings, hints, notes). IIRC
the difference between them, is likeliness of being correct, and frequency,
but I noticed that the manual misses a formal description of these
levels, I'll make a note about that.

More information about the Gpc mailing list