Hi folks,
Frank Heckenbach frank@g-n-u.de asked me to post a comment on my own posting for him, since his inflamed wrist prevents him from mailing himself.
I wrote:
is there a way to suppress this warning: optest.pas:53: warning: object type declared as function result type
Direct use of object types as variables (without using a pointer) has only recently been implemented due to Borland compatibility; and Frank is not really happy with it, since it enables the developer to do some really dirty programming. E.g. when assigning an object's values to another object, you usually should implement a "copy" or "clone" method for that sake. When dealing directly with object variables, you cannot always be sure what really happens. E.g. the following code snippet
type
foo = object x: integer; end (* foo *);
bar = object y: integer; end (* bar *);
var f: foo; b: bar;
... b := f; ...
would leave the field b.y uninitialized.
However, it doesn't cause any compiler-internal problems (that is, unless there's a bug in the compiler -- which is quite possible for this feature, since it is rarely used, thus it is barely tested). The warning cannot be disabled, though, but Frank says it shouldn't, even if it could.
If you want to deal with this feature in more detail, take a look at the file fjf451h.pas in the test directory of the latest gpc source distribution.
Turned out, the idea I had in mind collided with Pascal syntax at another point, so I'm skipping it. (I was trying to build a self-defined pseudo-environment using tricky operators and a function call, and I wanted to avoid superfluous "^" symbols, so I wanted to return a tFoo instead of a pFoo. Something like:
type tMyEnvironment = object public Procedure endOfEnvironment; end;
Operator someOperator ( me: tMyEnvironment; p: pProcedure ): tMyEnvironment;
...
begin ... myEnvironment someOperator @someAction ... someOperator @someAction .endOfEnvironment; ... end;
But it didn't work anyway, since the parser applies the .endOfMyEnvironment to the last @someAction instead of the whole statement. I should have thought to an end before posting to the list.;-)
[Frank again:] This way it cannot work, that's right, since the "." operation is always resolved first. However, you could be able to build up a pseudo-environment using macros. -- Something like
{$define myEnvironment someProcedureCallToStartTheEnvironmentBehaviour} {$define endMyEnvironment someProcedureCallToEndTheEnvironmentBehaviour}
... myEnvironment someCommand ... someCommand endMyEnvironment;
could work.
I hope I correctly reproduced all of Frank's remarks. :-)
Yours,
Markus