propose to rename natPlainSocketImpl to natPosixPlainSocketImpl

Sat Feb 2 15:40:00 GMT 2002

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