Re: AND and OR in if statement

2016-05-25 Thread Caitlin Potter 
Devils advocate: if you were to measure usage of identifiers named “and” or 
“or”, on the web, how substantial do you think their use would be? And even if 
they were used a fair bit, that hasn’t really stopped the introduction of other 
contextual keywords in the past.

If you really wanted to, you could find a way to make this work. But I’m not 
saying we need to turn JS into Python or Perl.

> On May 25, 2016, at 7:20 PM, Rick Waldron  wrote:
> 
> This is a non-starter, as AND and OR are already valid identifiers.
> 
> On Tue, May 24, 2016 at 9:15 PM Francis Clavette  > wrote:
> Hi,
> I’d like to be able to use AND for && and OR for || in conditional statements 
> in a future version of ECMAScript. It’s a feature I’ve always been wanting 
> since transitioning from PHP. It’s also much cleaner :
> 
> if ($scope.newSourceModal.isShown() && $scope.newsource.type == "book" && 
> (!$scope.insertingFromScan || $scope.ok))
> 
> ==
> 
> if ($scope.newSourceModal.isShown() AND $scope.newsource.type == "book" AND 
> (!$scope.insertingFromScan OR $scope.ok))
> 
> 
> Francis
> ___
> es-discuss mailing list
> es-discuss@mozilla.org 
> https://mail.mozilla.org/listinfo/es-discuss 
> 
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: AND and OR in if statement

2016-05-25 Thread Rick Waldron 
This is a non-starter, as AND and OR are already valid identifiers.

On Tue, May 24, 2016 at 9:15 PM Francis Clavette 
wrote:

> Hi,
> I’d like to be able to use AND for && and OR for || in conditional
> statements in a future version of ECMAScript. It’s a feature I’ve always
> been wanting since transitioning from PHP. It’s also much cleaner :
>
> if ($scope.newSourceModal.isShown() && $scope.newsource.type == "book" &&
> (!$scope.insertingFromScan || $scope.ok))
>
> ==
>
> if ($scope.newSourceModal.isShown() AND $scope.newsource.type == "book"
> AND (!$scope.insertingFromScan OR $scope.ok))
>
>
> Francis
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: importing selected chucks of a module into an object

2016-05-25 Thread Isiah Meadows 
Even with some larger libraries, you can do things like this:

```js
// small modules

import xmlParse from 'xml/parse';
import xmlCreate from 'xml/create';
import xmlSandwich from 'xml/sandwich';

import jsonParse from 'json/parse';
import jsonCreate from 'json/create';
import jsonBacon from 'json/bacon';

import htmlParse from 'html/parse';
import htmlCreate from 'html/create';
import htmlOrange from 'html/orange';
```

Lodash is a good example of this - check out its `lodash-es6` build, or the
various examples using `lodash/isArray`, `lodash/map`, `lodash/match`, etc.

I'm of the school of thought that I'm fine using smaller modules, but why
depend on `foreach`, `array-map`, and `is-array` separately when you can
depend on `lodash`, and just import `lodash/forEach`, `lodash/map`, and
`lodash/isArray`? If I can get the same functionality with fewer
dependencies, using modules likely to be reused by other modules because
the versions are compatible, I'm all for it. Even if it comes with extra
stuff, that extra stuff won't make it into a Browserify or Rollup bundle.

On Wed, May 25, 2016, 03:48 Norbert de Langen 
wrote:

