gmane.comp.lang.javascript.ecmascript4.general

Array.prototype.search

Rich Walrath — 2012-05-26T04:26:13

Hello,

I've been playing around with an iterative array method I wrote earlier
today. I thought it would be a good idea to post it here and see wher

The idea behind this method is to search for the best match. It does this
by allowing you to specify a weighing function that calculates the best
result based by comparing two of the values at a time.

Here is a variant to the method I have been toying with:


Array.prototype.search = function( searchFn, scope ){
var len = this.length, i = 1, curr;

if(len === 0){ throw new TypeError("Length is 0 and no results are
possible."); }

curr = this[0];

for( ; i < len; i++ ) {
if( i in this && searchFn.call( scope, curr, this[i], i, this ) ) {
curr = this[i];
}
}

return curr;
};


For an example say you have a list of coordinates and you want to get the
largest x coordinate you would just do something like this:

var arr = [
{ x: 0, y: 124 },
{ x: 50, y: 34 },
{ x: -23, y: 85 },
{ x: 163, y: 40 },
{ x: 65, y: -20 }
];

arr.search( function(c,v,i,o){
return v.x > c.

Re: Arity checking?

Axel Rauschmayer — 2012-05-25T16:47:33


Yeah. I think I’m getting the hang of this. It is still conceivable to add development-time checks via a library (via a special module loader?).

Re: announcing normative ECMAScript specification in HTML

Axel Rauschmayer — 2012-05-25T16:01:19

Great! Suggestion: one file per chapter (faster, especially on mobile devices).

The TOC either in its own file or before the copyright information would be more convenient, too. I'd expect it to always be the starting point for browsing the spec.

[[[Sent from a mobile device. Please forgive brevity and typos.]]]

Dr. Axel Rauschmayer
axel-eYMr+fsL/EUb1SvskN2V4Q< at >public.gmane.org
Home: http://rauschma.de
Blog: http://2ality.com

On 24.05.2012, at 19:58, Allen Wirfs-Brock <allen-Lg0tYrq3bKnvQC8VwISyQA< at >public.gmane.org> wrote:

_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const classes for max/min

Allen Wirfs-Brock — 2012-05-25T15:40:19

On May 24, 2012, at 1:50 PM, Erik Arvidsson wrote:


I'm actually rather this disinclined to play this game.  As soon as you put "const" in front of "class" you have a whole new construct within which you can define pretty much any syntax and semantics you want as long as you think users will find them acceptable. Hence there is very little need to "prove" anything here.

But, who can resist a design challenge...

The specification framework is all in place to support this.  Objects created via a const class constructor could be an alternative version of [[Get]] (http://ecma-international.org/ecma-262/5.1/#sec-8.12.3  remember to say "thank you Jason") that throws in step 2.  


lots of ways to approach this, but a simple way to prevent a value from escaping is simply to not provide any way to reference it.   Hence, don't bind |this| in the body of a const constructor. Provide an alternativenon value producing way to refer to the uninitialized instance within the constructor body.  For example, __this__ (I'

Re: Arity checking?

Brendan Eich — 2012-05-25T15:05:53

How would that work? It's impossible under 1JS.


Don't violate 1JS!

/be

Arity checking?

Axel Rauschmayer — 2012-05-25T07:21:26

I was under the impression that ECMAScript.next was going to perform arity checking. But looking at the proposals and the draft spec, it doesn’t look like it.

I can see pros and cons either way. I take it that the rationale was to not do things too differently(?) It would indeed be weird to perform arity checking only in the presence of parameter default values and/or rest parameters. Conditionally switching it on (e.g. via a pragma) does seem an option, though.

Re: const classes for max/min

Brendan Eich — 2012-05-25T14:29:57

Don't bring up proxies as a solution here! Direct proxies require target 
objects, which are both irrelevant and unacceptably high overhead.

/be

Re: Generators improvement idea

Rick Waldron — 2012-05-25T12:29:45


This approach expects all future readers of my code to look deep into the
function definition to locate a "yield return", instead of the conveniently
placed asterisk. Someone else mentioned this here:
https://github.com/JSFixed/JSFixed/issues/72#issuecomment-5820333





vs. the significantly less crowded:

function* counter() {
  var i = 0; yield i++;
}





Certainly you don't think piling more semantics on top of continue is a
better choice?



Rick




_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const classes for max/min

Axel Rauschmayer — 2012-05-25T09:31:31

Couldn’t #1 (optionally) be handled via a proxy and #2+#3 via static analysis?

On May 24, 2012, at 22:50 , Erik Arvidsson wrote:

Re: Generators improvement idea

François REMY — 2012-05-25T09:10:54

While we're at it, I had an idea to allow to avoid the function*() {} 
syntax: why not "yield [noLineTerminator] return" ?

Since "return" is a reserved word which can only appear as first token of an 
instruction, enforcing [noLineTerminator] makes sure any recognized use of 
'yield return' in ES6 would not be valid in ES5. Also, yield can continue to 
be used anywhere else as a variable, if needed.

Code sample :

    function counter() {
        var i = 0; yield return i++;
    }

Another variant would be :

    function counter() {
        var i = 0; continue return i++;
    }

Re: Array.prototype.take

Strager Neds — 2012-05-25T06:47:35

[1,2,3,4,3,2,1].takeWhile((x) => x < 4)
=> [1,2,3]

correct?

(I use 'takeWhile' here because it is what functional languages use
[1]; 'take' takes a fixed number of elements from a list.)

This is not the same as map+filter.  (I'm not sure how map even would
come into play; you're not transforming the data at all.)

Strawman implementation (without TypeErrors), if I understand correctly:

function takeWhile(pred, thisp) {
    var i;
    for (i = 0; i < this.length; ++i) {
        if (i in this) {
            var continue_ = pred.call(thisp, this[i], i, this);
            if (!continue_) {
                // Return all elements before this one.
                return this.slice(0, i);
            }
        }
    }

    return this.slice();  // Clone.
}

If takeWhile is included, it makes sense to me that its complement,
dropWhile, should also be included.  (Simply replace .slice(0, i) with
.slice(i), I think.)

And x.span(a, b) => [x.takeWhile(a, b), x.dropWhile(a, b)] to complete the set.

[1]: http://hacka

Re: Generators improvement idea

Brendan Eich — 2012-05-25T02:52:07

This does not work -- yield must be a special form that the compiler can 
see. An arbitrary call through a funarg cannot be presumed to 
maybe-yield without imposing unacceptable performance costs on all 
non-yield calls out of generator bodies.

/be

Irakli Gozalishvili wrote:

Re: Array.prototype.take

Axel Rauschmayer — 2012-05-25T01:37:42

Sorry. Right. You want a combination of filter and map.

On May 25, 2012, at 3:32 , Irakli Gozalishvili wrote:

Re: Array.prototype.take

Irakli Gozalishvili — 2012-05-25T01:32:58

Well some returns `true` or `false` I was talking more about taking slice of an array. You could obviously do things with an elements in `some` but it feels very wrong to push them into another array.  


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/


On Thursday, 2012-05-24 at 18:00 , Axel Rauschmayer wrote:



_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.take

Axel Rauschmayer — 2012-05-25T01:00:00


You can use Array.prototype.some for that purpose:

    function breakAtEmptyString(strArr) {
        strArr.some(function (elem) {
            if (elem.length === 0) {
                return true; // break
            }
            console.log(elem);
            // implicit: return undefined (interpreted as false)
        });
    }


Agreed. The ability to chain iterators would be cool. IIRC, there are plans for a module of iterator tools.

Array.prototype.take

Irakli Gozalishvili — 2012-05-25T00:42:43

Hi, 

At the moment Array methods can do almost everything that one can do with plain `for` iteration, only missing piece is `break`. 
Is there any chance to get something like:

array.take(predicate) 

Although, `take` would be way more useful if array methods chains were applied lazily. So that:

array.filter(predicate).map(fn).take(once) would only call `fn` up to a first match.

Maybe `Array.prototype.take` is not a best fit, but would be great if we could get at least something to cover
lack of `break`.

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Generators improvement idea

Irakli Gozalishvili — 2012-05-25T00:29:28

Hi, 

I have an improvement suggestion for generators. Unless I'm mistaken in spider monkey you
`yield` maybe used as a function:

function g() {
 yield(1)
 yield(2)
}


for (let $ in g()) console.log($)


It would be cool to take this even further and let users give `yield` a context specific name. 


// yield is passed in
function* program(require) {
  // maybe even alias passed in yield 
  var use = require;

  var _ = require('underscore')
  var template = require('asset!./template.html')
  var data = require('asset!./model.json')

  document.body.innerHTML = _.template(template, data) 
}

This would loading all assets async but avoid callbacks 

This is idea came to mind while thinking how SDK APIs that users commonly complain
about can be improved (At the moment it web worker like). There are some more examples

in the "more thoughts" section of the following document:
https://github.com/mozilla/addon-sdk/wiki/JEP-Content-scripts

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/

_______

Re: const classes for max/min

Rick Waldron — 2012-05-24T22:28:15

On Thursday, May 24, 2012 at 5:36 PM, Russell Leggett wrote:  

Agreed 100%, especially considering the favorable consensus appears to be in the majority now.  


I may be in left field here, but what stops:  

class C {
  f = "foo";
   
  constructor() {
    
  }
}


From desugaring to:

function C() {}

C.prototype.f = "foo";


I looked through as many of the class related proposals and couldn't find anything that disproved this possibility

Rick


_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

Re: const classes for max/min

Russell Leggett — 2012-05-24T21:36:11


Yes, I would really like to see some more elaboration from him. I guess
we'll have to wait for his return. One of the things that I was trying to
show was that the max/min proposal is not future hostile, whether or not
these things happen now, especially if it is not the default. I really just
don't want classes to be blocked.

- Russ


_______________________________________________
es-discuss mailing list
es-discuss-4eJtQOnFJqFAfugRpC6u6w< at >public.gmane.org
https://mail.mozilla.org/listinfo/es-discuss

"strict mode" |with| proposal

Aymeric Vitte — 2012-05-24T21:22:39

Draft is here : https://gist.github.com/edd064e5b29e67ebe493

Maybe everything is not accurate regarding some comments and annex 
should include other examples but, before writing more, let's submit it

As mentionned in the gist, it is supposed to address several topics : 
security and wrapping, modules, multiple globals, VMs and proxies

It did not come up just this morning, it can be called a |with| 
"nothing" proposal, |with| is not light in specs and rarely used, it was 
eliminated in strict mode (even if some non strict/strict mode 
combinations use it, see recent cajaVM analysis) but maybe strict mode 
can give it another meaning.

The concept is simple and based on the implementation of VMs where if 
you have to pass something to |with| or other, then it's totally 
impossible to separate it completely from the initial scope (see annex)

There is a disruptive assignment floating in the |with|'s code : 
"this=window" (which then sets the ThisBinding and associated var 
bindings), which has to follow som

Re: announcing normative ECMAScript specification in HTML

T.J. Crowder — 2012-05-24T21:00:39

Hi,

That's fanTAStic about finally having a normative, deeply-linkable, HTML
edition of the spec.

On 24 May 2012 19:13, Allen Wirfs-Brock <allen-Lg0tYrq3bKnvQC8VwISyQA< at >public.gmane.org> wrote:


Yes, but given the significant (and welcome) effort to keep section numbers
the same version-on-version, rather than having all links to 5.1 rot (e.g.,
become out of date) as of 5.2, it would be very useful to have
pseudo-targets that represent:

* The latest 5.x

* The latest, period

So for instance:

http://ecma-international.org/ecma-262/5.1/#sec-4.3.2

...links to Section 4.3.2 of Edition 5.1, but

http://ecma-international.org/ecma-262/5/#sec-4.3.2

...links to Section 4.3.2 of whatever the latest 5.x is, and

http://ecma-international.org/ecma-262/#sec-4.3.2

...links to Section 4.3.2 of whatever the *current* standard is.

Separately, ideally, with not just section names, but
semantically-intelligent targets. For instance, while it would be nice if

http://ecma-international.org/ecma-262/#sec-4.3.2

...alwa