I do not see how BTreePageOuter is used? Is that your own class? What does that have to do with BTree?
I wrote my own BTree, mainly as a learning exercise. I had a look at the other version, but it made my head hurt. Turns out mine is about 20% faster than the version on squeaksource for adds, and nearly twice as fast for deletes. I
Sounds cool, but IMHO correctness and customizability to different database layers is more important than speed.
Generally it is a bad idea to subclass collections. I am not sure, but
Is that a general smalltalk principle, or just in regards to Goods??
This is general to Smalltalk. Subclassing from concrete collections inherits you way too much behavior that exposes way too much of the internal structure. Subclassing introduces subtle bugs and hand hard to detect dependencies. For example, did you think of overriding #removeAllSuchThat: in your OrderedCollection subclass? If not, I bet that soon somebody starts to use it and completely breaks all constraints of a B-Tree.
- I am not aware that anybody has used GOODS in the past year on Pharo or even on a  Cog VM. So there might be (subtle) bugs. Do the tests pass?
Up until now. :) There were a couple of test failures 1.testFlushAllRemovesAllUnreferenced - this was failure 2.testTwoDifferentShapesInDatabase - this was error.
I haven't used GOODS for a long time, but it seems to me that fixing all tests is the first thing you would need to do. I doubt that any of you own code works reliably if there are things broken in the core code.
- GOODS loads things lazily. So it might be that when you look at things through reflection (like the inspector), they do not load properly. Also you need to make sure not to not access your objects with optimized messages like #== or #yourself, because these do not trigger the loading of the object.
Um, I'm not upto optimization tricks yet, so no. :)
This has nothing to do with *your* optimization tricks. These are optimization tricks that the VM and the compiler play on you. Below a list of potentially dangerous selectors that might not cause the GOODS proxy objects to load the object. You need to be aware of these details to be able to write code that works with proxy objects: ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue: and: or: whileFalse: whileTrue: whileFalse whileTrue to:do: to:by:do: caseOf: caseOf:otherwise: ifNil: ifNotNil: ifNil:ifNotNil: ifNotNil:ifNil: repeat + - < > <= >= = ~= * / \\ @ bitShift: // bitAnd: bitOr: at: at:put: size next nextPut: atEnd == class blockCopy: value value: do: new new: x y yourself Lukas -- Lukas Renggli www.lukas-renggli.ch