Re: propose to rename natPlainSocketImpl to natPosixPlainSocketImpl

[Adam Megacz <gcj at lists dot megacz dot com>]

Tom Tromey <tromey@redhat.com> writes:
>   The rationale here is that putting all the code in a single file
>   results in a huge mess of #ifdef.

Yes, I now agree that one-file-per-class (containing code for every
platform) is bad because of the nightmare if #ifdef's.

> One question is, what's our goal?  I think the goal is to have a
> system which is relatively easy to understand both for maintenance and
> for new ports.  Right now there is stuff all over.  You have to know
> to dig through natSystem.cc to add weird things for a new port.  You
> probably wonder "what is posix.cc and do I need one?", or "should this
> function go in posix.cc, or just inline in natFile.cc?".  Etc.

Exactly. I'd like to keep the porting procedure simple to encourage
people (and myself) to port gcj widely; the really hard work has
already been for us by the people who write gcc backends.

Ideally, I'd like it to be something as simple as "copy newplatform.cc
to <your-platform>.cc, fill in the blank functions, and add a case
statement to configure.in, recompile, and go". Obviously there will
always be wrinkles, but it would be nice if this was the case. This
wouldn't require any #ifdef goo.

> Another approach would be to define a more complete OS API and then
> have a single (e.g.) natFile.cc which used the abstract API.  I think
> this would be more work, and perhaps harder to maintain, but I don't
> have any real objection to it.

I like this, and I think the API could be something as simple as the
set of native methods in File.java. You just have to implement each of
them in <your-platform>.cc. No extra effort specifying an API; it's
implicitly contained in File.java.

This is what I meant by the "other extreme" -- one C++ file per
platform instead of one C++ file per class.

  - a