> Small modules are great, especially for creators. I’m onboard with
> small-modules being the default and recommended way of doing things.
>
> But.. I think history has shown that there is a use-case and a place in
> the world for larger composed modules. Take a look at lodash or jQuery for
> example.
>
> From a consumer point of view larger / composed modules make a lot of
> sense. A ‘higher order module’ if you will.
>
> Here’s the author of roll-up making a case for such modules as well:
> https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4#.hczbjni3t
>
>
>
> When dealing with many dependencies (for whatever reason) or just
> dependencies that are really related, it’s nice to not have to do this:
>
> ```
>
> // small modules
>
> import xmlParse from 'xml-parse';
>
> import xmlCreate from 'xml-create';
>
> import xmlSandwich from 'xml-sandwich';
>
> import jsonParse from 'json-parse';
>
> import jsonCreate from 'json-create';
>
> import jsonBacon from 'json-bacon';
>
> import htmlParse from 'html-parse';
>
> import htmlCreate from 'html-create';
>
> import htmlOrange from 'html-orange';
>
>
>
> // over
>
> import { parse, create, sandwich } as xmlUtil from 'xml-util';
>
> import { parse, create, bacon } as jsonUtil from 'json-util';
>
> import { parse, create, orange } as htmlUtil from 'html-util';
>
> ```
>
>
>
> *From: *Jordan Harband 
> *Date: *dinsdag 24 mei 2016 21:23
> *To: *Norbert Langen 
> *Cc: *"Tab Atkins Jr." , "es-discuss@mozilla.org" <
> es-discuss@mozilla.org>
> *Subject: *Re: Proposal: importing selected chucks of a module into an
> object
>
>
>
> This is usually part of the reason why small modules are recommended,
> rather than large object bags of things (including many named exports).
> Have you considered putting each thing you want to import as the default
> export of a separate file?
>
>
>
> On Tue, May 24, 2016 at 9:20 PM, Norbert de Langen <
> norbert.de.lan...@macaw.nl> wrote:
>
> I think there’s a preference reason for this but also optimization reasons.
>
> For humans it becomes crystal clear exactly what parts are dependent on. I
> personally like this.
>
> When importing the entire module the module code needs to be run to figure
> out what parts are not needed. Eliminating the possibility of tree-shaking
> I believe.
>
>
> On 24-05-16 21:06, "Tab Atkins Jr."  wrote:
>
> >On Tue, May 24, 2016 at 11:59 AM, Norbert de Langen
> > wrote:
> >> It would be nice to have this option:
> >>
> >> ```
> >> import { parse } as xmlLib from 'xml-lib';
> >> import { parse } as jsonLib from 'json-lib';
> >> import { parse } as htmlLib from 'html-lib';
> >>
> >> // usage
> >> xmlLib.parse();
> >> jsonLib.parse();
> >> htmlLib.parse();
> >> ```
> >
> >This begs the question, tho - why do you only need to import selected
> >chunks? If you're pulling in the module as a namespace object, how
> >does having the *rest* of the module available harm you?
> >
> >~TJ
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.getOwnPropertyDescriptors still at stage 0

2016-05-25 Thread Jordan Harband 
Closing the loop on this: this proposal is now stage 4, and will be
included in ES 2017. https://github.com/tc39/ecma262/pull/582

Polyfill: https://www.npmjs.com/package/object.getownpropertydescriptors

On Wed, Jan 20, 2016 at 9:26 PM, Jordan Harband  wrote:

