I always liked the way one can specify constants by platform in RB via the IDE. Your example of
MyClass.macDoThis > MyClass.winDoThis > MyClass.linDoThis illustrates another situation where this could apply in future. Seems to me we need are always going to need both options: A) to be able to create and view/filter out platform/configuration based method "variants" as a "whole" like in your example. B) the ability to just use the ONE method but switch code in and out via macro branches. In both cases the IDE could help in readibility/maintainability by using some kinnd of visual filtering mechanism. On a separate topic, I am very interested in your pre-emptive thread plugin. The only worry I have is that I am very wary of introducing yet another 3rd party library into my projects. Reason ? We all know of the huge support issus and risks of becoming dependent on support and maintenance from a host of library vendors - issues of obsolescence and bug fix delays spring to mind. So have you considered licensing your software to a "bigger" player like MonkeyBread or Einhugur? I think a lot of us who are producing commercial software are probably happier dealing with just one or two major library vendors instead a host of little ones. I think this sort of thing is why many decide just to "roll their own" solutions - even if it means "reinventing the wheel". Just something to think about - since your plugin sounds like something many of us might be interested in now that multiprocessing is going "mainstream"... of course many of us are also hoping that RS will eventually build in this sort of functionality into RB anyway... ;) On 30/11/06 14:06, "Daniel L. Taylor" <[EMAIL PROTECTED]> wrote: >> I would prefer to see some sort of IDE functionality that some how hid >> platform specific code, according to some selector, rather than #if tests >> throughout the code, or macro functions. I would say though that I would >> welcome the ability to set any function/method as #inline - which could be >> argued to be just a type safe form of macro.... >> >> One would then be able to switch between different "views" dependent on >> platform or just a name. so there could be a "view" for debug, beta and >> release mode, as well as view layers for specific platforms. Have to admit >> I >> don't have any firm picture of how exactly this would be implemented, but >> then that's down to will and brain brawn. > > At least for platforms, I "emulate" this by having separate methods for each > platform where needed. > > For example, let's say that MyClass.DoThis has to be platform specific > because it calls OS APIs. MyClass.DoThis will branch to three separate > methods: > MyClass.macDoThis > MyClass.winDoThis > MyClass.linDoThis > > It may sound like overkill, and I don't do it for simple methods, but with > complex methods it's nice to just see the platform code you're concerned > about. > > I would welcome the ability to choose views based on #if statements. > > Daniel L. Taylor > Taylor Design > Computer Consulting & Software Development > [EMAIL PROTECTED] > www.taylor-design.com > > _______________________________________________ > 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> > _______________________________________________ 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>
