Project V: Separation of Concerns
Saturday, 17. November 2007, 06:37:38
Yesterday, I updated the way certain sets are used internally for the type system. When a programmer adds an extra feature, there are two things that can happen. You add it and simply write up the code that needs it. This is only possible when adding to an object where you have access to its internals and where there's already a compound object existing that lets you do this. For example, adding a feature to an integer isn't going to work. You need to wrap it in another object and this is in fact the second thing that can happen. This is the annoying part.
For anyone wondering why I didn't use inheritance or whatever else, it's because I'm not extending anything. This is supposed to be the first version. It should be built correctly. And actually, this brings me to a more important point. Even if it isn't the first version, someone is going to have to maintain this internal code. No matter how much you try to encapsulate and hide data, someone has to know how those internals work. Eventually, someone is going to have to make changes.
Encapsulation is fine for USING the object, but it's not of much use aside from that. Certainly not for maintenance. So if there's a way to make internal changes easier, I think we should take another look at that. With Project V, I like the fact that not only can you change the insides, but you can have tools that understand the insides for you and even update it for you. With text based languages, you cannot really alter certain parts and have it displayed. The preprocessor is one tool, but that's for the compiler and not for the developer to see the results. Some IDE's do support class viewers but usually virtual functions are not merged with base class functions. If you do have it, it's nice, but not something that really matters in the grand scheme of things.
For text based code, you'd have to be able to subclass a function and change only parts of its insides. But most languages don't even allow you to do that with regular objects. You can only add members and functions. Let's say that you can do this. What then? How do you view it? You'd need an IDE to merge these changes together. And that's exactly what I've already done. The code to handle this is complete, so when I get to writing the IDE, all it needs to do is display the results.
As with my initial change of the way certain sets work, it's not just a matter of updating the data structure, but also the code that works on these data structures. Luckily, the IDE will also let you apply changes to data and the code that operates on it by having two versions of the data. Before and after. Then you link the parts from the before version to the parts in the after version and all the internals will update automatically. So if you have a unique object that needs to become compound, you simply link the unique object from the before version to its after representation inside the newly built compound structure. Apply the changes and the internal components will then update so that they still access the same data. You can drag and drop items between versions to make things easier.
I think being able to manipulate the 'things' that operate on our data is very important for programmers. It may not be necessary at runtime at all. But the reality is that humans are the ones making the design changes. As far as the actual implementations are concerned, the computer should be able to provide WAY more help than present day tools allow. I hope to keep providing these kinds of features in the future.
I'm still resolving a few little issues with building networks and then I'll just have the runtime engine to build.