> If Rick is unavailable, and after I've cleared a few other proposals off
> my plate, I'd be happy to take over as champion.
>
> On Wed, Jan 20, 2016 at 12:21 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> All clear. So, earlier, the TC39 champion was Rick Waldron but if he's
>> ultra busy (he usually is) and somebody else would like to champion this
>> I'd be happy to update the README with a champion reference.
>>
>> AFAIK Jordan Harband is the one taking care already of the poly in the
>> npm repo so if you (Jordan) will to champion this I'd be happy to add you
>> to the repo and help as I can.
>>
>> I'll work on the rest of the mentioned problems ASAP.
>>
>> Best Regards
>>
>> On Wed, Jan 20, 2016 at 8:05 PM, Domenic Denicola  wrote:
>>
>>> I’ve opened a number of minor, mostly-editorial issues on the proposal.
>>>
>>>
>>>
>>> In general, how much more work you need to do depends on how many stages
>>> you and your TC39 champion (who is it, by the way?) plan to advance the
>>> proposal at the next meeting. Looking through
>>> https://tc39.github.io/process-document/ I’d say:
>>>
>>>
>>>
>>> · For stage 1:
>>>
>>> o   You need to identify your TC39 champion (it should probably be in
>>> the document header)
>>>
>>> o   You need to identify potential cross-cutting concerns. For example,
>>> one might be “should there be a Reflect.getOwnPropertyDescriptors”? (to
>>> which my answer is no, but it should be included.)
>>>
>>> · For stage 2:
>>>
>>> o   Fix the editorial bugs in the spec text.
>>>
>>> · For stage 3:
>>>
>>> o   Identify designated reviewers and have them sign off.
>>>
>>> o   Get Brian to sign off.
>>>
>>> · For stage 4:
>>>
>>> o   Write full tests, covering symbols, data descriptors of every
>>> variation, accessors of every variation (get, get/set, set), throwing
>>> getters, and proxies with throwing and inconsistent getOwnProperty and
>>> ownPropertyKeys traps. (The proxies cases might not be necessary.)
>>>
>>>
>>>
>>> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
>>> Of *Andrea Giammarchi
>>> *Sent:* Wednesday, January 20, 2016 14:50
>>> *To:* Mathias Bynens 
>>> *Cc:* es-discuss@mozilla.org
>>> *Subject:* Re: Object.getOwnPropertyDescriptors still at stage 0
>>>
>>>
>>>
>>> Dear all,
>>>
>>>   the current proposal is here
>>> https://github.com/WebReflection/Object.getOwnPropertyDescriptors#objectgetownpropertydescriptors-proposal
>>>
>>>
>>>
>>> It has been mostly copied, as suggested, from
>>> https://github.com/tc39/Array.prototype.includes
>>>
>>>
>>>
>>> It has a reference implemntation:
>>> https://github.com/WebReflection/Object.getOwnPropertyDescriptors/blob/master/reference-implementation/index.js#L12-L68
>>>
>>>
>>>
>>> It has at least one test:
>>> https://github.com/WebReflection/Object.getOwnPropertyDescriptors/blob/master/test/built-ins/Object/getOwnPropertyDescriptors/has-accessors.js
>>>
>>>
>>>
>>> I wonder if there is a specific amount of tests I should cover, right
>>> now I just cover the fact it works and it does not ignore accessors.
>>>
>>>
>>>
>>> Woudl a test for symbols and one for data descriptors be enough to move
>>> forward?
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>> On Mon, Jan 18, 2016 at 9:12 PM, Mathias Bynens 
>>> wrote:
>>>
>>> On Mon, Jan 18, 2016 at 8:27 PM, Andrea Giammarchi
>>>  wrote:
>>> > Do you (or anyone else) know if that should be filed as a PR to
>>> tc39/ecma262
>>> > or if it should just be a repository eventually posted in here?
>>>
>>> It should be a repository that can eventually move to the tc39
>>> organization if all goes well. Good luck!
>>>
>>>
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.trimRight/trimLeft

2016-05-25 Thread Jordan Harband 
* sorry, to clarify: This was discussing padding. trimLeft/trimRight /
trimStart/trimEnd is still stage 2

On Wed, May 25, 2016 at 2:56 PM, Jordan Harband  wrote:

