On Sep 6, 2011, at 1:07 PM, Dean Landolt wrote:
> I didn't see this line of reasoning -- I thought your main point was that
> `generator` was grammatically ambiguous. My apologies if this was so obvious
> as to be implied, but in any event, it was a trivial little nit begging for a
> stronger r
On Tue, Sep 6, 2011 at 2:37 PM, Brendan Eich wrote:
> On Sep 6, 2011, at 9:47 AM, Dean Landolt wrote:
>
> We considered that, but generator is not reserved, and reserving it in ES6
>> requires newline sensitivity at least. Consider an anonymous generator
>> similar to the one you typed:
>>
>> g
On Sep 6, 2011, at 9:37 AM, John J Barton wrote:
> On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich wrote:
> Generators share with private name objects a right-sized (minimal but not too
> small) gap-filling quality that supports all of:
>
> * prompt standardization,
> * interoperable implementati
On Sep 6, 2011, at 10:10 AM, Dean Landolt wrote:
> On Tue, Sep 6, 2011 at 12:37 PM, John J Barton
> wrote:
>
> I was more thinking along the lines of better support for async programming
> that does not attempt to look sync (I have no idea what that means).
>
>
> I'm also curious what "bett
On Sep 6, 2011, at 9:47 AM, Dean Landolt wrote:
> We considered that, but generator is not reserved, and reserving it in ES6
> requires newline sensitivity at least. Consider an anonymous generator
> similar to the one you typed:
>
> generator()
> {...}
>
> where ... is actual code (and th
On Tue, Sep 6, 2011 at 12:37 PM, John J Barton
wrote:
>
>
> On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich wrote:
>
>> On Sep 5, 2011, at 9:36 PM, John J Barton wrote:
>> ...
>>
>> Assuming I am understanding the idea, then my description above is also my
>> criticism: control and data flow is jum
On Tue, Sep 6, 2011 at 2:01 AM, Brendan Eich wrote:
> On Sep 5, 2011, at 9:36 PM, John J Barton wrote:
>
> On Sun, Sep 4, 2011 at 1:42 PM, Brendan Eich wrote:
>
>> On Sep 4, 2011, at 11:06 AM, John J Barton wrote:
>>
>> As a reader I have to parse the function carefully to look for the
>> 'yield
On Mon, Sep 5, 2011 at 11:01 PM, Brendan Eich wrote:
> On Sep 5, 2011, at 9:36 PM, John J Barton wrote:
> ...
>
> Assuming I am understanding the idea, then my description above is also my
> criticism: control and data flow is jumping around in unusual ways and
> functions morph into multi-entry
On Sep 5, 2011, at 9:36 PM, John J Barton wrote:
> On Sun, Sep 4, 2011 at 1:42 PM, Brendan Eich wrote:
> On Sep 4, 2011, at 11:06 AM, John J Barton wrote:
>
>> As a reader I have to parse the function carefully to look for the 'yield'.
>> If I find one, then I know that this is not actually a f
On Sun, Sep 4, 2011 at 1:42 PM, Brendan Eich wrote:
> On Sep 4, 2011, at 11:06 AM, John J Barton wrote:
>
> As a reader I have to parse the function carefully to look for the 'yield'.
> If I find one, then I know that this is not actually a function after all.
> Then I need to mentally draw a lin
On Sep 3, 2011, at 12:19 PM, Dean Landolt wrote:
> On Sat, Sep 3, 2011 at 7:15 AM, Jorge wrote:
> On 02/09/2011, at 18:08, 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 impor
On Sep 4, 2011, at 11:06 AM, John J Barton wrote:
> As a reader I have to parse the function carefully to look for the 'yield'.
> If I find one, then I know that this is not actually a function after all.
> Then I need to mentally draw a line after the yield and label it "entry-point
> #2".
Th
On Fri, Sep 2, 2011 at 4:39 PM, Brendan Eich wrote:
> On Sep 2, 2011, at 4:15 PM, John J Barton wrote:
>
> Ok I hope someone creates more tutorial information about generators. I
>> read about them and played around with some examples, but I did not come
>> away thinking positive.
>>
>
> You migh
While I tend to use vocabulary more loosely than those who associate a
model or structure to a programming language I am sorry for any
confusion.
Actors : http://en.wikipedia.org/wiki/Actor_model
>From my standpoint the idea of event emitters using callbacks the
callbacks are being treated as act
On Sep 6, 2011, at 12:12 AM, Dmitry Soshnikov wrote:
> On 03.09.2011 3:39, Brendan Eich wrote:
>>
>> On Sep 2, 2011, at 4:15 PM, John J Barton wrote:
>>
>>> Ok I hope someone creates more tutorial information about generators. I
>>> read about them and played around with some examples, but I di
On Sat, Sep 3, 2011 at 7:15 AM, Jorge wrote:
> On 02/09/2011, at 18:08, 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
On 03/09/2011, at 02:12, Brendan Eich wrote:
> On Sep 2, 2011, at 3:01 PM, Bradley Meck wrote:
>
>> Even worse, libraries must support this, similar to
>> how a few libraries that break when a script in strict mode invokes
>> them but unlike frowned upon features,
>
> Strict mode is a static prop
On 02/09/2011, at 18:08, 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 but a callback and that breaking tha
On 03.09.2011 3:39, Brendan Eich wrote:
On Sep 2, 2011, at 4:15 PM, John J Barton wrote:
Ok I hope someone creates more tutorial information about
generators. I read about them and played around with some
examples, but I did not come away thinking positive.
You might start with D
On Sep 2, 2011, at 5:16 PM, Mikeal Rogers wrote:
>>
>> Ok, my b.s. detector is going off. You used "actors" in the first para about
>> Node, but Node is JS and JS (or Mikeal's favorite subset used in Node
>> built-in and approved libraries) is not an Actor language.
>
> My ability to dictate s
>
> Ok, my b.s. detector is going off. You used "actors" in the first para about
> Node, but Node is JS and JS (or Mikeal's favorite subset used in Node
> built-in and approved libraries) is not an Actor language.
My ability to dictate style in core is close to zero, if I could we wouldn't be
On Sep 2, 2011, at 3:01 PM, Bradley Meck wrote:
> Even worse, libraries must support this, similar to
> how a few libraries that break when a script in strict mode invokes
> them but unlike frowned upon features,
Strict mode is a static property of code. Strict callers cannot affect behavior
of
>>
>> 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,
> sin
In case someone is interested I've experimented with proxy sugared promises (it
was long time ago some few things might require updates):
https://github.com/Gozala/meta-promise
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France (h
On Sep 2, 2011, at 4:15 PM, John J Barton wrote:
> Ok I hope someone creates more tutorial information about generators. I read
> about them and played around with some examples, but I did not come away
> thinking positive.
You might start with Dave Herman's async library, task.js:
https://git
On Fri, Sep 2, 2011 at 3:48 PM, Brendan Eich wrote:
> On Sep 2, 2011, at 2:26 PM, John J Barton wrote:
>
> I'm pretty puzzled by this discussion and I'm guessing other folks might be
> puzzled as well. Since I understood node fibers as "thread for Node", the
> discussion I read is:
>
>/be: Yo
On Sep 2, 2011, at 2:26 PM, John J Barton wrote:
> I'm pretty puzzled by this discussion and I'm guessing other folks might be
> puzzled as well. Since I understood node fibers as "thread for Node", the
> discussion I read is:
>
>/be: You can have threads!
I did not say that. Remember, thr
Node has shared memory between actors, having multiple async code
flows executed on shared memory that appear to be sync by design is
very hard to do. This leads to implementation specific behavior unless
we standardize edit resolution. Most people who complain about nested
callbacks generally forg
On 03.09.2011 1:26, John J Barton wrote:
I'm pretty puzzled by this discussion and I'm guessing other folks
might be puzzled as well. Since I understood node fibers as "thread
for Node", the discussion I read is:
/be: You can have threads!
Mikeal: We don't want threads!
If I'm on the ri
I'm pretty puzzled by this discussion and I'm guessing other folks might be
puzzled as well. Since I understood node fibers as "thread for Node", the
discussion I read is:
/be: You can have threads!
Mikeal: We don't want threads!
If I'm on the right track, then I should understand how this
On Sep 2, 2011, at 1:45 PM, Mikeal Rogers wrote:
> We have no control over what v8 adds or what happens in Harmony.
>
> We do have control over what we use in node.js core and the patterns we drive
> forward in the community.
>
> We already don't use a lot of the features in the language and we
We have no control over what v8 adds or what happens in Harmony.
We do have control over what we use in node.js core and the patterns we drive
forward in the community.
We already don't use a lot of the features in the language and we're happy with
that.
-Mikeal
On Sep 2, 2011, at September 2
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 but a callback and that breaking
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
Besides, IIRC, there is a module for Node called node-fibers, which
introduces possibility of `yiled` for V8 (though, the implementation
differs from (standard) `yield` from SpiderMonkey).
And for the topic starter -- in ES6 it's planned to standardize `yield`
feature which will allow to have
There is already a Node module that uses Proxies as a way of enforcing
promises:
https://github.com/sam-mccall/node-plate
It allows your to write:
var pfs = plate(fs);
pfs.writeFile('/etc/passwd.bak', pfs.readFile('/etc/passwd'));
pfs.end(function(err) { if(err) throw err; console.log("It's save
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=gst&q=jashkenas#9533c06d486c10e6
-M
Hi,
I'm just a lambda JavaScript programmer who loves building black boxes
with the smallest APIs possible and a couple of hours ago, I found out
Proxys existed and since then, I've been watching talks and reading
articles about them. And it sure looks awesome.
But there's one thing I didn't get:
38 matches
Mail list logo
