i think the difference is that c++ operator overloading changes the operator. instead of emiting an ADD-type instruction, anything could happen. using a file as a device doesn't change the file protocol between client and server; the same 9p messages apply, regardless of the server implementing the file.
trying to be parsimonious about semantics leads to strange places. to be silly about it, should we reserve "int" for purely abstract integers with no constraints. what about intgers on Zn? or scaled integers? intgers between a min and max? integers that are used a power of two? should we have different types of files for spreadsheets than wordprocessors at the file protocol/namespace level? unix said no. we have One True Namespace™. or in v7 everything was a file, mostly. plan 9 said "s:Namespace:& Type:" and btw, if you want the usual things to work, there are some conventions that need to be followed. - erik On Thu Jun 8 09:53:13 CDT 2006, [EMAIL PROTECTED] wrote: > > > > interfaces like those provided by plan 9 fileservers are much more > > compelling. > > /dev/draw seems to me much more object-oriented than anything i've seen in > > c++ or java. it's ironic that the oop crowd seems to be the biggest > > poo-pooers > > of plan 9. > > > > I know people who think files should be for files, and that's it. > That abstracting the filesystem to mean anything else is almost as bad > as overloading operators in C++. > > I can kind of understand the complaint. > > in C++ for example you've got things like > > C = A + B; > > If A and B are objects of classes, this could mean a lot of different > things as you must define operator + for that class. A and B don't > even have to be of the same classes, and the same goes for C. Without > knowing about the data types, it's not really possible to know all the > possible side effects, exceptions, allocations (needless copies that > might be immediately thrown out and how different compilers might > interpret those) etc for a single expression. In fact there are a lot > of different function calls and code paths that could imply. > > The same might be said (though I think with less confusion) when someone says: > > echo eject > /dev/<blah> > > could be confusing because the file interface and syntax by which we > operate on it is also overloaded.
