On Nov 6, 2012, at November 6, 201211:35 AM, Rick Waldron
waldron.r...@gmail.com wrote:
Based on a read through of https://github.com/promises-aplus/promises-spec,
these things initially come to mind, please regard as a loose collection of
varying thoughts that may or may not be completely
: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on
behalf of Mikeal Rogers [mikeal.rog...@gmail.com]
Sent: Tuesday, November 06, 2012 15:33
also, node.js won't adopt either a promise API or a promise syntax for
it's core API. if it lands in the language then nothing
Sure, but I would hate it if this opportunity to create a **better** module
system was dragged down by compatibility with existing ones. We can migrate the
node modules if we need to, but the new system has be compelling enough for us
to do so.
We should identify the short comings of the
On Jun 27, 2012, at June 27, 20121:06 PM, Isaac Schlueter wrote:
I just disagree. I think it's fine if you like that style [one module
exports one thing], and you can use it. But we shouldn't force it on users.
I'm having trouble articulating why it is that module.exports=blah is
better
On May 10, 2012, at May 10, 20121:41 AM, David Bruant wrote:
Le 10/05/2012 04:44, Mikeal Rogers a écrit :
The core problem is that people who work nearly full time on designing a
language are necessarily out of touch with people using it, and the people
using it are ill equipped to balance
What is the goal of this?
If the goal is to get people to stop complaining, don't bother, people will
always complain. So long as there is a TC-39 there will be people that strive
to be armchair language designers and rail against any actual work.
The core problem is that people who work
On Jan 22, 2012, at January 22, 20121:35 PM, Jorge wrote:
. Not at all. Not only it doesn't clamp to 4ms (which happens to be a good
thing, IMO), but its timers often fire out of order !
node.js does not conform to the 4ms clamp because that would be silly. It does
not fire timers out of
I agree with every sentence in this post.
+1K :)
-Mikeal
On Nov 2, 2011, at November 2, 20119:05 AM, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
freeze does not add anything new to an object. If you don't want to change
the shape of an object ... don't change the shape of the object.
Again, immutability isn't just about security, but optimisation as well. You
could
HAHA!
You'll pry JavaScript from my cold dead hands!
-Mikeal
On Nov 2, 2011, at November 2, 201110:49 AM, Brendan Eich wrote:
On Nov 2, 2011, at 9:46 AM, Mikeal Rogers wrote:
I agree with every sentence in this post.
+1K :)
Switching to CoffeeScript? :-P
/be
-Mikeal
On Nov
On Nov 2, 2011, at November 2, 201110:57 AM, Brendan Eich wrote:
On Nov 2, 2011, at 9:51 AM, Mikeal Rogers wrote:
On Nov 2, 2011, at November 2, 20119:30 AM, Quildreen Motta wrote:
freeze does not add anything new to an object. If you don't want to
change the shape of an object
To bring the comments back around a little bit to this original proposal.
One thing I can't get over with this proposal is how obvious the syntax makes
the semantics. I didn't actually have to read any of the descriptions to figure
out how all of this works, my mind made a set of assumptions
This is a contrived case, but in general, because JS objects are mutable,
and when they're used as prototypes they stand in for class vtables,
something has to pay a price. Either you worry about checking on every
d.m(i) call that the cached target method in b is still the one to call, or
+1
to me, this is far more intuitive than the current proposal.
-Mikeal
On Oct 31, 2011, at October 31, 20116:57 PM, Jeremy Ashkenas wrote:
'Evening, ES-Discuss.
After poking a stick in the bees' nest this morning (apologies, Allen), and
in the spirit of loyal opposition, it's only fair
I would implore those doing this design work to offer greater weight to the
options of people who are *using* the language more than they are spending
their time on this list.
Users are generally under-represented on standards, we're lucky enough to have
some here, I would take their feedback
On Thu, Oct 6, 2011 at 5:08 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 4, 2011, at 10:52 AM, Mikeal Rogers wrote:
But, some of them simply double the semantics and syntax in the language
without a path to deprecate previous syntax. I'm a big fan of let, but if
you don't deprecate
Maybe it's time for me to chime in.
While I find it facilitating that so much meaning is being found in my tweet
I thought it might be productive to say what I actually meant by the
comment.
JavaScript's current (ECMA5) syntax has never prevented me from building an
application. I find
s/restructuring/destructuring
On Tue, Oct 4, 2011 at 6:52 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote:
Maybe it's time for me to chime in.
While I find it facilitating that so much meaning is being found in my
tweet I thought it might be productive to say what I actually meant
s/not taking as inspiration/now taking as inspiration
sorry for the typos, it's been a long hot day on this side of the world.
On Tue, Oct 4, 2011 at 6:56 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote:
s/restructuring/destructuring
On Tue, Oct 4, 2011 at 6:52 PM, Mikeal Rogers mikeal.rog
I was super confused as to why good tools and IDEs would require typing.
A bunch of typed languages do have great IDEs but I feel like that's mainly
because programming in a typed language can be considerably more difficult
which puts more emphasis on creating great tools to help deal with it.
I've used a few different javascript style guides over the years and the only
thing I can remember being consistent across all of them is that only
constructors get First letter casing.
I have to admit that the few times I've seen people using First letter casing
for non-constructors I've
We've talked about the problems that would come from this a lot in node.js.
One of the best comments I thought was from Jeremy Ashkenas (creator of
coffeescript).
http://groups.google.com/group/nodejs/browse_thread/thread/c334947643c80968/9533c06d486c10e6?lnk=gstq=jashkenas#9533c06d486c10e6
fibers turns node.js in to something the core team doesn't really view as being
node.js any longer.
we believe that it's more important to have assurances that your state can't
mutate between anything but a callback and that breaking that means you're
basically breaking node.
-Mikeal
On Sep
2, 20111:34 PM, Brendan Eich wrote:
On Sep 2, 2011, at 9:08 AM, Mikeal Rogers wrote:
fibers turns node.js in to something the core team doesn't really view as
being node.js any longer.
we believe that it's more important to have assurances that your state can't
mutate between anything
As for the application, reasoning about code that looks like hash-table
lookup but acts very different may not be better than reasoning about code
that looks like spaghetti but acts like you expect.
The two are not easy to trade off. Spaghetti is the bigger problem, IMHO,
since you can
this is going to get a little philosophical and not super technical so i apologize in advance.
i don't agree that expressiveness is necessarily a good thing. expressiveness comes with a cognitive overhead when reading and thinking about code, it's in your head, always. the more feature, the more
However, what if, rather than trying to consolidate legacy with
emerging (naive or otherwise) expectations of the languages evolution,
that focus is put instead upon a polysemetic interpreter, a common VM,
which language authors can utilise to their own ends (within
constraints), whereby the
do modern _javascript_ implementations actually "insert" semicolons?
i would assume that the parser would simply adhere to a set of rules when parsing in to an AST and those rules would govern what ends a particular statement, one of those rules being a semicolon.
Weak Maps seems to have superseded ephemeron tables.
They are non-enumerable, does this also exclude any call that gives you
an array of the current keys?
If this is the case then it excludes the primary use case we have in
node for ephemeron tables.
I can understand why you might want to
29 matches
Mail list logo
