ejs name space

[Tim Potter]

On Fri, 2005-07-15 at 13:46 +1000, tridge at samba.org wrote:
> Tim,
> 
> 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.

Yep - that sounds like a good idea.

> 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?

I prefer the ldb_add() format myself as it's closer to the C function
names, and also fits in with the cli_ convention you mention above.

> 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. 

I wasn't sure how well this sort of thing was supported in ejs.  Doing
this certainly makes things a bit more readable as well as slightly
easier to program.  I vote for the OO approach as well.

> 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?

Do tell!  I have just been poking around trying out a few things to see
if anything nice comes out of it.  So far, no luck.  (-:


Tim.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050715/0044c99f/attachment.bin