Hi Francesco, << Carl is AmigaOS' main designer, and AmigaOS is heavly based on "dynamic linked library", and none has encountered trouble with them. M$ is another thing! >>
Yes, it's not the concept of a DLL that I don't like, but how distribution is handled (or allowed), what regression testing is done for compatibility, etc. Another big distinction is that of libraries that are shared by many apps, as well as the OS, versus each app (or suite of apps, etc.) having their own version of a library that affects only them. << Amiga's libraries adopt this trick: if version 1.0 has these procedure: a, b, c The next library version MUST have old a, b, c procedure and add newest ones. A, b, c may be remapped on newst ones, but their entry point must be not removed, M$ doesn't adopt this trick ;) >> With COM you can define the interface and then ensure that the original interface is always supported in future versions through typelib versioning. This, in itself, isn't a perfect solution. I built a set of DLLs for a client who then modified them as time went on. Occasionally they would see a problem and attempt to solve it by turning off compatibility checking (this is in VB) which, of course, only caused many more problems as the ripple effect kicked in and more pieces had to be re-built to match the new interface IDs being generated. DLLs aren't the problem of course. People are. :) I *love* reusable libraries of code! I couldn't live without them. The question is, how to make it work? Because of the way REBOL works, we're probably going to be seeing apps that are built of many small pieces which may change dynamically. Whether the concept of Web Services takes off or not, the world is different now. With REBOL, it's about communication (messaging). We don't have to use components and libraries as we have, historically, with other langugages. We need a good model that is simple, flexible, and robust. Lots of details to consider on that front. In any case, RT seems to have a plan. They released /Base and Carl said they want to know what we think, so let's keep thinking and telling them. He also said another tool would be forthcoming to help with including the pieces they took out, so I think they have something in mind about how to handle this. What do *I* want as a developer? I want to be able to send out a single EXE, that isn't dependent on anything that might be changed for the OS or another app. External pieces I ship should not be used by anyone else, so I can handle them however I want. If I break my own app, that's my fault. If I deploy a script, either it's targeted at REBOL developers, sysadmins, etc. who know how this stuff works, or it's for users. If it's for users, there needs to be a single interpreter/runtime that is used for everything (IMHO). E.g. under Windows, .r files will be associated with rebol.exe and that version of rebol needs to be able to run every script they might get. This doesn't fit very well with the current model though. Keep brainstorming! --Gregg > What I hope doesn't happen is for REBOL to become like some other > languages that are really only good for programmers because it just > requires too much effort to set them up, use them, and learn about how > things work. Modularized Rebol will be good even for rookie ;) Regards -- "Where did you get all those facts!?!" -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
