Modules/1.1.1 Show of Hands

[Kris Kowal]

I'd like to call for a show of hands for Modules/1.1.1. Please show
hands here and begin discussions in a new thread.

Draft http://wiki.commonjs.org/wiki/Modules/1.1.1
Diff http://wiki.commonjs.org/index.php?title=Modules%2F1.1.1&diff=2509&oldid=2491

Kris Kowal

[Mikeal Rogers]

+ 1, of course :)

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

[Irakli Gozalishvili]

+1
--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Zachary Carter]

+1

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

--
Zach Carter

[Hannes Wallnoefer]

-1

I think having require.main === undefined is a much clearer way to say
there's no main module, and haven't seen any conclusive evidence why
the empty object would be preferable.

Hannes

2010/3/24 Kris Kowal <kris....@cixar.com>:

[Tobie Langel]

+1

[Daniel Friesen]

+0.5; I don't like it being an explicit {}, I'd prefer it if instead it
was defined as an object which must not have a set of keys. ie: an
object missing an id... I'd prefer to leave it up to implementations
what they want require.main to be for a non-module-main long as it
conforms. ie: If a impl makes `module` an instance of some sort of
Module class, I don't think it should be non-conforming of them to use
the same type of instance for require.main. And if an impl decides their
main isn't a module, but still has a followable url that it not be
non-conforming to define the .url but leave out the id and whatever else
is required to be left out.

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

[Dean Landolt]

On Wed, Mar 24, 2010 at 10:26 PM, Daniel Friesen <nadir.s...@gmail.com> wrote:

+0.5; I don't like it being an explicit {}, I'd prefer it if instead it was defined as an object which must not have a set of keys. ie: an object missing an id... I'd prefer to leave it up to implementations what they want require.main to be for a non-module-main long as it conforms. ie: If a impl makes `module` an instance of some sort of Module class, I don't think it should be non-conforming of them to use the same type of instance for require.main. And if an impl decides their main isn't a module, but still has a followable url that it not be non-conforming to define the .url but leave out the id and whatever else is required to be left out.

I really like this as a general principle -- we should duck-spec as much as possible.

[Ondřej Žára]

+1

O.

2010/3/24 Kris Kowal <kris....@cixar.com>

[Mikeal Rogers]

The problem with using require.main.id is that require.main is expected to be a reference to module in most cases and module.id states that require(module.id) should always return the top-level module. In cases where the top-level scope is not a valid module this attribute would have to be out of compliance with the id property specified for module if it's required to be set.

-Mikeal

--

[Kris Kowal]

Alright, given the following reversion, do hands go up or down?

http://wiki.commonjs.org/index.php?title=Modules%2F1.1.1&diff=2527&oldid=2525

Kris Kowal

[Mikeal Rogers]

+1

[Charles Jolley]

+1

[Hannes Wallnoefer]

+1

2010/3/25 Charles Jolley <cha...@sproutit.com>:

[Chris Zumbrunn]

http://wiki.commonjs.org/index.php?title=Modules/1.1.1&diff=2527&oldid=2491

+1

[George Moschovitis]

+1

> Diffhttp://wiki.commonjs.org/index.php?title=Modules%2F1.1.1&diff=2509&ol...
>
> Kris Kowal

[Tom Robinson]

My only concern is this:

2. A term must be a camelCase identifier, ".", or "..".

I have never seen a CommonJS module use camelCase ids.

I would prefer to just allow [0-9a-zA-Z_-] possibly along with a suggestion that uppercase characters are discouraged.

-tom

[Wes Garland]

I'm with Tom.

I think it's a fine spec, except that it makes "fs-base" an invalid CommonJS module identifier.  I would much rather see "fs-base" than "fsBase".

/especially/ considering the ramifications on a case-insensitive filesystem:

psychoTherapist and psychoTheRapist would be 'the same' module on Mac HFS but not Linux. I think
psycho-therapist and psycho-the-rapist would be far better.  We have prior-art moving from the case-insensitive to to the case-sensitive domain: CSS identifiers in text/css vs. text/html documents.

So, -1, but that is my only point of contention.

Wes

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

[Kris Kowal]

On Wed, Mar 31, 2010 at 6:38 PM, Wes Garland <w...@page.ca> wrote:
> So, -1, but that is my only point of contention.

I want this fixed too, but it's not a regression. Would you be
willing to put it off for the next version?

Kris Kowal

[Wes Garland]

On Wed, Mar 31, 2010 at 9:43 PM, Kris Kowal <cowber...@gmail.com> wrote:

I want this fixed too, but it's not a regression.

Really?!?!

*googles*

HUH!  Well, I'll be a ...
 

Would you be
willing to put it off for the next version?

Yes.  But let's get it on the next one fer-sure.  fs-base is out of spec.

Wes

[Tom Robinson]

It's not a regression in the spec, but AFAIK none of the implementations follow it.

I'm fine with holding off for 1.2, I had just overlooked the 1.2 Agenda thread before I posted.

-tom

[Wes Garland]

> It's not a regression in the spec, but AFAIK none of the implementations follow it.

I don't think the intention will ever be for the implementations to follow it: It's just a promise for the CommonJS community to promise never to propose a standard module whose name violates it.

Wes