Namespacing Global Procedures

ID:165340
 
Jan 13 2007, 11:27 am
I wondered if it was possible to somehow place Global procedures into differing namespaces. My main reason for wanting to do this mainly lies with Library making, I would like to add utility procs that have simple and clear names, that do not clash with proc names used by other libraries.

Naturally, as I do not know what names all of the other Libraries in BYOND's Libraries sub-site use for global procs, I would rather not have to search the whole lot and find an un-used, applicable and clear name. I would also rather not have to use funny little pre/post-fixing naming conventions, which may hamper the readability for some Programmers.

My first thoughts on how to achieve this was to use DM's rather sensible tree structuring:

proc
    MyNameSpace
        myProcedure()

// To call:
mob
    proc
        callGlobal()
            /proc/MyNameSpace/myProcedure()


This does seem to work, however it has the drawback that it produced a Compiler Warning, advising that I used call() instead of a path. I feel it would be move intuitive for users of my Library to be able to call procs in my defined namespace by DM's path convention, than the call() proc. I suspect one cannot turn off Compiler Warnings (Which isn't desirable either, as some Warnings may be very useful, but the user would not see them).

Does anyone have any thoughts on how I might maintain clear global procs, or implement some form of namespacing that does not incur Compiler Warnings? Or would it just be prudent to sacrifice some readability to avoid name clashes?
Jan 13 2007, 12:01 pm
You can easily organize your library's variables by prefixing your global functions and variables. Another method is to define them in a datum, and initialize the datum inside of your library.

Approach 1:
// admin library named sAdmin 

var/list/sAdmin_banned = list()

proc/sAdmin_isBanned(client/C)
  return (C.key in sAdmin_banned)

proc/sAdmin_HandleBanned(client/C)
  C << "You are banned!"
  del(C)

// user code
client/New()
  if(sAdmin_isBanned(src.client))
    sAdmin_HandleBanned(src.client)
  ..()


Approach 2:
var/sAdmin/sAdmin = new

sAdmin
  var/list/banned = list()
  proc/isBanned(client/C)
    return (C.key in src.banned)
  proc/HandleBanned(client/C)
    C << "You are banned!"
    del(C)

// user code
client/New()
  if(sAdmin.isBanned(src))
    sAdmin.HandleBanned(src)
  ..()
Jan 13 2007, 12:19 pm
In response to Unknown Person
The second approach does seem quite reasonable. Does it incur much overhead? I suppose one Datum and one New() is perfectly acceptable from a Library.

One of my reasons for considering namespacing (In some form) came down to my attempt to implement the Singleton Pattern for a few centralised datums in my Library. However that generally proved difficult to do, whilst maintaining nice New() related semantics. I suppose I should just put some faith in users not abusing my Library's internals.