> Closing the loop on this: this feature is now stage 4, and will be
> included in ES 2017. https://github.com/tc39/ecma262/pull/581
>
> Polyfills: https://www.npmjs.com/package/string.prototype.padstart and
> https://www.npmjs.com/package/string.prototype.padend
>
> On Thu, Jul 30, 2015 at 10:33 AM, Behrang Saeedzadeh 
> wrote:
>
>> I think poly-filling is only a good idea when the spec says a given type
>> should have a given function but one or more browsers haven't implemented
>> it yet.
>>
>> Otherwise it will become like the era of overtly monkey patching
>> everything in Ruby that could end up with libraries clashing with each
>> other and leading to lots of headaches for developers.
>>
>> Unless something similar to C#'s extension methods are added to
>> EcmaScript: https://msdn.microsoft.com/en-AU/library/bb383977.aspx that
>> can turned on a polyfill on a per scope basis.
>>
>>
>>
>> On Thu, Jul 30, 2015 at 1:12 AM Michał Wadas 
>> wrote:
>>
>>> I can't remember last time when I would need `isNullOrEmpty` -
>>> Boolean('') and Boolean(null) evaluates to false. And `if (str)`
>>> handles any case with consistent types.
>>>
>>> String.isNullOrEmpty = (a)=>(typeof a === 'string' || a === null) && !a;
>>>
>>> Anyway - native isNullOrWhiteSpace would be probably be useful only to
>>> reduce GC pressure, because it's easily polyfilled.
>>>
>>> String.isNullOrWhiteSpace = (a)=>a === null ? true : typeof a ===
>>> 'string' && !a.trim();
>>>
>>>
>>> 2015-07-29 13:27 GMT+02:00 Behrang Saeedzadeh :
>>> > Another set of very handy functions that in Java are provided by
>>> libraries
>>> > such as Guava or Apache Commons and in C# are built in, are
>>> > `String.isNullOrEmpty(aStr)` and `String.IsNullOrWhiteSpace(aStr)`.
>>> >
>>> > Would be nice if they ES Strings had them too.
>>> >
>>> > On Tue, Jul 28, 2015 at 10:15 AM John-David Dalton
>>> >  wrote:
>>> >>
>>> >> In the wild I've seen ltrim rtrim which are variations of trimLeft and
>>> >> trimRight and padLeft padRight or lpad, rpad for other forms. For
>>> stings I
>>> >> think of left and right as leading and trailing and think of start
>>> and end
>>> >> as more position indicators of like slice or a range.
>>> >>
>>> >>
>>> >> -JDD
>>> >>
>>> >> On Mon, Jul 27, 2015 at 4:55 PM, Dmitry Soshnikov
>>> >>  wrote:
>>> >>>
>>> >>> OK, it was added to the agenda for the next meeting (will be
>>> presented by
>>> >>> Sebastian Markbage), so can be discussed in detail. I agree that
>>> "start",
>>> >>> and "end" are now probably better fit (because of i18n, and a strong
>>> >>> correlation with "startsWith" and "endsWith"). We can probably
>>> ignore the
>>> >>> de-facto shipped in browsers, they will just implement in addition
>>> >>> `trimStart` and `trimEnd`, and eventually deprecate the "right" and
>>> "left".
>>> >>>
>>> >>> Dmitry
>>> >>>
>>> >>> On Tue, Jul 21, 2015 at 12:02 AM, Claude Pache <
>>> claude.pa...@gmail.com>
>>> >>> wrote:
>>> 
>>> 
>>>  > Le 21 juil. 2015 à 08:28, Jordan Harband  a
>>> écrit :
>>>  >
>>>  > On the contrary -"left" always begins at index 0 - "start" is
>>>  > sometimes index 0, sometimes index (length - 1).
>>> 
>>>  Counter-example: ES6 methods `String#startsWith` and
>>> `String#endsWith`
>>>  are named correctly.
>>> 
>>>  > I think "left" and "right" are the right names; "start" and "end"
>>>  > would require unicode bidirectional stuff.
>>> 
>>>  No, because characters in Unicode strings are ordered logically, not
>>>  visually.
>>> 
>>>  —Claude
>>> 
>>>  ___
>>>  es-discuss mailing list
>>>  es-discuss@mozilla.org
>>>  https://mail.mozilla.org/listinfo/es-discuss
>>> >>>
>>> >>>
>>> >>>
>>> >>> ___
>>> >>> es-discuss mailing list
>>> >>> es-discuss@mozilla.org
>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>> >>>
>>> >>
>>> >> ___
>>> >> es-discuss mailing list
>>> >> es-discuss@mozilla.org
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> > --
>>> > Best regards,
>>> > Behrang Saeedzadeh
>>> >
>>> > ___
>>> > es-discuss mailing list
>>> > es-discuss@mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>>
>> --
>> Best regards,
>> Behrang Saeedzadeh
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org

Re: String.prototype.trimRight/trimLeft

2016-05-25 Thread Jordan Harband 
Closing the loop on this: this feature is now stage 4, and will be included
in ES 2017. https://github.com/tc39/ecma262/pull/581

Polyfills: https://www.npmjs.com/package/string.prototype.padstart and
https://www.npmjs.com/package/string.prototype.padend

On Thu, Jul 30, 2015 at 10:33 AM, Behrang Saeedzadeh 
wrote:

