Daniel Stenning wrote:
All very good points - I would emphasise that for precompiled libraries I would want them to be in the relevant OS format - ie DLL , dylib etc. Do we really need a new precompiled library format specific to RB ?. The ability to create RB plugins, DLLs and dylibs would increast the range of projects for which RB could be used considerably.
Yes we do need an RB specific format! There are inputs and outputs for the compiler. You are thinking along the lines of outputs (DLL, dylib etc.). What is needed are "input" libraries. An input library for RB would contain all the necessary bits and pieces for it to be imported into the RB project. For source code libraries, the container would have the source code stored in it that the target project could read and compile as if it were a part of the target project. The compiled code would then reside in the target project. This has the disadvantage in that the library is compiled every time. The advantage of this is when the compiler is updated the code gets compiled with the new compiler. You also maintain a level of indirection that allows you to group the files together as one unit so you can use it many projects by using one external link in each project. For precompiled libraries there is no source code, but there is signature information that tells the compiler how access the methods and glue code that allows the compiler to link in the code. Also in this container would be the platform specific libraries that you are thinking of (DLL, dylib etc.) for each platform since RB is a cross-platform environment. Having these split out into separate libraries like DLL and dylib would make things unnecessarily confusing. On top of that RS may have there own proprietary way of storing object code, so we are just speculating at the implementation details. You want one container to contain all the different variants for each platform. Now having RB create "output" libraries such as DLL and dylib might be useful in the future, but this would fall under the "nice to have" category. Currently RB is not the most optimizing compiler in the world and there is still a long ways to go before it achieves that level of optimization. For the time being that kind of work is better suited to C/C++.
It seems to me that RS is slowly making RB version control friendly - but I think it would be a waste of RS resources to write in their own VC features. Far better to just add the ability to provide hooks for one of the existing VC systems.
I don't know how long you have been using RB, but RS already once attempted to roll their own version control system. I remember having discussions on this list and with Geoff about their previous version control system. And you are right to state it would be a waste of their time to write their own version control system. So they pulled their version control from RB and started working on a new direction. At that time I suggested that they create a version control system similar to CodeWarrior's where they provide the front end and an API that third party developers could hook into and bridge the gap between the source code control system and RB. But as time passed, something happened internally at RS and they decided to do this version file format. In my opinion, this was a mistake and a waste of resources on their part. They should have stuck with the original CodeWarrior like model. So unless RS has some plans to REALLY kick it up a notch, we are stuck with an inferior version control system. Now that they got UB support out of the way and the IDE is stable, they really need to concentrate on features that make sense and are not just band-aid features to just get by. RS is really hurting themselves in the corporate market because they are not properly interfacing with the development systems out there. Perhaps it is a lack of experience on there part in that they don't realize what developers need to interface with. We are at a critical juncture with RB in that they now have the opportunity to break out of the niche market they are in and really put to shame all other development systems. I have been developing software for twenty years and have always imagined a dream system for developing software and RB is the one system that comes closet to that dream. With a few well thought out features, RB could really kick butt in the market place. Unlike java which is more hype than substance, RB has real proven potential. Currently RB is like a three legged dog, it gets around just fine, but that fourth leg sure would be handy if you know what I mean. So RS, what is your vision for RB? Do you want to break into the corporate world? Any features you develop for corporate market are going to be like heaven to the individual developer like a proper interface to source code control systems. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
