Hello Björnke von Gierke, David, and y'all, > From: Björnke von Gierke <b...@mac.com> > Subject: Re: IDE Interoperability
See above for context. > The main issue is about how to decide > what is a component and what isn't. The OPERATIVE word here is "DECIDE". There is no BEST-answer to this. It depends on what we want to do, how we want to do it, who we are doing it for, etc. > Should a "script editor" be one component, or a dozen? The gist of "components" versus monolithic systems (aka All-in-One) is that componennts can be substituted for other ones, without adversely affecting the operation of the system, as-long-as the component BEHAVES as it should. Moreover the "separation of concerns" makes developing and maintaining the system (system's components) easier. The downside of modularization is, of course, the increased complexity and overhead of handling multiple entities versus just one. You don't want to have too-many, nor too-little. Btw, OOP design/programming deals with this issue incessantly. > For example a script editor contains stuff > for debugging, auto-completion (sometimes), > colorisation, undo handling, etc. My take-on-this is the following. Any substantive feature that people may want to program differently should be component-ized so that these people can replace the feature with their own version of it as-long-as it conforms the component's interface (protocols, API, etc). Debugging is a prime candidate for being component-ized. Colorization is a FAIR candidate for being component-ized, given the wide variety of prefs in terms of WHAT should be colorized, which colors should be used (some people are blind to some colors), etc. The same goes for "auto-completion" because coding-standards vary from person-to-person. Yet let's face it: most people will USE the defaults. As for UNDO it's too-fundamental to be componentized ... and, moreover, way-too-technical; and, more-to-the-point, NOT something that people will need to customize. > It's probably best to just start somewhere... Quite right. I'm looking forward to see what you guys come up with. :-) Alain _______________________________________________ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
