ejs name space

tridge at samba.org tridge at samba.org
Fri Jul 15 03:46:55 GMT 2005


We need to work out some namespace issues in ejs. For example, you
have created functions mkdir(), rmdir() etc that actually do SMB
operations, and I have created sys_unlink() that does a unlink() call
on the local filesystem. That could quickly get confusing for people
writing js code :-)

Perhaps we could follow a prefix convention? If you could rename your
smbcalls_cli.c ejs functions to cli_*() then we are much less likely
to tread on each others toes.

One of the major failings of js is that it doesn't have good namespace
control via packages or modules, so we need to be careful to choose
our names carefully.

For some thing like strupper(), and the variable 'NULL' I think
leaving off the prefix is fine, but for things like the ldb functions,
the cli functions etc we should use a common prefix per subsystem.

I chose thinks like ldbAdd() as the naming style for ldb calls, but
perhaps that would be better as ldb_add() to be more consistent. What
do you think?

An alternative would be to use an object oriented approach. For
example we could have code like this:

  var cli = cli_init();
  var conn = new Object();
  ok = cli.connect(conn, "//server/share);
  assert(ok == true);
  ok = cli.unlink(conn, "somefile.txt");
  assert(ok == true);

This would work by cli_init() creating a hash containing elements
which are pointers to C functions using mprCreateCFunctionVar(). That
way the functions are completely hidden inside the object, and don't
pollute the namespace at all (except for the init call).

This would be much more similar to the approach normally used in perl
and python I think. 

Which do you prefer? I think I prefer the latter approach, but I'd be
happy with either.

I also have some ideas on how to expose all of our libcli/raw/ code as
ejs without having to manually code all the glue code. Would you be
interested in that?

Cheers, Tridge

More information about the samba-technical mailing list