Packages, Automation and then some
Havent had much time to tinker with my pet pascal compiler, but I got in a couple of hours after work yesterday and today – and implemented support for source packages. The system is completely abstract so the IDE doesn’t really know “where” a unit is stored. When it needs a unit it simply uses a top-level api and ask for it, and the api takes care of locating it quickly.
Packages are normal zipfiles (same as java uses) with some clever serial-code management. When you start the IDE a splash screen displays the loading of packages and the files are hot-plugged into the file lookup system. So the IDE actually doesn’t know the difference between a normal folder, a zipfile or something lingering on the Internet. With one exception: if your zipfile is “sealed” then you wont be able to view the units. This is a good thing for component vendors that want to ship their products without revealing their secrets. It also makes resource handling much easier (images, music, style sheets, binary data).
Also took the time to write a clever unit scanning class for dwscript. All classes and generics everywhere. Now also enumerates interfaces and class inheritance (yey!). Since DWS is so fast these days there really is no need for threading. This will by far be the best IDE for DWScript development in history.
Abstract storage is also in place, at least the basic class hierarchy. Meaning: the IDE has no idea where files are stored. It simply pertains to a storage class which takes care of the rest. Which means you don’t have to keep two buffers in memory at the same time. Much faster and requires far less code than other approaches.
And yes. DWS is bolted into the system from scratch, so once the IDE api is complete it will be fully scriptable and invokable via DWScript. Utilities etc. can be written in DWScript itself and registered in the Tools menu.