| Re: Namespaces (redux) [message #32295 is a reply to message #32233] |
Thu, 26 September 2002 09:23   |
![Stein Vidar Hagfors H[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "Stein Vidar Hagfors H[1] is currently offline")
Stein Vidar Hagfors H[1]
Messages: 56
Registered: February 2000
|
Member |
|
|
Struan Gray <struan.gray@sljus.lu.se> writes:
> JD Smith, jdsmith@as.arizona.edu writes:
>
>> 1. Use Objects.
>
> I think this is the key. If I were ever to put together a library
> of routines suitable for public use (oink oink, flap, flap) the most
> natural way seems to create a package object and make all the routines
> methods. There is no law that says an object's methods have to act on
> its internal data. Converting existing libraries and the code that uses
> it could probably even be automated.
Hear, hear, all of the above. Think "toolbox/toolkit". You can have several
toolboxes, and use different screwdrivers (errr.., LEGEND routines) from
separate toolboxes at you own whim, mingled together in the same routine at
different places. True, an essentially similar effect can be achieved with
prefixes like MPFIT, but at the expense of limiting the descriptiveness and
uniqueness of the prefix (versus using a class name), if one wants to avoid
very long routine names. In this sense, the variable name used to hold the
instantiation of a toolbox provides a means of having a localized shortcut
without poisoning the namespace for other local routines.
The trouble with automated conversion is interdependencies (calls within a
library must be changed to (inserting "self->" in front of those), and "user"
routines must be changed, involving a choice between libraries in cases of
conflict (currently done by path manipulation or other "automagic" means),
adding variables to hold each toolbox without messing up the existing routine,
and finally modifying the routine calls (potentially messing up
indentation/line lengths, etc). Converting the routine/file names (even in a
large hierarchy of library routines) is relatively trivial, though!
Namespace crowding is one of the reasons why I every now and then hold back
quite a bit from volunteering some of my own solutions to some of the problems
presented in this newsgroup. For convenience and historical reasons, most of
my routines involve *some* dependency on the SolarSoft library, which quite
frankly is a mess in this respect! So, rather than going through the motions
of ripping out those dependencies before suggesting "my" solution, I just shut
up (the alternative is asking people to install a centipede to get a single
pair of legs)!
--
------------------------------------------------------------ --------------
Stein Vidar Hagfors Haugan
ESA SOHO SOC/European Space Agency Science Operations Coordinator for SOHO
NASA Goddard Space Flight Center, Email: shaugan@esa.nascom.nasa.gov
Mail Code 682.3, Bld. 26, Room G-1, Tel.: 1-301-286-9028/240-354-6066
Greenbelt, Maryland 20771, USA. Fax: 1-301-286-0264
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
