Re: win32lib & global functions
----- Original Message -----
From: "Andy Serpa" <ac at onehorseshy.com>
To: "EUforum" <EUforum at topica.com>
Subject: RE: win32lib & global functions
>
>
> Derek Parnell wrote:
> >
> >
> > ----- Original Message -----
> > From: "Andy Serpa" <ac at onehorseshy.com>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Thursday, October 02, 2003 4:01 PM
> > Subject: win32lib & global functions
> >
> >
> > > Suggestion / nitpick:
> > >
> > > If you're going to include general functions (that are global) in
> > > win32lib, can you give them non-generic names?
> > >
> > > I only use win32lib in about 10% of my projects, so it is not like it's
> > > "standard" with everything I do. But I do have a personal "standard"
> > > library that contains neccessities like abs(), etc.
> > >
> > > However, since abs() is in win32lib, it causes all sorts of name-space
> > > conflicts. I used to rename the win32lib version of abs(), but got sick
> > >
> > > of doing that which each update, so I grudingly renamed my own version
> > > to just ab().
> > >
> > > Same thing with all the functions in tk_trim.e -- trim(), compress(),
> > > split(), etc. -- these are all functions I've already got that may or
> > > may not do the same thing as those versions. Win32lib is hogging all
> > > the good function names!
> > >
> > > Couldn't we call all these W32_trim(), W32_compress(), or some such
> > > thing?
> > >
> >
> > Sorry. But I'm not going to change the names I've been using. I am
> > however slowly changing the library to refer to these routines using a
> > namespace qualifier. Can the namespace functionality help you?
> >
> How? If a function is global, it's global and is going to interfere
> with my functions unless I use namespaces every time I want to use my
> own library.
Exactly. I have to, just as everyone else has to. Why are you so special?
>I might have a module, and now I've got to go thorough and
> add qualifiers to a bunch of functions just because I want to put a
> Windows interface on it?
Life's a bitch ain't it. I had to do the very same thing.
> What's the problem with using non-generic names in win32lib, even if
> that means changing existing names? It can be done in 5 minutes with a
> careful search-and-replace.
Firstly, the 'generic' routines you mention are not defined in win32lib, but in
libraries that contain generic routines that win32lib happens to use. Secondly,
if it's so easy to do, why not change your source code rather than me change my
generic libraries and stuff up who-knows-how-many other people.
>And for those (probably few) people it would
> break code for, simply provide a separate include file with "aliases" to
> the new function names.
Ummm, there are already in separate include files -- tk_maths.e and tk_trim.e.
Hey I know...why don't you NOT use your routines and use mine instead.
I don't really want to change my generic routine libraries to use obsure names
and THEN provide another library that maps the generic names back to the obscure
ones, just so somebody who wants to use my libraries with generic sounding names,
can. Sorry, but it ain't gonna happen.
> I don't see how it is win32lib's place to
> provide global, general non-win32 related functions that it happens to
> use internally.
Well, I repeat - these routines are NOT inside win32lib. The are defined in
libraries whose purpose is to contain generic routines. IF win32lib did use these
libraries, I would either have to bring the routines inside win32lib and all
other libraries that use them, or use somebody else's libraries. In other words,
win32lib needs to use abs() and trim() and a few others just as your code needs
to use these generic functions. So who's library should I use, Andy?
> Why use names that are very likely to conflict with
> another library's functions when you can use names that very likely
> NEVER will?
And the same applies to you. Why are you trying to use names that I've used - go
and get your own 
> I downloaded the win32lib beta, and there are even more
> conflicts than with the last version because win32lib.e is now directly
> dependent on tk_trim.e and I think it even has a new function or two.
> (For instance, I don't remember lookup() before, which is a new
> conflict.)
It is not dependent on 'tk_trim.e' in the sense that it can use any library that
contains trim(), split(), and lookup() functions. I just need to change the line
...
include tk_trim.e as strlib
to
include andy_serpas_wonder_library.e as strlib
for example.
> Use non-generic names, or don't make the functions global. Isn't that a
> sound and reasonable principle?
No it is not. I'm using generic functions. Win32lib is including libraries that
contain the generic functions I need. Because these generic functions are in
libraries they need to be global - sorry, but just deal with it. You have at
least four options...
a) Use namespaces in your code to resolve ambiguities.
b) Change your names for these routines.
c) change my names for these routines.
d) Use my routines and don't use yours.
A MUCH MUCH better solution would be for RDS to take on the support of these
common generic routines and so everyone could be working from ONE official
library set. Saves us all re-inventing the wheel so frequently.
In summary, I'm not changing my code.
--
Derek
|
Not Categorized, Please Help
|
|
