ejs name space
tpot at samba.org
Fri Jul 15 04:20:57 GMT 2005
On Fri, 2005-07-15 at 13:46 +1000, tridge at samba.org wrote:
> 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. (-:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20050715/0044c99f/attachment.bin
More information about the samba-technical