[Vm-dev] Regarding TestOSAPlugin & Applescript

Ken G. Brown kbrown at mac.com
Mon May 7 01:45:48 UTC 2007


I see, can understand the naming issues. Maybe at some opportune time when back compatibility is broken anyway.

I don't want to get into a big discussion, but I'm just expressing an opinion here. It seems to me that back compatibility is most often a big anchor on moving forward. Those that want/need back compatibility are always free to stay in the past with whatever version they last had. In the long term, if compromises are always made in the direction of back compatibility, I think that the overall quality of the system is of course, 'compromised'.

Similarly, if decisions are always made in the direction of 'the simplest thing that could possibly work', in the long run you end up with bunch of stuff that perhaps only 'simply' works. This 'simplest thing' idea is great for prototyping or testing out ideas, but one needs to always remember to go back and clean up after.

Perhaps a better rule of thumb is 'doing the best thing in the best possible way'. The semantics can be argued forever tho.

And since I seem to be on a roll here, if you always buy cheap tools, in the long run you end up surrounded with a bunch of cheap junk that when you really need to get a job done, the tool either breaks or does a crappy job.

And if you always patch things instead of repairing properly, pretty soon you are surrounded with patched stuff everywhere, all on the verge of failure.

Yeah, yeah, I know, need to define 'repair properly', 'best thing', 'best possible way', etc.
 
Maybe I should reconsider clicking send here! :)

Ken

>On 6-May-07, at 4:54 PM, Ken G. Brown wrote:
>
>>
>>On a slightly related topic, do you think it would be worthwhile going though the plugins and make the names more consistent with the convention? I'm not sure exactly all that is involved but perhaps some cleanup would improve things for the future?
>
>We considered doing this several years ago - probably when I first wrote VMMaker - but it would mean changing quite a few methods in the image and breaking backward compatability, so we decided against it. I do think it would be a good idea at some point but that whole 'making a new image with loads of stuff changed and to hell with back-compat' meme seems to make people scream in terror.
>
>>
>>I was rooting around everywhere learning where things happened and it being the first time through, I was initially confused by the following:
>>
>>internal plugin B3DEnginePlugin generated as Squeak3D
>>internal plugin BalloonEnginePlugin generated as B2DPlugin
>>internal plugin BitBltSimulation generated as BitBltPlugin
>>internal plugin DSAPlugin generated as DSAPrims
>>internal plugin DeflatePlugin generated as ZipPlugin
>>internal plugin FFIPlugin generated as SqueakFFIPrims
>>internal plugin KlattSynthesizerPlugin generated as Klatt
>>internal plugin LargeIntegersPlugin generated as LargeIntegers
>>
>>The rest seem to have matching names and folders everywhere.
>You'll find the name defaults to the same as the implementation class's name unless overridden by (I think) #pluginName. Best compromise we could come up with at the time.
>
>
>tim
>--
>tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>Strange OpCodes: FA: Failsafe Armed



More information about the Vm-dev mailing list