> I think poly-filling is only a good idea when the spec says a given type
> should have a given function but one or more browsers haven't implemented
> it yet.
>
> Otherwise it will become like the era of overtly monkey patching
> everything in Ruby that could end up with libraries clashing with each
> other and leading to lots of headaches for developers.
>
> Unless something similar to C#'s extension methods are added to
> EcmaScript: https://msdn.microsoft.com/en-AU/library/bb383977.aspx that
> can turned on a polyfill on a per scope basis.
>
>
>
> On Thu, Jul 30, 2015 at 1:12 AM Michał Wadas 
> wrote:
>
>> I can't remember last time when I would need `isNullOrEmpty` -
>> Boolean('') and Boolean(null) evaluates to false. And `if (str)`
>> handles any case with consistent types.
>>
>> String.isNullOrEmpty = (a)=>(typeof a === 'string' || a === null) && !a;
>>
>> Anyway - native isNullOrWhiteSpace would be probably be useful only to
>> reduce GC pressure, because it's easily polyfilled.
>>
>> String.isNullOrWhiteSpace = (a)=>a === null ? true : typeof a ===
>> 'string' && !a.trim();
>>
>>
>> 2015-07-29 13:27 GMT+02:00 Behrang Saeedzadeh :
>> > Another set of very handy functions that in Java are provided by
>> libraries
>> > such as Guava or Apache Commons and in C# are built in, are
>> > `String.isNullOrEmpty(aStr)` and `String.IsNullOrWhiteSpace(aStr)`.
>> >
>> > Would be nice if they ES Strings had them too.
>> >
>> > On Tue, Jul 28, 2015 at 10:15 AM John-David Dalton
>> >  wrote:
>> >>
>> >> In the wild I've seen ltrim rtrim which are variations of trimLeft and
>> >> trimRight and padLeft padRight or lpad, rpad for other forms. For
>> stings I
>> >> think of left and right as leading and trailing and think of start and
>> end
>> >> as more position indicators of like slice or a range.
>> >>
>> >>
>> >> -JDD
>> >>
>> >> On Mon, Jul 27, 2015 at 4:55 PM, Dmitry Soshnikov
>> >>  wrote:
>> >>>
>> >>> OK, it was added to the agenda for the next meeting (will be
>> presented by
>> >>> Sebastian Markbage), so can be discussed in detail. I agree that
>> "start",
>> >>> and "end" are now probably better fit (because of i18n, and a strong
>> >>> correlation with "startsWith" and "endsWith"). We can probably ignore
>> the
>> >>> de-facto shipped in browsers, they will just implement in addition
>> >>> `trimStart` and `trimEnd`, and eventually deprecate the "right" and
>> "left".
>> >>>
>> >>> Dmitry
>> >>>
>> >>> On Tue, Jul 21, 2015 at 12:02 AM, Claude Pache <
>> claude.pa...@gmail.com>
>> >>> wrote:
>> 
>> 
>>  > Le 21 juil. 2015 à 08:28, Jordan Harband  a
>> écrit :
>>  >
>>  > On the contrary -"left" always begins at index 0 - "start" is
>>  > sometimes index 0, sometimes index (length - 1).
>> 
>>  Counter-example: ES6 methods `String#startsWith` and
>> `String#endsWith`
>>  are named correctly.
>> 
>>  > I think "left" and "right" are the right names; "start" and "end"
>>  > would require unicode bidirectional stuff.
>> 
>>  No, because characters in Unicode strings are ordered logically, not
>>  visually.
>> 
>>  —Claude
>> 
>>  ___
>>  es-discuss mailing list
>>  es-discuss@mozilla.org
>>  https://mail.mozilla.org/listinfo/es-discuss
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> es-discuss mailing list
>> >>> es-discuss@mozilla.org
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> >>>
>> >>
>> >> ___
>> >> es-discuss mailing list
>> >> es-discuss@mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> > --
>> > Best regards,
>> > Behrang Saeedzadeh
>> >
>> > ___
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
> --
> Best regards,
> Behrang Saeedzadeh
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.padLeft / String.prototype.padRight

2016-05-25 Thread Jordan Harband 
Closing the loop on this: this proposal is now stage 4 and will be included
in ES 2017. https://github.com/tc39/ecma262/pull/581

On Mon, Jan 11, 2016 at 11:40 PM, Norbert Lindenberg <
ecmascr...@lindenbergsoftware.com> wrote:

