propose to rename natPlainSocketImpl to natPosixPlainSocketImpl
Fri Feb 1 23:32:00 GMT 2002
>>>>> "Adam" == Adam Megacz <firstname.lastname@example.org> writes:
Adam> Okay, I've proposed the two simple extremes (group by
Adam> functionality, group by platform), and both have been
Adam> rejected. If we're going for a middle ground, I'll just start
Adam> submitting patches and let people comment on stuff on a case by
Adam> case basis; I guess my goal of having a simple, uniform naming
Adam> scheme for port-specific stuff is not going to happen.
I think what Bryce (apologies if I'm misrepresenting him) and I were
getting at was something like this:
* Have a separate (e.g.) natFile<Platform>.cc for each OS family.
So for instance we'd have one natFilePosix.cc for all Posixy
systems, and in that file we'd account for particular oddities using
#ifdef. There are several files for which we'd do this; I think
you've already listed them.
The rationale here is that putting all the code in a single file
results in a huge mess of #ifdef.
* Look in existing files for seemingly generic code which is really
platform-specific. Some is in prims.cc and some in natSystem.cc;
there might be a little more scattered about. For this code, define
a simple OS API and move the code behind it.
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.
With the above proposal, we'd have a small list of files you'd need to
rewrite for each new port. Since they'd all be named similarly, you
could construct a list using `find'. For clean platforms you'd have
the benefit of working using files without ugly #if code.
I'm not really sure what to do about the ConcreteProcess code. The
trend has been to move such code (non-public classes) out of java.lang
and into gnu.gcj (or gnu.java if it is shared with Classpath).
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.
What do you think of this?
More information about the Java