tsdnz wrote:
SpyderTL wrote:
https://www.youtube.com/watch?v=f-KMbNpJ2Jk
Nice video. Makes it easier to see what you are trying to do.
I guess everything is an object with a meta header with properties etc?
Yep.
Brendan wrote:
Conceptually, an object is "code + data". Are you storing an object ("code + data") as a single thing on disk?
All objects have data located in one location, and metadata located in another location. (.NET combines these into a single location, and stores the metadata right before the object data, which I may decide to do at some point..) The metadata has a pointer to the actual data, and a pointer to a class object. The class object metadata has a pointer to the data (which is filled with code and more metadata describing the methods and properties), and a pointer to a base class type object that acts as the base type for all classes. And that object has a base type of Object, which is another class.
Brendan wrote:
Often in practice an "object" isn't actually a true object because code is separated from data (the object's code is a "class" shared by all objects of a specific type). In that case; what is the difference between storing the class' code on disk (as an executable file) and storing each object's data on disk separately (as a data file)? How is this different to a traditional file system?
It's not terribly different, but the biggest difference would be the metadata, and the complete discarding of the "file" paradigm. As I've mentioned before, the File/Folder terminology makes sense in some cases, but in other cases, it really makes it difficult for the user and the application developer. The best example I can think of is Music. I've got thousands of songs on my PC, and I have spent countless hours organizing them into a folder structure that makes sense to me. But as soon as I run an application to play that music, it has its own idea how things should be organized, and I have to prevent it from moving things around. Also, if my daughter wants to use the same PC, but wants the same songs organized differently, then the file system is completely useless.
So, I'm shooting for something not quite like a traditional file system and not quite like a traditional database. The plan, for now, is to store everything on disk as an Object of some sort, and then add additional Indexes (which are just objects) that will allow you to find objects of a specific type, or that have a specific property value, like where the song artist is equal to "The Eagles".
Most operating systems have built this sort of functionality on top of their file systems, and most applications have built additional functionality to make this all possible. I'm just trying to cut out all of those layers, and build all of that functionality directly into the OS and the storage structures, so that all of this information and functionality is available immediately at boot time from the command line.
Brendan wrote:
For both of these cases ("true objects" and "just glorified files"); what happens when the object is modified (e.g. a "setter" method is used) when the object is on disk?
Still working out the details, but most likely modifying a property on an object (either in memory or on disk) will involve simply changing the value, externally. But internally, it would involve asking the OS for a "Writer" object for that property, and then calling .Write(newValue) on whatever it returns. For objects in memory, you would get a memory writer pointing directly to the memory location, and for objects on disk, you would get (for lack of a better term at the moment) a file system writer, pointing directly to the offset of that property on disk.
Of course, a lot of things have to fall into place for all of this to work properly, but it all works great in my head...
Properties that contain references to other objects is going to be particularly tricky, since the value will be different in memory than it would be on disk, so that will probably involve finding (or creating) a corresponding object on disk, and using a reference to that object, instead of the original object. I may ultimately need to assign each object a GUID in order to keep track of object instances that are located in memory and on disk at the same time.
EDIT: I uploaded a fresh set of bootable images to CodePlex. If you want to check it out, just click the link in my signature.