Etienne Gagnon wrote: > > I'm not sure what the precise naming semantics are, maybe it would make > > sense to have interface that must be implemented by a VM into VM* > > classes, and classes that can be implemented natively in a different > > fashion in their own Platform* or Native* namespace. I'd prefer Native* > > since it 'sounds right' when the distinction is made about native methods. > > Dalibor, you understood exactly what I meant: there is a difference between > a native interface and a VM interface. VM* classes should be reserved for > such things that only a VM can implement (e.g. low-level primitive reflection > functionality). > > To classpath maintainers: If you want to separate all native calls to Native* > classes, I don't care, but please do not mix the VM* interface and the > Native* interface. They are semantically quite different things. I am > suprized that this is not plain obvious to some of you.
Hmm.. I agree that some native routines are more "VM oriented" (or whatever) than others, but I don't quite see an obvious criterion for distinguishing between the two. E.g., opening a file descriptor is a thing that "only a VM can implement" is it not? Moreover, all VM operations must be implemented via native methods, so at the least there is a confusion in the naming of things. Can you describe more explicitly how you would distinguish between "VM interfaces" and "native interfaces" (and perhaps suggest better names)? -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
