1. Re: Coming real soon!
OK, I can't really resist this one (and I'm a little behind in my reading...)
----- Original Message -----
From: francis at gmx.co.uk
>Has this comment has been totally misconstrued? When compared to other
languages,
>or specifically their Win32 capabilities, I think Euphoria currently has set a
very ad-hoc
>precedent. To cut the shit, the API is effectively a backbone segment of every
Win32
>language; this is indisputable. And you cannot statically link functions with
>Euphoria, only dynamically; so although this is not really the issue it
effectively means
>every program must include the API definition before it can do anything else.
What
>Euphoria needs is a base API library, from which every other windows library
is built apon.
>From the base comes protocol. I agree these problems are not specifically
Euphoria
>Language issues but software implentation issues. But comeon...
I'm not sure how statically linking things would change anything. Whether it's
done statically or dynamically, you'd have to include something somehow. Why
would it matter if the lib you used does things dynamically vs statically? Is
it a bad thing to include the API definition? How could you get around this
(other than making that junk a part of the base language--which will never
happen in the official version)?
I'd be interested to hear some more details about what sort of a base API lib
people would like. I'm assuming you'd want more than simply define_c_func's
and a list of constants, but maybe that's all you'd want. Either way, there's
an awful lot of stuff involved when you say 'Win32 API.'
>Although WIN32Lib is a seperate issue, it is an example of a very different
>(high level) protocol by which to communicate with the API. But how about
>a bit of creative engineering? With a Win32 base library covering (hopefully
the
>entire) API, Win32Lib could just include this before declaring its own
routines
>for (in my opinion) superior engineered code. Right now anyone who wants to
>get lower than Win32Lib has to wade through API definitions and tedious
copy/paste
>activities. I know, I have half the damn API plastered accross my hard drive
which
>I add to as needed. Although it is beside to point to argue libraries are NOT
part
>of the Euphoria Language, API protocol is usually semi-DEFINED in other
>langauges before you actually "include libraries". Yes, ok its more complex
than
>that; but in currently in Euphoria its 20x more complex than that. Does
everyone
>who wants to step ahead into the more complex and faster waters beyond
Win32lib
>have to spend hours upon hours manually creating the masterpiece of API
definition?
Actually, Win32Lib has been slowly encompassing more and more of the API as
time goes on. When I started extending the lib, it was a lot less complex than
it is now (although less useful, IMHO). Over the last year or so, the lib has
become more complex, but I think that Derek's work on making it easily
extendible will really pay off.
I'm not sure where the 20x complexity factor comes from. The most difficult
part (of implementation) seems to be getting structures correct (this has been
talked about around here, and many agree that it would be a nice enhancement to
make Eu play nicely with others). But I don't think that's where you're going
here. Take win32lib, for example. Yes, many of the calls seem a lot more
complex than perhaps they seem from browsing API docs. But the reason for this
is that there are several API calls wrapped into one Eu function, since often
the API calls are fairly low level (as you've alluded above).
>Still, besides how far off the point this thread is going to be argued, who
can criticise
>Bernie here for what he's doing? Who can possibly argue that Euphoria(Win32)
>does not need this library? Hello?
I don't think anyone really criticized Bernie. He puts out some interesting
work, but we still haven't seen this lib, so, officially, the jury is out on
the ultimate usefulness of it.
=====
Matt Lewis
http://www14.brinkster.com/matthewlewis
