newlispfanclub.alh.net

I am considering to title-case all contexts/namespaces names used in standard modules shipped with the source distribution and installers which are currently lower-case.

This has been discussed earlier, but as it may break existing code I am interested to hear the community about this again and before changint it.

The following prefixes would be affected:

canvas.lsp - cv -> Cv
crypto.lsp - crypto -> Crypto
postscript.lsp - ps -> Ps
stat.lsp - stat -> Stat
sqlite3.lsp -> sql3 -> Sql3
unix.lsp -> unix -> Unix
zlib.lsp -> zlib -> Zlib

The following prefixes would stay as they are:

cgi.lsp - CGI
ftp.lsp - FTP
gmp.lsp - GMP
indix.lsp - INFIX (or should it be Infix ?)
mysql.lsp - MySQL
pop3.lsp - POP3
postgres.lsp - PgSQL
xmlrpc-client.lsp - XMLRPC

Basically we would follow Cormullion's suggestion to title-case namespace names except for generally known abbreviations (Internet protocols, known trademarks, etc.). The documentation (newlisp_manual.html, CodePatterns.html) mostly follows this convention already and changes would be made where this is not the case.

Most third party modules listed here: http://www.newlisp.org/modules/ also follow this convention already, and it seems to be generally accepted programming practice.

What do you think? What would be the schedule of introduction?

Ps: variables holding contexts would stay lower-case. This way both cannot be confused when reading unknown code:
... it would then be obvious that 'cx' is a variable holding a context, not a context itself.

You could always just duplicate the names for a few versions:

Hi Lutz,

This is only from a visual aspect and not becoming mandatory.. right?

Because If I dislike something in particular about a programming language
then its being case sensitive.. Ieeeekksss my fingers start rejecting the keyboard already..

Norman.

Its not mandatory, only good practice and the way modules would be shipped.

Jeff:

but 'new' would also duplicate the memory used, because everything gets copied to a second context.

There is a better method using a context variable:
This technique is also described in the canvas module. The canvas and the postsrcipt module are API compatible. When I was testing the canvas module, I just plugged in the old postscript modules for testing.

My suggestion was for future modules. I'm voting against changes that break existing code.

I think what cormullion is responding to here is the reason standards committees are set up to begin with. I, too, was bitten by 10, but the bites have mostly healed now. Granted, I have no modules of code floating around to continue mauling me.

It’s the ol’ ebb-and-flow between freedom and security.

As newLISP matures, changes will naturally become less frequent and drastic. Till then, we’re riding the rough Western range, where nothing is gare-on-teed.

As to the naming change, I kind of liked the idea that module names were lowercased to set them off from classes :-) But I know Lutz struggles with his decisions about every tiny detail of newLISP, so I’ll naturally defer to him.

m i c h a e l

I know there's been a lot of talk about contexts and possible identifier collisions recently. I've been wondering if we shouldn't start a more unique naming convention: Referring to these long identifiers might be annoying, but you can always make an alias. Of course this Java-like pattern is only one style. We have nearly all characters available to do whatever we want.