> Thank you for renaming padLeft/padRight to padStart/padEnd.
>
> On the treatment of code units, I was hoping to find more detail in the
> meeting minutes, but haven’t seen those yet. The native encoding of strings
> in the language, with the exception of a few parts that we haven’t been
> able to fix in EcmaScript 2015, is UTF-16, in which some characters take
> one code unit and others two code units. The current padStart/padEnd
> proposal doesn’t take that into consideration – it truncates at code unit
> boundaries rather than code point boundaries, and thus perpetuates problems
> stemming from obsolete assumptions about Unicode from 1995.
>
> For background on the Unicode problems in pre-2015 EcmaScript see:
> https://mathiasbynens.be/notes/javascript-unicode
> and the proposed solution that got integrated into EcmaScript 2015:
> http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/
>
> Thanks,
> Norbert
>
>
> > On Nov 17, 2015, at 13:07 , Jordan Harband  wrote:
> >
> > In the TC39 meeting today, we discussed these concerns and decided to
> rename the proposal from padLeft/padRight to padStart/padEnd (
> https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294)
> - and correspondingly, to investigate providing trimStart/trimEnd
> (alongside the legacy trimLeft/trimRight). The consensus remained the same
> around treatment of code units - which is that, like every other string
> method, they should conform to the native encoding of strings in the
> language.
> >
> > As such, the proposal has now been approved for stage 3 in the TC39
> process.
> >
> > Thanks everyone for providing your input!
> >
> > - Jordan
> >
> > On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi  wrote:
> > I might be late to this but please don't use "left" and "right" for
> referring to start and end of a string. In right to left languages it's
> confusing. As someone who writes right-to-left we have enough of those
> "left" and "rights" based on English writing direction. CSS made this
> mistake but corrected it in later specs. Original box model (margin and
> padding) used left and right but newer flex box spec uses start and end.
> Because we made a mistake in the past we don't have to repeat it.
> >
> > Thanks,
> > Mohsen Azimi
> >
> > On Mon, Nov 16, 2015 at 10:44 AM Claude Pache 
> wrote:
> >
> > > Le 16 nov. 2015 à 14:01, Alexander Jones  a écrit :
> > >
> > > I see about as little use case for this as `String.prototype.blink`.
> Date/hours is better solved with zero padding formatting, not just padding
> out the already stringified number (think negative values -42). Same
> applies to filenames for lexicographical sort. Fixed length fields in wire
> protocols already need to be converted to bytes first before padding, which
> makes the use of this feature impossible.
> >
> > Sure, in all those cases I could have used `sprintf` instead of
> `str_pad`. However, the equivalent of neither one is natively available in
> JS.
> >
> > I could write a tagged template that does the equivalent of
> `sprintf` And `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to
> have for writing more easily such a template,... oh well... :-/
> >
> > —Claude
> >
> >
> >
> > >
> > > On Monday, 16 November 2015, Claude Pache 
> wrote:
> > > Here are my typical use cases (found by scanning uses of "str_pad" in
> my PHP codebase):
> > >
> > > * transferring data through a protocol that uses fix-length fields;
> > > * formatting things like date/hours, e.g. "08:00" for "8am";
> > > * generating filenames of fixed length, so that they sort correctly,
> e.g. "foo-00042.txt";
> > > * generating codes of fixed length (e.g. barcodes).
> > >
> > > In all those cases, the set of characters is typically limited to
> ASCII or ISO-8559-1.
> > > Moreover, the filler string consists always of one ASCII character
> (usually " " or "0").
> > >
> > > —Claude
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list

Re: ECMA-402 DefaultLocale

2016-05-25 Thread Mike Samuel 
Are lines 149-164 the part you want people to look at?
On May 23, 2016 4:47 PM, "Geoffrey Garen"  wrote:

> Hi folks.
>
> ECMA-402 lists default locale as an unspecified "implementation dependent
> behaviour”.
>
> In the absence of a specified default locale behavior, can we agree to a
> de facto or best effort behavior to match the OS’s or browser’s locale and
> language settings?
>
> We’d like Safari and WebKit to honor the OS's locale and language settings
> so that language, time, date, currency, etc. present just as well in web
> content as they do in native apps. You can see the approach we took here:
>
> <
> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformUserPreferredLanguagesMac.mm
> >
>
> Regards,
> Geoff
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: AND and OR in if statement

2016-05-25 Thread Claude Pache 

> Le 25 mai 2016 à 03:29, kdex  a écrit :
> 
> IMHO, the current operators `&&`, `&`, `||` ,`|` are the cleanest 
> implementation of `and` and `or` that I could think of.

I don’t think so: It is not ideal that the longest forms, `&&` and `||`, are by 
far the most current ones. But this is history that we cannot change.

Having to sets of logical operators, `&&`/`||` versus `and`/`or`, **with 
different precedence**, is very useful in idiomatic Perl, where they are 
typically used to express control-flow. But much less so in idiomatic JS.

—Claude

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: AND and OR in if statement

2016-05-25 Thread Andy Earnshaw 
It's not feasible anyway because AND and OR are already valid identifiers:

a = foo()
  &&(bar)

is equivalent to `a = foo() && bar`, but

a = foo()
  AND(bar)

is equivalent to

a = foo();
AND(bar);

On Wed, 25 May 2016 at 02:29 kdex  wrote:

> Could you explain how your second example is cleaner? All I see is that
> it's longer; the rest is merely a matter of taste.
> JavaScript's syntax was, amongst others, heavily influenced by C-family
> languages (which went for `&&` and `||` as well as `&` and `|`).
>
> Next, I think it's confusing that, although we're calling it "bitwise and"
> and "bitwise or", we would only be able to write `and` or `or` in a logical
> context; this choice is entirely arbitrary. Bitwise operators would still
> need to be `&` and `|` since there's no way to tell what your intent is
> just from the syntax.
>
> IMHO, the current operators `&&`, `&`, `||` ,`|` are the cleanest
> implementation of `and` and `or` that I could think of.
>
> On Dienstag, 24. Mai 2016 21:14:59 CEST Francis Clavette wrote:
> > Hi,
> > I’d like to be able to use AND for && and OR for || in conditional
> statements in a future version of ECMAScript. It’s a feature I’ve always
> been wanting since transitioning from PHP. It’s also much cleaner :
> >
> > if ($scope.newSourceModal.isShown() && $scope.newsource.type == "book"
> && (!$scope.insertingFromScan || $scope.ok))
> >
> > ==
> >
> > if ($scope.newSourceModal.isShown() AND $scope.newsource.type == "book"
> AND (!$scope.insertingFromScan OR $scope.ok))
> >
> >
> > Francis
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: importing selected chucks of a module into an object

2016-05-25 Thread Norbert de Langen 
Small modules are great, especially for creators. I’m onboard with 
small-modules being the default and recommended way of doing things.
But.. I think history has shown that there is a use-case and a place in the 
world for larger composed modules. Take a look at lodash or jQuery for example.
From a consumer point of view larger / composed modules make a lot of sense. A 
‘higher order module’ if you will.
Here’s the author of roll-up making a case for such modules as well: 
https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4#.hczbjni3t

When dealing with many dependencies (for whatever reason) or just dependencies 
that are really related, it’s nice to not have to do this:
```
// small modules
import xmlParse from 'xml-parse';
import xmlCreate from 'xml-create';
import xmlSandwich from 'xml-sandwich';
import jsonParse from 'json-parse';
import jsonCreate from 'json-create';
import jsonBacon from 'json-bacon';
import htmlParse from 'html-parse';
import htmlCreate from 'html-create';
import htmlOrange from 'html-orange';

