Re: GO engine interface

[Henrik Rydberg <rydberg@xxxxxxxxxxxxxx>]

Hi again, here are some more thoughts on the subject.

P.J.Leonard wrote:
> ...
> OK so are you suggesting a wrapper that could be used to insulate the
> application from any classes that they do not like ? The wrapper would
> use the standard types (int char etc) ?
> ...

Yes and No, if I read you right. The basic interface would use (int char
etc),
in all cases where it is just as well, as for instance in move().

> This would be good for decoupling but bad for effeciency.

With inlining code, it should not affect efficiency at all.
As long as we are talking about functions that really only take the 
basic data types. For instance, a function

  void Move(int x,int y);

could be overloaded (inherited if member) as taking the argument
Point2D, say, by the inline function

  inline void Move(const Point2D& pt) {
    <parent>::Move(pt.x,pt.y);
  }

assuming something like: struct Point2D { int x,int y; }. As far as I
know,
a decent compiler interprets this as more or less the same code.

> I think it would be nice if a set of basic GO types could be agreed
> between programmers

I agree, but only for more complex types that cannot be treated in
the above fashion. It's hard to know where to draw the line, though. :)

> ...
> there could be standard library for all to use. Legacy code would need
> to provide an interface to these types but new code could be based on the
> predefined types and develop faster because there will be a base of code 
> that operates and the predefined types.
> ...

You do have a point here, and I definetely agree with you that with such
a
codebase, things would develop quicker. But as I see it, there are two
ways 
to go: either one starts with something very simple, and let the
community
develop the standard as it grows, or one could try to do it correctly
from 
the beginning. I think all experience points at doing the former, since
even
the core code probably will be rewritten several times anyway, before
everyone
is pleased.

> Also if you go for using simple types you lose the posibility of
> passing references to structures to comunicate. This of course will slow
> things down considerably
> ...

Yes. No point in using a language inefficiently. But what the data
for such issues should look like is likely to be argued about, and that
is
why we need a coordinator, I think.

Henrik

-- 
Henrik Rydberg (http://fy.chalmers.se/~rydberg),
Department of Applied Physics, Chalmers University of Technology.