Markus Gerwinski wrote:
I hope I correctly reproduced all of Frank's remarks. :-)
Unfortunately not. :-(
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.
Not "Direct use of object types as variables (without using a pointer)", but object assignments. Non-pointer objects have been working for a long time and there's nothing bad about them.
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.
GPC doesn't even accept this program (as you could have easily tried). The problems arise with polymorphism:
If the RHS is polymorphic, some fields may be cut in the assignment. To an OOP purist, this would be quite a horror, when considering objects as entities and not just a collection of fields.
If the LHS is polymorphic, things get even stranger. That's what the reference to fjf451h.pas was referring to. (See the comment there for details.)
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).
Yes (again: for object assignments).
The warning cannot be disabled, though, but Frank says it shouldn't, even if it could.
The warning *can* be disabled (`-Wno-object-assignment'), but you should know what you're doing when you disable it ...
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.
That's not quite what I said. In fact, such macros wouldn't be any good, since you could just rename the procedures instead. And I made several other suggestions of which the macro thing was just a final addition. (Yes, I'm quite angry. If I take the time trying to help with your problems, is it really demanding too much that you at least reproduce my suggestions correctly when I explicitly asked you to in the beginning?)
So again:
Eike Lange wrote:
is there a way to suppress this warning: optest.pas:53: warning: object type declared as function result type
There is no such warning if you use "pFoo":
...
If that is not what you want, could you give me some code to play with?
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.;-)
The first idea was to use another operator instead of `.' to get the evluation order right. But then it yields a results (even if dummy) which must be ignored some way (see the other thread) ...
Independent of the syntax, the above operator entails two object copies per invocation which is usually not good style, especially if the objects are larger. One of them could perhaps be avoided by using a reference parameter, but the return value still entails an assignment. Therefore it would be better to pass and return object pointers instead.
Markus' concern that the syntax would be cluttered by `^'s etc. is not really so bad since they're mostly if not all hidden in the procedure and operator, not in the code using it.
Another idea was using `with' in combination with some suitable routines. That's where the macro came in (so the starting macro could expand to something like `with CreateEnvironment^ do begin', and the ending macro to `; CloseEnvironent end' or so). This also has the advantage that the environment can contain regular statements, not encapsulated in subroutines and passed as procedure pointers.
The goal (also not mentioned here I think) was to create a `try ... except' environment as found in other languages. The macros could help to get the syntax rather close, until such a thing will be built into GPC ...
(I may have forgotten some more ideas. I hadn't taken notes, assuming you had.)
Frank