On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
On 7 October 2011 16:18, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
On 7 October 2011 01:39, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
On 6 October 2011 14:11, David T. Lewis lewis@mail.msen.com wrote:
I need to ensure that OSPP runs on trunk as well as oscog branches, which means that updates to all those branches would be best. But I suspect it may be possible to adopt a strategy of loading with ioLoadFunction, and if this fails, try a direct reference to the global variable (though I don't know if Carbon will allow this?).
Why? Why keeping workarounds?
Because for OSProcessPlugin I choose to maintain a certain level of backward compatibity and support for as many different VM projects as possible.
You lost me here. VM is evolving, things keep changing. Can you tell me any of the reason for keeping a freshly-built plugin to be compatible with 10-years old VMs? One could always use older version(s) of plugin which works with that VMs.. so, what is the problem?
Can you explain me , what is the benefits from staying compatible with dusty systems which, most probably, are used by 1% of users (if any)?
IMO, the purpose of plugin subsystem should be to serve as a way to customize the VM(s) for various kinds of distributions, but not as a way to ensure that something which was working 10 years ago, will keep working today without any changes.
It's about modularity. I maintain the three plugins for OSProcess as separate packages independent of any version of VMMaker. As with any such problem, maintaining the integrity os interfaces is the key to success.
I also care about the people who might use these packages, and often I do not even know who they are. If someone in Japan or China or a researcher at a university wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages to work without problems.
I also am lazy. I find that a little time and effort making sure the interfaces work saves a lot of my time later on. If I don't break something, I don't have to waste time later on explaining why it does not work. That is the same reason I write lots of tests and comments. It just saves a lot of time and excuses later on.
That is the approach I have taken, and it has worked well for me so far.
Dave