1. RE: win32lib & global functions
Derek Parnell wrote:
>
>
> ----- Original Message -----
> From: "Andy Serpa" <ac at onehorseshy.com>
> To: "EUforum" <EUforum at topica.com>
> 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. 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?
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. And for those (probably few) people it would
break code for, simply provide a separate include file with "aliases" to
the new function names. I don't see how it is win32lib's place to
provide global, general non-win32 related functions that it happens to
use internally. Why use names that are very likely to conflict with
another library's functions when you can use names that very likely
NEVER will? 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.)
Use non-generic names, or don't make the functions global. Isn't that a
sound and reasonable principle?
2. RE: win32lib & global functions
Wolf wrote:
>
>
> > 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?
> So, why not rename all *your* custom functions accordingly:
> ... as_trim(), as_compress(), etc, ... or whatever ...
> ... or are you suggesting _everyone_else_ should re-write all their
> existing code?
Are people including win32lib.e so they can use abs() or trim()? I
thought it was a Windows library. It is better programming practice to
use non-generic names, and any transition needed does not have to be
painful. A simple, optional alias file using the original names will do
if people are using these functions in their own code and don't want to
update...
3. RE: win32lib & global functions
I'm talking about names -- my functions may not even do the same thing
that yours do. Plus your way still leads to broken code, which is why I
brought this up in the first place. I downloaded the win32lib beta, and
it broke some of my already-working win32lib programs because there were
now namespace conflicts with functions I already had in other libraries.
And given the attitude that it is ok to "globalize" whatever functions
you desire that win32lib might become DEPENDENT ON but aren't functions
which are not part of win32lib's purpose, you can expect to break more
code in the future as you add more arbitrary (& undocumented) functions.
I'm not trying to get you to force anything on anybody, I'm trying to
get you to STOP forcing something on everybody. Your way leads to
broken code and conflicts that can be avoided. My way leads to no
broken code (in theory) and no conflicts. Isn't that better? (I say in
theory because yes, it will lead to some broken code if you underwent
the transition I am suggesting, but it wouldn't have if you hadn't used
the generic names in the first place or hadn't made them global. But
sometimes you have to pay a price to fix a mistake.)
I don't know why everyone is getting so huffy -- I was just suggesting a
sensible plan so no one will have to deal with conflicts and broken
code! I don't understand why you would argue in favor of such things
when it can be easily avoided...
4. RE: win32lib & global functions
Pete Lomax wrote:
>
>
> On Fri, 3 Oct 2003 19:34:22 +0000, Andy Serpa <ac at onehorseshy.com>
> wrote:
>
> >I don't know why everyone is getting so huffy
>
> OK, I'm fairly calm.
>
> Not that I can see why you think this is a good idea, you understand.
>
> What are you proposing here?
>
> No *more* generic names?
>
> Revert generic name usage in win32lib back to the status quo as of say
> June 2003, and not use any more? When did this problem really kick in?
>
> Remove *all* generic name usage in win32lib and suffer the widespread
> consequences? Particularly existing user contribs no longer working.
>
> You'll get "huffy" responses when your proposal is widely believed to
> be likely to cause far more problems than it solves.
>
I'm only talking about functions that are NOT in win32lib proper --
functions that have nothing to do with creating & maintainting windows,
controls, listboxes, etc. If it comes with a generic string library,
that's fine, it just shouldn't be "mandatorily global", that's all,
because as it adds generic functions, THAT BREAKS CODE TOO. If a user
wants to use those functions, all it would take is an extra "include"
line -- no big deal. (No "widespread consequences".) And I'm certainly
hoping that the library will not continue to add more & more
non-optional generic functions, yes, because those will break even more
code. I get the feeling that the only reason these libraries are there
at all is because win32lib.e uses them itself, not because the intention
was there to provide all sorts of general libraries.
I'm merely asking for a little forethought. There must be at least 3
libraries in the archive with a "compress" function and at least 5 with
a "parse" function, all of which do different things, for instance.
There are enough conflicts as it is without adding more just to be
stubborn.
There is one good way that RDS could fix this problem by enhancing the
namespace feature or include system so either a file can be included so
it is only available to the file that includes it (denoted by an extra
keyword on the include line), or allowing namespace hierarchies whereby
we can specify "default" libraries so the interpreter will use those
default functions without causing a conflict and without having to use
namespace qualifiers if we want to use the default version of a
function.
Anyway, if you want win32lib to be a big, bloated, 800-pound gorilla
that gets to sit where ever it wants, then I can't stop you, but I
thought Derek believed in "making life easier for the coder". Instead I
get responses like Rob is often accused of, "I don't really want to
change that... just because I don't. Suck it up."
