> Moreover, if the sensible use cases for locking are few and far > between, then I'm still inclined to leave it out since you can add the > locking semantics at a different level. Are you sure about that? Without the locking, only non-resizable objects would be able to implement the protocol. So any higher level locking would have to be implemented on top of the old, non-safe version. Then you'd have to make sure that all parts of your application accessed the object through the extra layer. The "safe" part would be lost. > Your use of the word *no* is different than mine. :-) I could > similarly claim that the segment count puts no burden on > implementations that don't need it. I think I may have been replying to something other than what was said. But what I said is still true -- it imposes no extra burden on *implementers* of the interface which don't use the extra feature. I acknowledge that it complicates things slightly for *users* of the interface, but not as much as the seg count stuff does (there's no need for any testing or exception raising). > I believe it will be a no-op in enough places that extension writers > will do it wrong without even knowing. Well, there's not much that can be done about extension writers who fail to read the documentation, or wilfully ignore it. > Which exception? Would you introduce a standard exception that should > be raised when the user tries to do an operation that currently isn't > allowed because the buffer is locked? Maybe. It doesn't matter. The important thing is that the interpeter does not crash. > I still believe the locking can be added on top of the simpler > interface as needed. But it can't, since as I pointed out above, resizable objects won't be able to provide the simpler interface! Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4