Hacking "method variables"

Frank Heckenbach ih8mj at fjf.gnu.de
Tue Jun 13 13:32:12 CEST 2006

> 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.

> > Of course, that can be a problem -- as always if not carefully used.
> > BTW, do you warn if taking the address (@) of a normal (non-object)
> > variable on the stack?
> 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? E.g., comparing floating point
numbers with = or <> is often wrong (due to inexactness), but not
always (if you know what values they can have). And, of course, most
dirty stuff can be right or wrong, and the compiler will never know

If the compiler can see that something is always wrong, it's usually
better made an error, such as never assigning a function result
(which is an error according to ISO even). (Even though it's not
strictly always wrong, e.g. if you always leave the function with
goto, Halt, etc., but then it's at least pointless to declare it as
a function.)


Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8

More information about the Gpc mailing list