In the case of a B-Tree the data structures are the keys/offsets (and possibly values) that are stored in the tree and not the tree itself.
For instance most examples on the net just assume keys to be long numbers but that is obviously insufficient for an actual application. Keys could be 20-bit hashes, strings, floats, doubles etc. The same applies to a lesser degree to the offsets (at leaf node level) and any embedded values.
Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects.
In the case of a B-Tree the data structures are the keys/offsets (and possibly values) that are stored in the tree and not the tree itself.
I'm confused, you store values in the tree but in itself it is not a data structure?
Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects.
I see a B-tree as a data structure not an object per se, I still don't see how it would mean anything without its operations.
Let me try and give an example. Let's assume we are modelling a non-leaf node which contains long keys and long offsets. We can do it in any of the following ways:
In all of these cases, the data structure is different but the basic B-Tree algorithm remains the same. You can implement the algorithm once (using templates (C++), macros (C), or a weakly typed language (Lisp/Scheme)) and re-use it with any and all data structures that come up later.
No, they're duck-typed. Types are attached to values, not variables, and for example trying to eval (+ 1 "hi") will throw a proper type exception.
You usually don't have to declare types but for example in Common Lisp you can optionally declare types for better performance in speed-critical parts of the code.
I think you are both right. IMHO, a B-tree is a structure, but generally it's more of a meta structure. When you are doing something with a B-tree, you generally care about the contents of the tree, not the actual tree. The tree just happens to be the facility to efficiently manipulate the information that you really care about.
Also IMHO, code is data as well. So the definition of the b-tree operations (algorithms), the tree that they operate on, and the application data within the tree are all just data (some of them just happen to have a more direct effect on run time operations).
For instance most examples on the net just assume keys to be long numbers but that is obviously insufficient for an actual application. Keys could be 20-bit hashes, strings, floats, doubles etc. The same applies to a lesser degree to the offsets (at leaf node level) and any embedded values.
Plus it is interesting that you view a B-Tree as an object - when I think about it, I categorise it as an "algorithm" operating on various data objects.