Re: Windows stuff...
Juergen Luethje wrote:
>
> Tommy Carlier wrote:
>
> > Patrick Barnes wrote:
> >> To program in windows using only the standard libraries is very time
> >> consuming and annoying.
> >> Excellent work has been done in 3rd party projects like win32lib and
> >> w32engine.
> >> Some people find one or both of these restrictive, and so go off and
> >> use a different system...
> >>
> >> This means that programmers are using different windows libraries to
> >> write their own code, and to convert a library to use a different
> >> windows library is difficult, if not impossible.
> >>
> >> What do you think about collaborating to produce a common core to
> >> these windowing systems, that can be extended to produce a library
> >> that caters to different needs?
> >>
> >> For a start, one include file should have every windows API constant,
> >> and be compatible across the board. Perhaps it should be included in
> >> the euphoria installer as a standard include.
> >
> > I agree that there is a need for a core library, but that library
> > should be very limited. The API constants are necessary.
>
> Yes, the API constants are necessary, and I actually think that they
> should ship with the official Euphoria distribution.
Which API constants? Microsoft's Windows API? Linux KDE? Linix GNOME?
wx? OpenGL? DirectX? All of them? Why is RDS responsible for distributing
these and for keeping up to date with the likes of Microsoft and
Linux publishers?
Remember that Euphoria is both a programming langugage - a tool.
RDS publishes one specific instance of a Euphoria interpreter. In future,
there could be alternative publishers of Euphoria interpreters and compilers.
Would also expect that all Euphoria publishers have to supply
all 3rd-party constants too?
> This is normal for other languages such as C, Delphi, PowerBASIC
> etc. for years now.
If I recall correctly, Kernighan and Ritchie did not distrubute Windows
API constants 
>
> > 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.
>
> I certainly don't have as much programming knowledge as you, but anyway,
> I'd like to say here: KISS. I think it should be a plain include file.
> It works fine e.g. for the languages mentioned above, why shouldn't it
> be good for Euphoria?
Also, C, Delphi, PowerBASIC, etc are all compilers. In these languages,
using the constants is a compile-time effort and never at run-time.
With Euphoria, every time you run a program, the 'constants' must be
executed. Thus having ALL the constants run for every Windows program
written in Euphoria might be a penalty for some.
Thus it might be a better strategy to have related constants together
in separate include files. That way, you execute the ones you are
actually using.
> > Different libraries use different functions to define structures, and
> > to load DLLs and functions.
>
> Yes, but that must not be accepted as a given prerequisite, because it's
> part of the problem! And that's why it is highest time to create some
> standards in this regard. When all libraries use these standards, then
> this issue will dissapear.
If only it was this simple. Why are there different approaches to these
'common' processes? One answer may be that they are trying to achieve
different things. For example, in win32lib, we could have just used the
'native' methods for defining API functions: open_dll(), define_c_func().
But I chose not to because I thought it would be faster to only define
these if they were actually used in your program. Thus win32lib does not
define any API routines if you are not using them. This makes the code
in the library more complex, but has little impact for users of the
library. Same with RAM structures. I could have just used simple offset
values and then made users workout when to use poke(), poke4(), peek,
peek4u(), peek4s(), etc.. as appropriate. David Cuny chose not to do it
that way. He wanted to make it easy to use RAM structures and to reduce
errors in defining such in the library. But this comes with a run-time
cost. Other libraries have decided that the run-time cost is not worth it.
There are different ways of achieving these things because there are
different design goals. One size does not fit all.
> In order to 'define' a standard, it's not
> necessary to write large and complicated documents.
No, the hard part is getting the agreed to.
> RDS just has to include the regarding code in the official Euphoria
> distribution. This will automatically be a 'de-facto standard' like it's
> already with the library routines, that currently ship with Euphoria.
So are we happy to live with the "benevolent dictator" model?
> For instance, if there would be built-in library routines for handling
> C-like structures, all those different self-written routines would
> become superfluous (provided, the built-in routines are good), and
> sooner or later would disappear from the "market".
Tell me again why C++, Delphi, D, PowerBASIC, Java, et al were invented?
Because you can't please all the people all the time. Which "pretty print"
do you use?
> So the various different approaches, and different libraries are a
> direct consequence of the lack of a standard in that regard. And (at
> least currently, since OpenEU isn't available yet) no one else than RDS
> can introduce an Euphoria standard, that will be accepted and used by
> many people.
RDS has given us EDS. It works as advertized. Yet people want SQL type
databases.
> When there are suggestions for improvement to Euphoria, Rob often writes
> something like: You can do it yourself. While it's true, this is not the
> point. Of course, we can write this or that code snippet ourselfes, but
> we can't define standards ourselfes. That's actually up to RDS.
Anyone can write standards. But try getting people to follow them. Have you
any idea how many RS-232 'standards' are out there in the real world?
People will only follow an RDS published standard if they like it and if it
suits them.
> > If the API definitions are available as a
> > database, anyone could generate Euphoria-code from it.
>
> Sorry, but I actually can't hear this "Anyone can do it her/himself."
> argument anymore. 'Standardization' is the name of the game. 
But why isn't what Tommy suggested a possible standard?
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
