Forwarded from marcov@stack.nl (Marco van de Voort):
In gmane.comp.compilers.gpc, you wrote:
Forwarded from marcov@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 anyway.
(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.
Frank Heckenbach wrote:
Forwarded from marcov@stack.nl (Marco van de Voort):
In gmane.comp.compilers.gpc, you wrote:
Forwarded from marcov@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.
You mean of the internal Delphi record? But he's not using it.
Otherwise, in the TP object model, and AFAIK also the Delphi one, there's only initialization of instances (VMT pointer and fields), not of methods. Virtual methods are dispatched via the VMT pointer of the instance, so they don't have to (and cannot) be initialized by themselves.
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 anyway.
I think it's really something different (method pointers bound or not bound to an instance). But I also still wonder if the usage isn't too rare to warranty new syntax ...
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.
As I said. -- These are things that can be wrong, but are not always wrong. Why do you say "no"? ;-)
Again, if it's always wrong, and the compiler can know this, it should be an error.
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.
I suppose you have options to suppress warnings at a given level. GPC doesn't have that, instead it has options to en-/disable specific warnings (and a few groups of related warnings). These options can be used as (local) compiler directives, so you can disable warnings in the source code (preferably after you've checked that they're harmless, and when there's no cleaner way available to avoid them).
Frank
-
Frank Heckenbach