1. win32lib & global functions
- Posted by Andy Serpa <ac at onehorseshy.com> Oct 02, 2003
- 372 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Oct 02, 2003
- 375 views
----- 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
- Posted by Wolf <wolfritz at KING.IGS.NET> Oct 02, 2003
- 369 views
> 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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Oct 03, 2003
- 380 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Oct 03, 2003
- 364 views
----- 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
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Oct 04, 2003
- 369 views
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