I still think we have different definitions of stable :-) I only mean
"should not crash and burn, and if crashes and burns --- please
report". You seem to imply "follows latest draft, is not going to
change" as well. Surely by this definition --harmony is not stable, it
might not be up to date and it will change, just like the draft
itself.
It is highly unlikely (though I can't predict the future) that any
part of --harmony will be moved out from under the flag before final
standard is released.
> Map and Set are missing their iterator APIs completely,
There was no iterator api specified at harmony:simple_maps_and_sets
when V8 implemented them. Erik Arvidsson amended the wiki only a month
ago.
> let is only allowed with the "use strict" prologue...
Which AFAIK was perfectly aligned with old opt-in story (aka extended
mode); opt-in however was dropped in favor of 1JS.
> ES module syntax support appears and disappears (when it is available, module
> identifiers are assigned as undefined),
Fair point. I don't think modules were ever declared working and I am
not sure why --harmony implies --harmony-modules. Need to ask Andreas
about that (he is working on finishing the implementation afaik).
> Strings don't hold any shared references in JavaScript
Yes, they don't. But objects hold strings. obj = {foo:0} holds "foo".
Fortunately spec foresaw these complications and forbade using
primitives as keys as Brandon points out.
--
Vyacheslav Egorov
On Sun, Jul 8, 2012 at 4:35 PM, Rick Waldron <[email protected]> wrote:
>
> On Sunday, July 8, 2012 at 9:15 AM, Vyacheslav Egorov wrote:
>
> Apparently we define 'stable' differently.
>
> Probably not, but I think you've misunderstood the --harmony flag and while
> doing so, you've decided to argue with me about it.
>
>
> It is behind the flag because it is from the next non-finalized JS standard,
>
> Yes, I know, I'm _very_ familiar with "the next non-finalized JS standard".
>
>
> not because it is crashy or buggy.
>
> Actually, this is _exactly_ what it's for; Map and Set are missing their
> iterator APIs completely, ES module syntax support appears and disappears
> (when it is available, module identifiers are assigned as undefined), let is
> only allowed with the "use strict" prologue... There's more and I think we
> both agree that these issues are "unstable" and "buggy".
>
>
>
> As for string keys: I thought you are proposing to use weakmap like that
> here, sorry I misunderstood.
>
> To clarify, I meant that each scope object could be added as a key to a
> WeakMap with the cache object as it's value instead of the object dance it
> does now - which would avoid hasOwnProperty checks and object reference
> leaks.
>
> Implementation has no problem with them (so nothing to report) but
> primitives can be shared in unexpected ways (e.g. two objects with the
> property foo hold the same instance of string 'foo'.)
>
> Strings don't hold any shared references in JavaScript, but I'm interested
> in seeing the code you're describing.
>
> so one should always keep that in mind, because value will never be released
> if key is strongly reachable.
>
> Yes, this is exactly the point of a WeakMap
>
>
> Rick
>
> Vyacheslav Egorov
>
> On Jul 8, 2012 2:53 PM, "Rick Waldron" <[email protected]> wrote:
>
>
> On Sunday, July 8, 2012 at 6:05 AM, Vyacheslav Egorov wrote:
>
> WeakMap/Map/Set are available in V8 for quite some time. You just need to
> run with --harmony.
>
>
> I'm not sure I understand what the point your trying to make is. I said
> "stable v8" which is meant to imply "not behind a flag". If there are "hard
> to explain memory leaks", that's a bug and should be reported.
>
> Why would you use a WeakMap for use case that required strings as keys? This
> is like using a chainsaw to cut bread.
>
> Rick
>
> (Though storing anything in a WeakMap with a string key might lead to a hard
> to explain memory leaks).
>
> Vyacheslav Egorov
>
> On Jul 7, 2012 6:28 PM, "Rick Waldron" <[email protected]> wrote:
>
>
>
> On Saturday, July 7, 2012 at 10:28 AM, Mariusz Nowak wrote:
>
> This is the use case we were missing, you want to do same thing I've once
> tried to do in domjs https://github.com/medikoo/domjs
> Currently I think there's no better solution than polluting global scope.
> In domjs I resolved it by introducing dynamic scope (
> https://github.com/medikoo/domjs/blob/master/lib/dscope.js ).
>
>
> This is a good use case for WeakMaps; they aren't available in v8 stable
> yet, but would eliminate the leaky references that could be held in the
> current implementation.
>
> Rick
>
>
>
>
> but it's not great approach as variable assignments live only during
> function execution, and that's confusing. I think best solution would to be
> have possibility to run modules in some predefined lexical scope, but it's
> not that easy to achieve.
>
> On Saturday, July 7, 2012 3:55:26 PM UTC+2, ajlopez wrote:
>
> Thanks!
>
> I usually do in your suggested way, and I'm with you. But in this special
> case, I feel the user of my module could find a bit weird to write
>
> var st = require('simpletags');
>
> st.html(st.head(st.title('...')), st.body(st.h1(....))
>
> instead
>
> html(head(title('....')), body(h1('...'))
>
> in a controlled way (only in its own module). I want to give him/her an
> option. Ruby has it (as an option, too). It's the first time I found I
> needed it in Node.js. Usually, I assert "Ruby ceremony > Javascript/Node.js
> ceremony", but now, I was trapped by this issue.
>
> My best solutions:
>
> a)
> var st = require(...); // and use with st.h1, st.h2...
>
> b)
> require('simpletags').exportsTo(global); // maybe in browser I could export
> to windows directly in the module
>
> c)
> var simpletags = require('simpletags');
> eval(simpletags.exportLocalCode()); // where .exportLocalCode returns a
> String with "var h1 = simpletags.h1; ... "
> c2)
> var st = require('simpletags');
> eval(st.exportLocalCode('st')); // the local variable name 'st' should be
> informed to be used in var ...= .... string result
>
> On Sat, Jul 7, 2012 at 10:38 AM, Mariusz Nowak <[email protected]> wrote:
>
> In modules you can achieve the same by assigning function to global: e.g.
> `global.foo = function () { .. }` it will work same as `this.foo = function
> () { ... }` in REPL. but I would strongly discourage this, relying on global
> scope is bad practice.
>
> I'd say that unless you're using regular require/export logic to share
> objects between modules, you're doing something wrong. Try to think just
> with require/exports and then you should quickly find way home. See how
> module relations in other packages work.
>
> --
> Mariusz Nowak
> https://github.com/medikoo
> http://twitter.com/medikoo
>
>
> On Saturday, July 7, 2012 3:18:51 PM UTC+2, ajlopez wrote:
>
> Thanks for the suggestion!.... but... I missing some part of your answer.
>
> I guess I understand the difference btw global, this.property, and var
> local. And then, I understand why it not works. What I don't understand is
> how to circumvent/solve the problem. I don't know if your answer is:
>
> a- " you'll get the answers :) " and then, you will know that it's
> impossible to solve, or too weird
> b- you'll get the answers :) " and it's possible in this (simple)
> way.....etc...
>
> AFAIK, it's "a". Am I right?
>
> My problem is:
>
> - module1 requires module2
> - I want to use the exposed functions of module2 as they were defined in
> module1, using dynamic names. That is, it's not a solution
>
> var module2 = require('module2');
> var Function2 = module2.Function2;
>
> Usually, I did a bit of experiment at REPL. I found that this works:
>
> var name = 'Function2';
> this[name] = ...
>
> var obj = new Function2(); // without using this
>
> BUT it's only works at REPL. So, encouraged by this discovery (I expected it
> will not work), I hoped to make it works in other context.
>
> Now, I understand why it is work in REPL. Notably, in REPL
>
> this == global
>
> so it's possible to emulate
>
> var foo = ...
>
> with something like (pseudocode)
>
> name = 'foo'
> var [name] = .....
>
> writing
>
> name = 'foo';
> this[name] = ...
>
> and then foo is available "as if it is" a local var.
>
> But inside a running .js, this is not equal to global. I was tricked by REPL
> ;-)
>
> So, the better solution I found so far is to put something like this in
> module1:
> //
> http://stackoverflow.com/questions/5625569/include-external-js-file-in-node-js-app
>
> var fs = require('fs');
> var vm = require('vm');
>
> var includeInThisContext = function(path) {
> var code = fs.readFileSync(path);
> vm.runInThisContext(code, path);
> }.bind(this);
>
> includeInThisContext(__dirname + '/module2.js');
>
> console.log(foo); // it's defined
>
> where module2 define foo:
>
> foo = {};
>
> BUT IN MY CASE, module2 doesn't define the functions at its own context:
> https://github.com/ajlopez/SimpleTags/blob/master/lib/simpletags.js
> it uses an array to dynamically define and export functions. I never have
>
> function h1() {
> }
>
> function h2() {
> }
>
> defined at module2 context. And I don't want this. My DSL defines a function
> for each HTML tag.
>
> Now, I want to have these dynamically defined functions from module2
> accessible in outer module1, as they were local to it.
>
> I could write inside my module,
>
> var h1 = makeTag('h1');
> var h2 = makeTag('h2");
> ...
> ....
>
> for dozens of tags, and then use something like includeInThisContext.... but
> I feel it's too weird.
>
> Apparently, my problem is: I didn't find a way to define a local var with a
> dynamic name.
>
> The original DSL in Ruby:
> https://github.com/dlitvakb/deklarativna/blob/master/test/test_deklarativna.rb
>
> use "include dslmodule". And inside the dsl module, it defines dynamically
> named functions at module top level. So the functions are automatically
> available to the module that makes the includes.
>
> That is the "trick" I didn't found how to emulate in
> Node.js/require/CommonJS world.
>
> Some links in my research:
> http://stackoverflow.com/questions/5833978/javascript-how-to-use-dynamic-local-variables
> http://stackoverflow.com/questions/5094862/how-do-i-access-a-local-variable-dynamically-via-a-string-form-of-its-name-fro
> http://stackoverflow.com/questions/598878/how-can-i-access-local-scope-dynamically-in-javascript
> http://stackoverflow.com/questions/2336508/javascript-get-access-to-local-variable-or-variable-in-closure-by-its-name
> http://stackoverflow.com/questions/1119335/javascript-local-variable-declare
>
> The better approach I found in these links is to use eval (!!??):
> eval("var "+name+ " = ....");
>
> Am I right? the only ways are the above ones? Or is another way?
>
> Any suggestions?
>
> Angel "Java" Lopez
>
>
> On Sat, Jul 7, 2012 at 9:27 AM, Mariusz Nowak <[email protected]> wrote:
>
> @ajlopez get to know how variable scoping in JavaScript works (what is
> global, how this and how local variable works), and you'll get the answers
> :)
>
>
> On Saturday, July 7, 2012 2:11:56 PM UTC+2, ajlopez wrote:
>
> Hi people!
>
> A very simple question. When I write in the Node repl:
>
> this.foo = 'bar';
> console.log(foo);
>
> it's ok, foo is defined. But writing that code in file.js and running
>
> node file.js
>
> then foo is not defined.
>
> Or require('file.js'), then foo is not defined.
>
> Any way to define a variable in the "current context"? Apparently, "this"
> properties and "current context" top variables are the same in REPL, but
> they are not the same in .js, or inside a required module.
>
> I want to do this in a dynamic way:
>
> name = 'foo';
> // ...
> this[name] = 'bar';
>
> so
>
> foo = 'bar';
>
> is not a solution in my context.
>
> I could use:
>
> global[name] = 'bar';
>
> but I want to expose the new "current context" top variables only in my
> "current context" without pollute the global environment.
>
> I encountered this problem when coding a simple HTML DSL:
> https://github.com/ajlopez/SimpleTags/blob/master/test/exportsTo.js
> I want the DSL functions to be accesible as:
>
> require('simpletags').exportsTo(????); // ???? == global? this? Now, I
> should use global to make it works in any situation
>
> then, use the exported function as functions in current context:
>
> html(body(h1("TheNextBigThing")));
>
> instead
>
> var st = require("simpletags");
>
> st.html(st.body(st.h1("TheNextBigThing")));
>
> Any other way?
>
> TIA
>
> Angel "Java" Lopez
> http://ajlopez.wordpress.com
> @ajlopez
> gh:ajlopez
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
