1. 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?
2. Re: win32lib & global functions
----- 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?
--
Derek
3. Re: win32lib & global functions
> 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?
4. Re: win32lib & global functions
On Fri, 3 Oct 2003 13:52:06 +0000, Andy Serpa <ac at onehorseshy.com>
wrote:
>
>
>Wolf wrote:
>>=20
>>=20
>> > 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()?
No, but people including win32lib are using abs() and trim().
>I thought it was a Windows library.
Yes...
>It is better programming practice to use non-generic names,=20
LOL, pot calling the kettle black, methinks.
>and any transition needed does not have to be painful.
> A simple, optional alias file using the original names will do=20
>if people are using these functions in their own code and don't want to=20
>update...
So why not move your own functions to your own, optional include file
that you use when you are not including win32lib?
Why get Derek to do this and potentially upset a large number of
people and break alot of existing code in the archives, when you could
just as easily do it without having to worry about that?
Pete
5. 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
6. Re: win32lib & global functions
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=20
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.
Regards,
Pete