// over
import { parse, create, sandwich } as xmlUtil from 'xml-util';
import { parse, create, bacon } as jsonUtil from 'json-util';
import { parse, create, orange } as htmlUtil from 'html-util';
```

From: Jordan Harband 
Date: dinsdag 24 mei 2016 21:23
To: Norbert Langen 
Cc: "Tab Atkins Jr." , "es-discuss@mozilla.org" 

Subject: Re: Proposal: importing selected chucks of a module into an object

This is usually part of the reason why small modules are recommended, rather 
than large object bags of things (including many named exports). Have you 
considered putting each thing you want to import as the default export of a 
separate file?

On Tue, May 24, 2016 at 9:20 PM, Norbert de Langen 
> wrote:
I think there’s a preference reason for this but also optimization reasons.

For humans it becomes crystal clear exactly what parts are dependent on. I 
personally like this.

When importing the entire module the module code needs to be run to figure out 
what parts are not needed. Eliminating the possibility of tree-shaking I 
believe.

On 24-05-16 21:06, "Tab Atkins Jr." 
> wrote:

>On Tue, May 24, 2016 at 11:59 AM, Norbert de Langen
>> wrote:
>> It would be nice to have this option:
>>
>> ```
>> import { parse } as xmlLib from 'xml-lib';
>> import { parse } as jsonLib from 'json-lib';
>> import { parse } as htmlLib from 'html-lib';
>>
>> // usage
>> xmlLib.parse();
>> jsonLib.parse();
>> htmlLib.parse();
>> ```
>
>This begs the question, tho - why do you only need to import selected
>chunks? If you're pulling in the module as a namespace object, how
>does having the *rest* of the module available harm you?
>
>~TJ

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss