Modules 1.2 Agenda

[Kris Kowal]

Please nominate features for 1.2 here. Extra points for making proposals.

We need proposals for:

* A module-relative "resource" object, like module.resource(path).open(…).
* To fix the module identifier domain. The current specification
restricts module identifiers to camelCase delimited by slashes, but
this is hazardous in case-insensitve stores, and not restricted in
practice.

Tobie has made a proposal for async, which is in flux:
http://wiki.commonjs.org/wiki/Modules/Async/A

Kris Kowal

[Kris Kowal]

On Wed, Mar 24, 2010 at 3:13 PM, Kris Kowal <kris....@cixar.com> wrote:
> Please nominate features for 1.2 here.  Extra points for making proposals.

There's also a note on the wiki:

** version 1.1 will need spec tweaks and more work: there has been
discussion/argument over the behaviour and formation of module.id, one
side going for invariance based on path relative to search paths, the
other going for absolute file path, since the top level id is
dependent on the require.paths at the time of module load. There is
also discussion about what we should and shouldn't allow as an
argument to require, particularly about camelCase (which not many
platforms mandate) and about file extensions.

Kris Kowal

[Wes Garland]

File extensions should not be spec mandated; assuming js as an impl
language is a non-starter

We should be looking at module resources and clarifying instanceof and
exports enumerability expectations on 1.2 IMO.

Wes

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google
> Groups "CommonJS" group.
> To post to this group, send email to comm...@googlegroups.com.
> To unsubscribe from this group, send email to commonjs+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/commonjs?hl=en
> .
>

[Charles Jolley]

re camelCase: would we just make module id's should be case insensitive?

-Charles

[Kris Kowal]

On Wed, Mar 24, 2010 at 3:43 PM, Charles Jolley <cha...@sproutit.com> wrote:
> re camelCase: would we just make module id's should be case insensitive?

A case-insensitive name-space is vulnerable to cross-platform
difficulties. I think we need to mandate a delimiter at least, for
CommonJS modules, never mind extensions to the spec that have no
interest in being portable, like ObjJ Frameworks, which Narwhal is
obliged to support beyond spec anyway.

The reason for being picky about case insensitivity is the very real
albeit rare problem of ambiguous names like "expertsexchange". On a
case-insensitive file system "ExpertsExchange" is informational but
still collides with "ExpertSexChange", so these two names cannot
coexist. Mandating a delimiter and a normal case obviates this class
of problems.

So this is another area of verbiage that is sensitive to the
distinction between constraints on interoperable modules, and
constraints on interoperable module loaders. I do not think that we
should mandate that module loaders reject modules that are not
CommonJS module identifiers. We should however mandate that CommonJS
compliant modules should use a strict name-space, to guarantee that
all loaders can load them without conflicts. I'm in favor of hyphen
delimited lower-case alphanumeric terms delimited by slashes.

Kris Kowal

[Mikeal Rogers]

Making module identifiers case insensitive puts a large burden on package installers and package registries. At the very least this will require additional queries to check *all* existing entries, toLower them, and see if a new package conflicts.

I think this puts a pretty large burden on implementers when most environments are already case sensitive and when they aren't they fail in fairly obvious ways.

-Mikeal

Kris Kowal

[Kris Kowal]

On Wed, Mar 24, 2010 at 4:59 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
> Making module identifiers case insensitive puts a large burden on package
> installers and package registries. At the very least this will require
> additional queries to check *all* existing entries, toLower them, and see if
> a new package conflicts.

I'm not suggesting case-insensitivity. I'm recommending that the
module identifiers must be lower case so that if they happen to be
stored on a case insensitive file system (e.g., a Mac with stock HFS,
and NTFS last time I checked, which was admittedly a previous life),
there won't be any conflicts. I am not recommending any special
checks or toLowerCase calls in loader code.

Kris Kowal

[Wes Garland]

Right -- all kris k is saying here is that xommonjs-sanctioned names
must come from a paeticular character set.., I'm not sure what is
meant by the slash 's mention, though -- kris, care to xomment further?

Wes

Sent from my iPhone

[Mikeal Rogers]

I guess my next question is are we suggesting that this is "must" or "may" in the spec?

"must" implies that Modules implementations that allow names that aren't lowercase are out of compliance. "may" sounds like it's barely a suggestion. This is one of those places I'd really like "should".

-Mikeal

[Wes Garland]

This doesn't affect module /implementations/ at all -- only the standards process.

Wes

Sent from my iPhone

[Kris Kowal]

On Wed, Mar 24, 2010 at 5:21 PM, Wes Garland <w...@page.ca> wrote:
> This doesn't affect module /implementations/ at all -- only the standards
> process.

Right, we need to refactor the module specification to be divided into
a section for which "may" and "must" apply to modules, and another
section where "may" and "must" apply to module loaders.

Kris Kowal

[James Burke]

On Wed, Mar 24, 2010 at 5:07 PM, Kris Kowal <cowber...@gmail.com> wrote:
> I'm not suggesting case-insensitivity. I'm recommending that the
> module identifiers must be lower case so that if they happen to be
> stored on a case insensitive file system (e.g., a Mac with stock HFS,
> and NTFS last time I checked, which was admittedly a previous life),
> there won't be any conflicts.  I am not recommending any special
> checks or toLowerCase calls in loader code.

I do not recall other systems, like Python or Java, that have spec
schemes to avoid casing issues? It would seem fine to leave it out of
any CommonJS module spec.

I do not like any naming scheme that makes it hard to make a JS
variable of the same name as the module name. Slashes are not allowed
in JS names, but using the last part of a module ID seems like it
might be a common choice.

James

[Chris Zumbrunn]

I'm fine with additional restrictions, like lowercase, but hope that
we will not make module identifiers less restrictive.

The spec could say that a term must be a lowercase alphanumerical
value that is a legal javascript variable identifier.

"4logjs" would be illegal, so is (and always was) "fs-base".

Chris

[Kris Kowal]

On Thu, Mar 25, 2010 at 3:02 AM, Chris Zumbrunn
<chris.z...@gmail.com> wrote:
> I'm fine with additional restrictions, like lowercase, but hope that
> we will not make module identifiers less restrictive.
>
> The spec could say that a term must be a lowercase alphanumerical
> value that is a legal javascript variable identifier.

In practice, there is no reason to restrict module names to valid
JavaScript identifiers.

Kris Kowal

[Chris Zumbrunn]

Well, being able to assign a required module to a variable of the same
name should probably be counted as a reason.

Beyond that, I just think that we may one day want to extend the use
of modules in a way that will make allowing none-js--var-id-names feel
like a mistake. For example an implementation or convention that under
some circumstances would make modules directly available in the
context of certain scopes or that would make them available as
properties of an object. Forcing users to use a syntax like
foo["fs-base"] wouldn't be pretty, needing to do global["fs-base"] or
this["fs-base"] even worse.

Are we loosing a lot by keeping the restriction?

Chris

[Mikeal Rogers]

I don't think that's much of an issue.

Most popular types of libraries will end up have long names because they'll be competing for namespace in the package registries. An example from Python.

json
json2
jsonlib
jsonlib2
simplejson
yajl

Once the names are large or less descriptive people won't be using the name as the variable name anyway.

var json = require('yajl');

I would rather encourage "-" as a separator because of the issues Kris Kowal mentioned with camelcase and not worry about being valid variable names.

-Mikeal

[Wes Garland]

> I would rather encourage "-" as a separator because of the issues Kris Kowal mentioned
> with camelcase and not worry about being valid variable names.

We also have prior examples in related use where we move between case-sensitive camelCase identifiers and a case-insensitive domain: CSS.

HTML is case-insensitive, so we wind up with font-family.  JavaScript is case-sensitive; this transforms to fontFamily in the object model.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Daniel Friesen]

^_^ Heh, I even have string prototypes to convert between those forms
inside Wrench.js already.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

> > <chris.z...@gmail.com <mailto:chris.z...@gmail.com>>

> <mailto:comm...@googlegroups.com>.

> To unsubscribe from this group, send email to
> commonjs+u...@googlegroups.com

> <mailto:commonjs%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/commonjs?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "CommonJS" group.
> To post to this group, send email to comm...@googlegroups.com

> <mailto:comm...@googlegroups.com>.

> To unsubscribe from this group, send email to
> commonjs+u...@googlegroups.com

> <mailto:commonjs%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/commonjs?hl=en.
>
>
>
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102