David P Grove wrote: > On VMFoo vs. NativeFoo vs. PlatformFoo, I really don't care. I only > observe that one person's VMFoo is another person's native/platfrom so > perhaps it makes sense to just pick one name (VM) and leave it. I suspect > you are unlikely to be able to "nicely" divide the classes along these > lines so why waste any intellectual effort (and silly flame wars) arguing > about whether something is a VMFoo vs a NativeFoo.
This was exactly my thinking originally, and why I was inquring to Etienne about what he really meant, i.e., what is his "dividing function", because to me there really is no such thing. However, after thinking about it I realized that he is right in a way. While in the grand scheme of things there I agree is no one true clear division between "VM" methods and "native" methods, in practice, by virtue of its implementation, Classpath has implicitly defined just such a dividing line. I.e., if Classpath supplies a native implementation of a method, then it's a "native" method.. if not, then its a "VM" method... at least within the context of Classpath itself. So if we belive Classpath being self-consistent is a good goal, then it does make some amount of sense that the naming scheme would be consistent with the VM/native split that it implicitly defines. NOW having said all this I should also say that it doesn't really matter to me either :-) I'm more curious in the underlying issues that motivate the discussion because they help me understand subtleties of VM design. E.g., Classpath has implicitly defined this line.. is that the best line? What line would you draw if you were starting over? (rhetorical questions, please don't answer on the list :-) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath