Modules/1.1.1 Show of Hands

191 views
Skip to first unread message

Kris Kowal

unread,
Mar 24, 2010, 6:08:43 PM3/24/10
to comm...@googlegroups.com
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

unread,
Mar 24, 2010, 6:30:00 PM3/24/10
to comm...@googlegroups.com
+ 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

unread,
Mar 24, 2010, 6:32:37 PM3/24/10
to comm...@googlegroups.com
+1
--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

Zachary Carter

unread,
Mar 24, 2010, 6:37:49 PM3/24/10
to comm...@googlegroups.com
+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

unread,
Mar 24, 2010, 6:46:06 PM3/24/10
to comm...@googlegroups.com
-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

unread,
Mar 24, 2010, 6:56:36 PM3/24/10
to CommonJS
+1

Daniel Friesen

unread,
Mar 24, 2010, 10:26:35 PM3/24/10
to comm...@googlegroups.com
+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

unread,
Mar 24, 2010, 10:35:43 PM3/24/10
to comm...@googlegroups.com
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

unread,
Mar 25, 2010, 4:27:18 AM3/25/10
to comm...@googlegroups.com
+1

O.


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

Mikeal Rogers

unread,
Mar 25, 2010, 12:20:57 PM3/25/10
to comm...@googlegroups.com
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

unread,
Mar 25, 2010, 3:13:38 PM3/25/10
to comm...@googlegroups.com
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

unread,
Mar 25, 2010, 3:15:08 PM3/25/10
to comm...@googlegroups.com
+1

Charles Jolley

unread,
Mar 25, 2010, 3:20:07 PM3/25/10
to comm...@googlegroups.com
+1

Hannes Wallnoefer

unread,
Mar 25, 2010, 3:30:25 PM3/25/10
to comm...@googlegroups.com
+1

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

Chris Zumbrunn

unread,
Mar 25, 2010, 4:54:44 PM3/25/10
to comm...@googlegroups.com

George Moschovitis

unread,
Mar 28, 2010, 12:40:46 PM3/28/10
to CommonJS

Tom Robinson

unread,
Mar 31, 2010, 7:00:38 PM3/31/10
to comm...@googlegroups.com
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

unread,
Mar 31, 2010, 9:38:22 PM3/31/10
to comm...@googlegroups.com
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

unread,
Mar 31, 2010, 9:43:08 PM3/31/10
to comm...@googlegroups.com
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

unread,
Mar 31, 2010, 10:49:35 PM3/31/10
to comm...@googlegroups.com
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

unread,
Apr 1, 2010, 4:22:00 AM4/1/10
to comm...@googlegroups.com
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

unread,
Apr 1, 2010, 8:07:49 AM4/1/10
to comm...@googlegroups.com
> 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
Reply all
Reply to author
Forward
0 new messages