[MiNT] FW: WCOWORK vs WINDOM for components

[Lonny Pursell <atari@bright.net>]

on 7/23/2005 1:02 AM, evan@coolrunningconcepts.com wrote:

> Quoting Lonny Pursell <atari@bright.net>:
> 
>> This is a very simple concept.  If you suspect any one of your imported
>> modules cannot deal with WCO, then by all means do not turn the WCO mode on.
>> I have to question the validity of that question even.  If you are making a
>> program and you don't fully know what all the individual parts are capable
>> of or doing, hmm should you be coding in the first place?
> 
> This is not a good design.   Thats not how safe modular programming
> works.  The
> whole point is that you shouldn't know or care the implementation details
> within the library.  You just use the functions and API it provides.
> 
> Why should it always come back to not turning on WCOWORK.  If someone wants to
> use it, and it can be done safely why not make it work?

Because there are no libs that require or use WCO to date, thus you are in
effect talking about old libs.   As I said if you want to use it you will
have to be darn sure all your components can deal with it.  It's new.

Even if you changed the way it works, and converted it all to new API calls.
Same problem.  Someone could just as easily make a lib that required the new
API calls and ignores the old calls, or vise versa.  Then you are back to
square one, not knowing what works with what.

This is an endless loop.
 
>> It's my understanding that those calls are there for extreme reasons.  Like
>> if someone still wanted to force the windows out x/y to an even pixel
>> coordinate.  Yes they seem to defeat the purpose and if someone is going to
>> code in that manner I would suggest not turning on the WCO mode in the first
>> place.  You are only going to fully benefit from WCO if you stick to working
>> exclusively with WORK area coordinates.
> 
> Again, I don't understand the all or nothing approach and the purpose of
> defeating modular programming.  Perhaps if you could explain what benefit will
> be lost and what features I gain that will not possible if both APIs are
> available I will better understand.

I have tried.  Not getting anywhere.  I would suggest at this point you do
one of 3 things.

1) Stop complaining about it, since that route generally don't work in the
end, especially if the main gripe is simply "This is not a good design"
That does not exactly clarify anything for Ozk.

2) Present some VERY detailed alternative with some example code, API calls,
docs etc.  Pretty much the only way you are going to effectively change
minds.

3) Take over dev yourself.  Ultimately the best way to get your point
across.

-- 
Lonny Pursell    http://www.bright.net/~gfabasic/