Re: [MiNT] WCOWORK implementation : conclusions.

[George Nakos <gnakos@yahoo.com>]

First of all, let me stress that I mainly code in asm
for 680x0 processors and a bit of GFA BASIC, have
coded a bit of GEM in the past (using GFA), and will
probably won't code in GEM in the near future. But, as
I've been a subscriber on the list for some time now,
and this subject has caught my attention for some time
now, I'd like to make some points if I may.

--- Arnaud BERCEGEAY <arnaud.bercegeay@free.fr> wrote:

> About the library concept.
> 
> I've heard that such approach is a hack, a bad
> design, something idiot...  
> What is idiot in the story : to help other
> developpers by providing a set  
> of lib so that they don't have to re-invent the
> wheel for each  
> developpement ?

Well, I probably don't have any rights to tell what
I'm about to say (and it's a bit off-topic :), but
here goes(!): I always write my programs from scratch,
as I feel that my previous were crap, and that most
stuff could be done in a better (cleaner, faster) way.
That's the main reason I don't re-use any of my code
or libraries (I don't even do that on my job which is
about C coding, with a very few exceptions).

> 
> Of course, this library will use AES functions
> because it runs over the  
> AES layer.... and of course it's not portable to
> other platform (linux,  
> macos...) because it requiers the AES to run, but
> what's the problem ?  
> oh... it also requiers a VDI for the output; it's
> even less portable, but  
> it's just perfect for GEM developpers :)

Let me ask this: if Atari had included a "don't do it
like this" in their developers docs, would you do it
anyway? Because as it seems to me only Ozk is meddling
with XaAES at this time, and he suggests not following
that path (this is far from saying that Ozk=Atari
though! But he just wants to set some standards as to
organise his code path).

> About the simplification for programmers.
> 
> I see two kinds of GEM developers.
> 
> 1. old scholl developers that re-invent the wheel on
> each development.  
> When such developper want to develop a new
> application, then he copy 'n  
> past another application and change what need to be
> changed to make the  
> new application.

Being a sort of guy that re-invents the wheel each
time, I can guarantee that I don't do that sort of
thing. I only use a tiny setup/restore code fragment,
and the rest is completely new work.

> 
> 2. intelligent/lazy developpers that re-use already
> proven-to-work code,  
> so that they don't have to redevelop anything for a
> new application : the  
> .C files developped contains only the code specific
> to this application.  
> All "common" stuff already developped are provided
> by libraries (windom,  
> woutlib, gslib...).
> 
> The 2nd type of developpers has a lot of advantages
> :
> - if a bug is fixed in the management of evnts
> (windom lib for example),  
> then all the application will benefit this fix
> - the developper has just to focus on code specific
> to the application,  
> nothing more.
> - if a new feature appears in the AES (mouse wheel,
> WM_REPOSED...), then  
> this could be included in windom and then all windom
> applications will  
> benefit.
> - if the application contains an usual type of
> window, if the developper  
> is cool then he could split its code to isolate the
> management of that  
> window, and make a lib so that all other lazy
> developpers may benefit from  
> its work in their applications.

So let me ask a simple question (which I,
surprisingly, have never seen asked): What if a
library like windom introduces a hard-to-debug bug
that breaks all applications that use it, even older
ones? And, on top of that, you find that you can't
switch back to older versions of windom because of new
features that only the current build has?

> For WCOWORK feature, there will be no advantage at
> all for developpers  
> (only some hours of work for the library developper
> and some possible  
> incompatibilities problem already explained).

What might seem a waste of time and resources could
become essential in the future. See my comments below.

> 
> To end, let's talk about WCOWORK.
> 
> At first, i though it was just an half step. Now i'm
> sure it's a really  
> bad hack.
> 

I can't comment on that, since I don't code in GEM,
but I can say this: It could be currently a hack
because (as Ozk pointed out so many times), it's still
in development. And if people start negative comments
before it even evolves then it will be abandoned and
will be forever a hack. For that matter, if Ozk loses
patience and motivation from all this talk, he can
very easily abandon XaAES development. Nobody's
forcing him (or paying hime) anyways, and development
will be ground to a halt until someone else as skilled
as Ozk picks up the source tree, learns it by heart
and then debugs starts adding new features (as I'm
very sure Ozk has done).

And I really can't see all this hostility towards his
new features. If it doesn't break anything currently
(as he's said so many times), why don't we all give
him some grace period to evolve the idea some more?
I'm positive it will work out in the end.

> 
> For theme change, the only constraint for the
> application is to not store  
> any AES data. It's independant of the WCOWORK
> mode... and windom  
> applications do not store AES data, so windom
> applications are already  
> ready for theme change for ages !!!
>

Well, for all I know this could just be luck! Had Ozk
suggested an implementation for this that didn't work
with windom, I suppose this thread would be even
bigger :)

> Conclusion
> 
> Now, i'm sure WCOWORK mode (as it is implemented
> now) won't help windom user, 

Well, this statement just makes me think that the
whole fuss is being done over windom. So, is one
library worth the possible freezing of XaAES
development?

> and won't give any further liberty to the AES
> (i really hoped this  
> was the case)... so i will never use it. I don't
> want to spend hours  
> coding new stuff just for the fun to introduce
> incompatibilities. As a  
> consequence, none of the libraries will support this
> feature, and none of  
> windom application will support this feature. If an
> application wants to  
> use some of the libs, then the application shall not
> enable that mode.

Nobody is forcing you to use it, as I've gathered. And
it wouldn't be wise to implement something that it's
in-development, right?

> best regards,
> Arnaud.
> 

Well, that's about it. Hope I didn't step on too many
toes, or gotten out of line too much, but I just had
to write my thoughts.

Regards, and happy holidays to everyone,

George Nakos (GGN/KUA)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com