Something that wasn't clear to me personally until reading the last few
posts: I suspect that some of the negative reaction to unwrapping/wrapping,
and the suggestion that FutureFutureT is a meaningful construct, comes
from the mindset of static typing - not in the sense that static types
Le 26/04/2013 00:21, Claus Reinke a écrit :
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted
A Future for a Future seems like a corner case compared to the
broader simplicity of an implicit unwrap.
The argument is not about whether FutureFuture... is a common
case. The Argument is that Future... and Array... and Optional...
and things that may raise catchable errors and other types
Le 26/04/2013 03:39, Tab Atkins Jr. a écrit :
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble trib...@e-dean.com wrote:
So what's an example
that motivates you to want to build a tower of promise types? The main one
I know of is the implementation (not use of) higher-order collection
constructs
On 26 April 2013 10:54, David Bruant bruan...@gmail.com wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part translates into
helping users? authors (more than what I described at [2] which is derived
from my own
[adding public-script-coord and Anne]
Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit :
On 26 April 2013 10:54, David Bruant bruan...@gmail.com wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part
On 26 April 2013 12:19, David Bruant bruan...@gmail.com wrote:
In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some people
(including me) like to call
Le 26/04/2013 13:24, Andreas Rossberg a écrit :
On 26 April 2013 12:19, David Bruant bruan...@gmail.com wrote:
In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some
Math.imul support was just added to the v8 trunk:
https://code.google.com/p/v8/source/detail?r=14450.
Is there any ongoing effort to standardize it?
On Fri, Nov 2, 2012 at 9:24 PM, Brendan Eich bren...@mozilla.org wrote:
David Herman wrote:
On Nov 2, 2012, at 12:05 PM, Yehuda
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or not the API allows one
to create a promise whose eventual value is itself a
Let me take a crack at describing E's support for promises.
E has two modes for sending a message to an object. There is the
immediate send and the eventual send. If the Object is an
unresolved promise the immediate send will trap. (A promise can
be forced to resolve using the when
Yes, you do.
On Apr 26, 2013 2:54 PM, Kevin Smith zenpars...@gmail.com wrote:
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or
On Fri, Apr 26, 2013 at 9:28 AM, Alex Russell slightly...@google.comwrote:
Yes, you do.
Mark or Domenic, is the point about Q true as well? (That it could, in
principle, provide something like Future.accept, but it chooses not to.)
Just wanted to check before I say somethin' foolish : )
{
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then the only real controversy is whether or not the API allows
one to create a
On 26 April 2013 14:29, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 13:24, Andreas Rossberg a écrit :
I'm not sure if your description of E is accurate -- I'd find that
surprising. It _is_ a perfectly sensible design to have transparent
futures that you can just use in place of the
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
Promise/A+ does not prohibit promises for promises. But in practice the
problem is
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted nesting
Perhaps you didn't read my post then?
Can you point to any code in wide use that makes use of this
thenables = monads idea you seem to be implicitly assuming?
Perhaps some of this generic thenable library code? I have never
seen such code, whereas the use of thenable to mean object with
a then method, which we will try to treat as
So there are no such libraries, and you are just wishing that they existed and
that they took over the meaning of `then` from promises?
From: Claus Reinke [claus.rei...@talk21.com]
Sent: Friday, April 26, 2013 10:11
To: Domenic Denicola; Mark Miller; David
Le 26/04/2013 15:47, Claus Reinke a écrit :
My own argument is not for nested futures themselves, but (1) for
futures to offer the same interface (.of, .then) as other thenables,
which
(2) implies that there is to be no implicit lifting or flattening in
.then.
For promises, I don't expect to
From: David Bruant [bruan...@gmail.com]
Thoughts?
Since this entire problem seems predicated on Claus's misunderstanding of the
term thenable, which apparently has no basis in real libraries but instead
entirely in wishful thinking, it might be more prudent for him to use the term
monad
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I believe the controversy is over the number of resolution iterations
for a given wrapped value.
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big
You argue for a two-level system of non-lexical names to support
configuration - okay. But why does that imply you have to drop
the lexical naming altogether, instead of using a three-level system
(from external to internal to lexical names)?
You don't, it's an orthogonal concern. Note that Sam
On Fri, Apr 26, 2013 at 3:20 PM, David Sheets kosmo...@gmail.com wrote:
2013/4/26 Kevin Smith zenpars...@gmail.com
What exactly is the controversy here?
I believe the controversy is over the number of resolution iterations
for a given wrapped value.
I think we all agree with the semantics
On Fri, Apr 26, 2013 at 9:36 AM, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then
Hi Sam,
Thanks for this long explanation. I have several thoughts, but I'd like to
ask one thing in particular.
What you propose, with logical names, is a global namespace of short
human-readable names with *no* conflict resolution authority. How do you
see that working? From a namespace
From: David Sheets [kosmo...@gmail.com]
From my reading, DOM Futures doesn't state anything about resolution
semantics, to its detriment, but abstracts those semantics behind
`FutureResolver`.
This is not correct. See Let resolve be a future callback for the context
object and its resolve
From: Kevin Smith [zenpars...@gmail.com]
What you propose, with logical names, is a global namespace of short
human-readable names with *no* conflict resolution authority. How do you see
that working? From a namespace perspective, how is that any different than
hanging identifiers off of
Promise/A+ does not prohibit promises for promises. But in practice the
problem is recognizing what is a promise.
I would say rather that we have two orthogonal, but
highly interfering issues:
1. Do we allow promises-(for-promises)+?
2. How do we recognize a promise type within the resolve
On Fri, Apr 26, 2013 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: David Sheets [kosmo...@gmail.com]
From my reading, DOM Futures doesn't state anything about resolution
semantics, to its detriment, but abstracts those semantics behind
`FutureResolver`.
This is not
From: David Sheets [kosmo...@gmail.com]
Why is there a semantic distinction between my thenables and your thenables?
Because your thenables are not to be trusted! They could do pathological things
like jQuery, or conceptually incoherent things like thenables-for-thenables.
Sanitation at the
On 26 April 2013 16:25, Dean Landolt d...@deanlandolt.com wrote:
The fundamental controversy, as Juan just noted, is how to precisely
identify a promise in order to do either of these two things. This problem
isn't quite so clean cut, but it's much more important to solve. I've been
trying to
On Fri, Apr 26, 2013 at 4:03 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: David Sheets [kosmo...@gmail.com]
Why is there a semantic distinction between my thenables and your thenables?
Because your thenables are not to be trusted! They could do pathological
things like
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
Let me note that this is not the fundamental controversy (not for me,
anyway). The fundamental controversy is whether there should be any
irregularity at all, as is unavoidably introduced by implicit
On Tue, Apr 23, 2013 at 11:30 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Apr 23, 2013 at 11:25 AM, David Sheets kosmo...@gmail.com wrote:
On Tue, Apr 23, 2013 at 7:02 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Apr 23, 2013 at 6:12 AM, David Bruant bruan...@gmail.com
Hi Bill,
I think I know what you mean by these terms, and what I think you mean is
correct ;). But given the history of promises and futures, you make two
unfortunate and confusing terminology choices: forced and wait.
Instead, E promises, like all JS promises, are inherently non-blocking. The
On Apr 24, 2013, at 9:17 PM, Ron Buckton wrote:
Be it Promise or Future, instanceof won’t work across frames. It would likely
still require a Future.isFuture/Promise.isPromise just as we need to have
Array.isArray now. That is, of course, unless we can use symbols for branding
in a
On Fri, Apr 26, 2013 at 8:45 AM, David Sheets kosmo...@gmail.com wrote:
Could you point me to some code that needs dynamic flattening?
From
https://github.com/promises-aplus/promises-spec/issues/101#issuecomment-16657518
```js
var promise = getDataFromServerUsingQ().then(function (data) {
Le 26/04/2013 17:25, Tab Atkins Jr. a écrit :
On Fri, Apr 26, 2013 at 3:19 AM, David Bruant bruan...@gmail.com wrote:
Your abstract example was:
If FutureFuturex can exist, then you'll have to write this
boilerplate code in a lot of places:
f.then(function res(v){
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and libraries
switch to using those (or a subclass of them) rather than rolling bespoke
promises.
Last I heard, jQuery has committed to never switching their promises
implementation to
On Fri, Apr 26, 2013 at 9:01 AM, David Sheets kosmo...@gmail.com wrote:
Domenic points out
http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/0234.html
that DOM Futures currently do a recursive resolution which seems to
violate these equivalences. I also don't see anything
On Apr 26, 2013 8:42 AM, Tom Schuster t...@schuster.me wrote:
Math.imul support was just added to the v8 trunk:
https://code.google.com/p/v8/source/detail?r=14450.
Is there any ongoing effort to standardize it?
As with Firefox, which you actually implemented :)
I landed support for Math.imul in JSC yesterday as well.
Can't find actual documentation on the expected behavior so just copied what
mozilla does.
--Oliver
On Apr 26, 2013, at 10:58 AM, Rick Waldron waldron.r...@gmail.com wrote:
On Apr 26, 2013 8:42 AM, Tom Schuster t...@schuster.me
On Fri, Apr 26, 2013 at 10:03 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and libraries
switch to using those (or a subclass of them) rather than rolling bespoke
promises.
The current DOM spec, in code:
Future.resolve(1).then(value = {
value === 1;
// Return a non-promise
return 2;
}).then(value = {
value === 2;
// Return a promise for a non-promise
return Future.resolve(3);
}).then(value = {
On Fri, Apr 26, 2013 at 11:03 AM, Kevin Smith zenpars...@gmail.com wrote:
The current DOM spec, in code:
Or, much more simply:
* Future.accept takes a Foo and returns a FutureFoo.
* Future.resolve takes either a Foo or a FutureFoo. In either case,
it returns a FutureFoo.
* In Future.then(cb),
Le 26/04/2013 17:58, Mark Miller a écrit :
However, the need for assimilation is history dependent. If there is
another plausible-enough path to adoption and widespread use of
promises that does not require assimilation, I would be very happy.
But I have not found any of the alternatives
Actually, I may have gotten it terribly wrong (apologies). In my prototype
implementation, the following:
Future.accept(Future.resolve(1)).then(value = {
console.log(value !== 1);
return Future.accept(Future.resolve(1));
}).then(value = {
console.log(value ===
On Fri, Apr 26, 2013 at 8:58 AM, Mark Miller erig...@gmail.com wrote:
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
Let me note that this is not the fundamental controversy (not for me,
anyway). The fundamental controversy is whether there should be any
On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com wrote:
Actually, I may have gotten it terribly wrong (apologies). In my prototype
implementation, the following:
Future.accept(Future.resolve(1)).then(value = {
console.log(value !== 1);
return
On Apr 26, 2013 1:03 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
The need for this will decrease now that DOM Futures exist, and
libraries switch to using those (or a subclass of them) rather than rolling
bespoke promises.
Last I
I think this is a really good description of the problems and possible
solutions. Unfortunately, I think you underestimate the problems.
Where should this wrapping occur? Each library can add a check+convert to all
surface API. It doesn't sound that hard (library authors can jump in to say
2013/4/26 Tab Atkins Jr. jackalm...@gmail.com
On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com
wrote:
Actually, I may have gotten it terribly wrong (apologies). In my
prototype
implementation, the following:
Future.accept(Future.resolve(1)).then(value = {
Filed https://bugs.ecmascript.org/show_bug.cgi?id=1452
On Fri, Apr 26, 2013 at 2:01 PM, Oliver Hunt oli...@apple.com wrote:
I landed support for Math.imul in JSC yesterday as well.
Can't find actual documentation on the expected behavior so just copied
what mozilla does.
--Oliver
On Apr
On Fri, Apr 26, 2013 at 7:25 PM, Kevin Smith zenpars...@gmail.com wrote:
Future.accept(Future.resolve(1)).then(value = {
console.log(value !== 1);
return Future.accept(Future.resolve(1));
}).then(value = {
console.log(value === 1);
});
logs
- true
If resolved called the thenable's then() with *accept *and reject, it
would only unwrap one layer.
Good spec googles (I think). I just whiteboarded it and came to the same
conclusion. Does anyone else have a prototype implementation they can run
this program on?
{ Kevin }
On Fri, Apr 26, 2013 at 7:44 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
I think Kevin's assertion is correct. According to the spec, callbacks are
wrapped in something called a future wrapper callback. When a promise is
returned from the callback, the wrapper does this:
Let value be
2013/4/26 Anne van Kesteren ann...@annevk.nl
If resolve called the thenable's then() with accept and reject, it would
only unwrap one layer.
Oops yeah. I guess that should be fixed. :/
Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only
2013/4/26 Mark Miller erig...@gmail.com
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
the term future
What are the chances of the WHATWG renaming the spec to DOMPromise?
Juan
___
es-discuss mailing list
Oops yeah. I guess that should be fixed. :/
Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only one layer, the spec would need a way to
discern promises from thenables.
I don't think so. It has no bearing on Promises/A+, because A+ doesn't
On Fri, Apr 26, 2013 at 12:17 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
2013/4/26 Mark Miller erig...@gmail.com
On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
wrote:
[...]
the term future
What are the chances of the WHATWG renaming the spec to DOMPromise?
On Apr 26, 2013 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com
wrote:
Actually, I may have gotten it terribly wrong (apologies). In my
prototype
implementation, the following:
2013/4/26 Kevin Smith zenpars...@gmail.com
Oops yeah. I guess that should be fixed. :/
Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only one layer, the spec would need a way to
discern promises from thenables.
I don't think so. It has
On Fri, Apr 26, 2013 at 12:24 PM, Alex Russell slightly...@google.com wrote:
On Apr 26, 2013 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com
wrote:
Actually, I may have gotten it terribly wrong (apologies). In my
From: Juan Ignacio Dopazo [dopazo.j...@gmail.com]
2013/4/26 Kevin Smith zenpars...@gmail.com
Oops yeah. I guess that should be fixed. :/
Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only one layer, the spec would need a way to
discern
Le 26/04/2013 20:39, Domenic Denicola a écrit :
I think this is a really good description of the problems and possible
solutions. Unfortunately, I think you underestimate the problems.
Where should this wrapping occur? Each library can add a check+convert to all
surface API. It doesn't sound
Le 26/04/2013 20:36, Rick Waldron a écrit :
The libraries discussed in this and similar threads have the benefit
of very limited adoption, where breaking changes incur minimal costs.
jQuery doesn't have that luxury ;) [0] and therefore won't break
backward compatibility. I can assure you that
Yes, sorry. It will on version 1.1:
https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure
To clarify: in 1.0, the behavior of returning a thenable was highly
underspecified, in part because of a lack of clarity about promises vs.
thenables. In 1.1, returning a
From: Kevin Smith [zenpars...@gmail.com]
Yes, sorry. It will on version 1.1:
https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure
To clarify: in 1.0, the behavior of returning a thenable was highly
underspecified, in part because of a lack of clarity about
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be
compatible with Promise/A+ and not jQuery promises? Because more libraries
use Promise/A+? what about market share?
What we're discussing is not *compatibility* but *ability to
We did talk about Math.imul, Dave presented it briefly IIRC last fall.
It's a bite-sized win. Should be able to get it into ES6.
/be
Rick Waldron wrote:
Filed https://bugs.ecmascript.org/show_bug.cgi?id=1452
On Fri, Apr 26, 2013 at 2:01 PM, Oliver Hunt oli...@apple.com
On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be
compatible with Promise/A+ and not jQuery promises? Because more
libraries use Promise/A+?
The difference would only surface when testing that case.
Not quite. You can still have thenables that call `onFulfilled` with
another thenable, to any depth. You can also insert a real promise at the
end of any-length thenable chain.
I understand now. Essentially, in the test you create
On Fri, Apr 26, 2013 at 11:44 AM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
2013/4/26 Tab Atkins Jr. jackalm...@gmail.com
On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com
wrote:
Actually, I may have gotten it terribly wrong (apologies). In my
prototype
Le 26/04/2013 21:47, Domenic Denicola a écrit :
From: David Bruant [bruan...@gmail.com]
Which naturally leads to the question: why should platform promises be compatible with
Promise/A+ and not jQuery promises? Because more libraries use Promise/A+?
what about market share?
I realize I was
On Fri, Apr 26, 2013 at 6:36 AM, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Promises/A+. (If not, then we have a really big problem!)
If so, then
On Fri, Apr 26, 2013 at 1:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
[snip]
No. Future callbacks can return Futures, which then chain (the return
value of then adopts the state of the callback's return value). This
is the big monad benefit that we keep talking about.
[snip]
Shorter
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me: this is why I keep asking people who want flattening to actually
provide an example of where flattening is useful, that isn't (a)
assimilation, (b) a result of weird language semantics from some non-JS
language, or (c) an authoring
On Fri, Apr 26, 2013 at 1:45 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Tab Atkins Jr. [jackalm...@gmail.com]
Shorter me: this is why I keep asking people who want flattening to actually
provide an example of where flattening is useful, that isn't (a)
assimilation, (b) a
On Fri, Apr 26, 2013 at 1:39 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Apr 26, 2013 at 6:36 AM, David Bruant bruan...@gmail.com wrote:
Le 26/04/2013 14:54, Kevin Smith a écrit :
What exactly is the controversy here?
I think we all agree with the semantics of then as specified in
Hi,
ES5 remains pretty vague as far as the global object is concerned [1].
Specifically, the [[Class]] is left to the implementation suggesting
that internal [[Get]], [[Set]], etc. are unbounded on what they can do.
For instance, when doing this.Object, an implementation could do
anything
The right place to discuss this is probably in [3] below.
On Apr 27, 2013, at 12:13 AM, David Bruant wrote:
Hi,
ES5 remains pretty vague as far as the global object is concerned [1].
Specifically, the [[Class]] is left to the implementation suggesting
No, [[Class]] does not suggest
Thanks for making these issues clearer to me Mark. I am
beginning to get some idea of the problems that JS promises face
given that they must have an object-like appearance.
I like the fact that in E, promises just work and I think of
Joule as a language where every value is a promise and
On Apr 26, 2013, at 7:20 AM, Claus Reinke claus.rei...@talk21.com wrote:
You believe you have worked out the core parts that caused you to
postpone lexical modules,
We're still on the hook to finish a wiki-complete design of the core by the
May meeting. I'm a busy guy.
Dave
On Apr 26, 2013, at 7:27 AM, Kevin Smith zenpars...@gmail.com wrote:
What you propose, with logical names, is a global namespace of short
human-readable names with *no* conflict resolution authority. How do you see
that working? From a namespace perspective, how is that any different than
I have an implementation in Typescript/ES5 at
https://github.com/rbuckton/promisejs/tree/master/Variations with a test suite
that can be run from node.
Ron
Sent from my Windows Phone
From: Kevin Smithmailto:zenpars...@gmail.com
Sent: 4/26/2013 11:47 AM
To:
On Fri, Apr 26, 2013 at 7:17 PM, David Herman dher...@mozilla.com wrote:
On Apr 26, 2013, at 7:27 AM, Kevin Smith zenpars...@gmail.com wrote:
I'm not understanding how this strategy will facilitate namespace
coordination. I can
only see it leading to namespace confusion.
There is, of
Claus Reinke wrote:
but do you think
users are going to rewrite their code bases twice just because modules
are going to be delivered in two stages?
What are you talking about?
People are not going to rewrite more than once. Current NPM/AMD modules
do not nest, so there's no basis for
And note that Java also does not mandate reverse-DNS, it's just a
convention. But in fact, that convention is really annoying and people hate
it. Node uses much simpler global names that are reserved via NPM. This
does lead to collisions and some people don't like that; an alternative
system
One additional point on this topic. Even on the web, where there isn't
something like NPM as an arbiter for names, the JS community has
managed to use shared resources like the global object and the AMD
module name space effectively.
Facility of scale. If done correctly, we ought to hope
On Sat, Apr 27, 2013 at 12:22 AM, Kevin Smith zenpars...@gmail.com wrote:
And note that Java also does not mandate reverse-DNS, it's just a
convention. But in fact, that convention is really annoying and people hate
it. Node uses much simpler global names that are reserved via NPM. This does
91 matches
Mail list logo
