Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Frank Heckenbach
Subject: Skipped: Object type as function
Date: 31 Dec 2003, 02:44:37
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
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).