OpenEuphoria

Re: Windows stuff...

• Posted by Matt Lewis <matthewwalkerlewis at yahoo.com> Sep 13, 2004
• 434 views

Tommy Carlier wrote:
> Patrick Barnes wrote:
>
> I agree that there is a need for a core library, but that library should be
> very limited.
> The API constants are necessary. But I think that it would be useful, if
> instead of
> a Euphoria-library, these definitions (constants, functions, structures) would
> be available
> as a database. Different libraries use different functions to define
> structures, and
> to load DLLs and functions. If the API definitions are available as a
> database, anyone
> could generate Euphoria-code from it.

It's not too difficult to do this, but it's only moderately useful.  Only
a handful of people develop GUI libararies (compared with the number of
people who use them).  Where I think it's really useful is for cross 
platform development, and also for modularizing things.  Take a look at
the developer's package for wxEuphoria:

http://wxeuphoria.sourceforge.net/download.htm
 
> > From that, common procedures could be agreed upon. Some things are
> > common across all flavours of windows library - opening a dialog box
> > and getting a result, the concept of an event handler, low-level
> > routines like timers etc....
> 
> I don't totally agree with this statement: if you force such common
> procedures, people
> will be limited to write libraries that all look the same. What if one wants
> to write
> a library that doesn't use an event-system, or if it uses an event-system that
> looks
> totally different than the common event-system? If such a common event-system
> would
> exist, how would it look? I have to say: the Win32Lib event-system is easy to
> use and
> pretty advanced, but what's the point of writing a (revolutionary?) new
> library if
> you're going to stick with old habits.

The problem you'll run into is that you're building on top of the same
base (the Win32 API) as everyone else.  There's only so much you can do
to make it work differently, before you're adding huge amounts of 
complexity and overhead to your library.  Then you've got something that
is probably a lot slower, and is definitely more difficult to develop and
maintain, because you not only have to deal with the idiosyncracies of
MS, but of your own code.
 
> > The internals of the procedures and functions as implemented by
> > windows library designers do not have to be the same, but their
> > abstract behaviour should be the same, or similar enough to make
> > compatibility much easier.
> 
> I disagree: the abstract behaviour of a Windows library should not be the same
> as any
> other Windows library. That's why I'm starting the new library: to make a
> library that
> doesn't suffer from backward compatibility (yet), and that implements some new
> features
> and ideas that haven't been implemented before.
> Compatibility can be a good thing, but is also very limiting.

As far as re-engineering the way the library hangs together, I agree.  
There were some choices made in the earlier days of Win32Lib that have 
made extensibility more difficult than it could have been. Admittedly,
some of this can be traced to me (I think I've learned a bit on the 
subject, and tend to make better choices these days).

Matt Lewis