Wind32Lib Suggestions (was RE:NO!!!!)
dcuny at LANSET.COM wrote:
> Chris Bensler wrote:
>
>
> > How about seperating [Win32Lib] into
> > seperate libs?
>
> I've been urging Derek to wait until Robert adds namespaces to Euphoria
> before restructuring the code. But it's not clear when that will happen.
Namespacing is definitely an issue with such a large library, but as
is.. it's virtually impossible for anyone to modify without having to
LEARN the entire inner workings of the lib.. To me this defeats the
purpose..
>
> > Who says I WANT to use listboxes, edit
> > controls.. groups, or even buttons for
> > that matter...
>
> Structuring the library so that it's better organized seems to me an
> excellent goal. Stucturing it so that you could leave out sections of
> the
> library seems laudable. Structuring it so you can leave out individual
> elements of the library - considering how interconnected they are -
> seems
> like overkill.
>
Granted, There are definitely alot of things that need to be implemented
together, but I don't think that they are ALL interconnected..
some things would certainly need need to be grouped together. And some
things would still have to be implemented in the Kernel lib..
I think if you create a kernel that includes only the basic controls..
you could implement pretty much everything else in other libs..
I'm not saying that each control should have it's own lib, but you could
implement basic controls in one library file, like CTRL3D.DLL
Things like dialog boxes in another, toolbar controls in another (I
think this is already done), picture controls in yet another.. etc,
etc...
> Compartmentalizing each control to stand alone would result in an even
> larger library, since large chunks of code would be duplicated between
> controls. Trying to eliminate this with inheritance would inflict OOP
> onto
> the library, carrying it's own overhead and additional complexity.
>
You mean standalone, such as still including the main win32lib engine,
or ALONE, as in, each control lib carries it's own engine to handle the
events and methods.. That's certainly not what I mean..
Sure it would be larger, but on the whole.. (I AM anyways) willing to
sacrifice some speed and size for the sake of ease of use.. even if it
means including OOP..
I also think that expandability is KEY functionality with an API such as
win32lib..
As a lot of people have said, win32lib is not designed for highspeed
apps anyways..
> > I think the size of the main lib can
> > be diminished to a tenth of it's
> > current size if you are able to
> > restructure it. maybe use OOP
>
> Adding an extra level of OOP to the library - especially considering
> that
> Euphoria doesn't support OOP - seems unnecessary to me. There are other
> ways
> to accomplish the same goal.
>
OOP was just a suggestion.. if there is a better way to do this, than by
all means.. How I understand it, this is the reason that OOP was
designed.
> > It shouldn't include any classes..
> > They should be seperate libs.. Just
> > like WINDOWS..
>
> I'm not sure what Windows you are referring to, but it's not the Win32
> API
> that I've come to know. The Win32 API is only loosely 'class'
> structured.
>
> > I hate to say they did something right,
> > but they didn't make billions for nothing..
>
> Maybe you are thinking of the MFC? Most people who work with GUI APIs
> pretty
> much agree that the Win32 API is a mess, compared to just about anything
> else.
>
Can't say I know what MFC is, but I'm basically saying that the win32lib
should be expandable.. how it is now, it surely is not.
If I wish to add anything to the lib, I need to learn how the whole
thing works.. in my mind if I will do that. I should just start from
scratch... Though I would definitely prefer not to..
I shouldn't have to know every datail about how all the controls
corelate.. that's what the lib is for..
I should just be able to code in my own controls using a defined
structure..
> > If I could simply write the class module
> > with the events, properties, and handlers
> > that I would need for my class alone, I
> > would at least try to do so..
>
> Take a look at Llama for an attempt to create a 'clean' set of OOP
> wrappers
> around the Win32 API. Since Euphoria doesn't support OOP, the
> implementation
> isn't all that simple, after all. Much of the code is a struggle to make
> the
> Win32 model fit the OOP model, and it's not a good fit.
>
> > To accomplish this, win32lib would definitely
> > need a lot of restructuring.. possibly even
> > re-writing the whole thing.. but to me this
> > should be priority #1..
>
> I don't see the library as being *that* terribly broken. It's certainly
> large, but considering the scope of the library, I don't think that's a
> valid complaint.
>
Not broken, just not modifiable, from a users point of view, I feel it's
virtually impossible to implement anything that I want to, without just
outright asking..
I would be more than glad to contribute my controls to the library, but
how it sits now.. that means handing out my own modified version of the
current win32lib. And the last thing we need is everyone and his cousin
contributing their own version of the API, just to accomodate one
control that they think is handy..
To each their own, some people choose to use graphic buttons, other
choose to use pushbuttons, I shouldn't have to have the routines for
both included in my lib that I have attached to my prog.. if I only use
one..
> Even if Win32Lib were terribly broken, I think the prudent thing to do
> would
> be to hold off and see how Robert plans on implementing namespaces.
>
This is definitely a concern and NEEDS to be rectified quickly..
On a side note.. I don't really think that EU's archive of libraries CAN
expand much further without constantly running into naming conflicts..
This means that the expansion of EU is nearly at a standstill, for the
sake of clashing the libs.. either tha, or there will be a lot of
modifications to standard libs in the futute to make use of varying
libraries.
Hmm.. Have much more to say, but I feel I'm out of my league and I don't
know how to explain myself well enough..
>From a user's perspective though, the library is overwhelming..
Docs just don't do it.. I need to see how things are implemented. Having
to look at that library is like trying to find a grain of salt on a
beach..
Chris
|
Not Categorized, Please Help
|
|
