Forwarded from marcov@stack.nl (Marco van de Voort):
In gmane.comp.compilers.gpc, you wrote:
It works though with uninitialised objects too as long as you don't actually "use" (dereference) self:
I see. But I suppose Markus also wants to call the method via the procedural variable later and apply it to a certain object instance (selected at call time), something like (depending on the syntax chosen):
Not possible directly, however messing with the internals (via the tmethod record typecast) is "supported". IOW, people expect it to work on Delphi.
procedure test;
var localx : somemethodvar;
begin localx:=globalmethodvarref; // local copy, avoid global mod of complex constant. tmethod(localx).data:=otherinstance; // maybe typecast to pointer end;
the problem is of course that the assignment is not safe. However usually code that messes with instances of procvars is typically framework internal, and not in normal user code, so I don't have a particular problem with it. (at least not enough to invent new syntax)
A slight advantage of the delphi method is that it requires dirty syntax to do dirty things. That could be seen as a deterrent.
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).
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.
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
Frank Heckenbach 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.
Right. To be precise, I believe that something I'm already doing as a dirty hack might as well (or even better) be achieved in a type-safe way, and I would prefer to do so.
-
Frank Heckenbach -
Markus Gerwinski