Re: [Proposal] New syntax for lazy getters

[Isiah Meadows]

I agree the main proposal is long and complex, but this kind of addition
could be designed with little effort to "fall out of the grid", since it
has so much in common with classes already (properties, getters/setters,
methods). The main question is with properties, but those are easy to just
leave out, since function calls do just as well.

Function declaration/expression/parameter decorators are completely
different beasts with little in common, so I feel it's a bad comparison.

On Thu, Jun 28, 2018, 01:33 Augusto Moura  wrote:

> On June 27, 2018 09:23, kai zhu  wrote:
> > what would happen if you tried to JSON.stringify foo? a core-value of
> javascript to industry is as an idiot-proof/least-surprise language for
> serializing json-data across browser <-> server.  junior-programmers who
> naively employ hard-to-serialize things like custom-getters in their
> low-level code, mostly end up annoying senior-programmers when they have to
> debug high-level integration-code that have problems baton-passing those
> states around.
>
> Depends on the chosen implementation (which will be open for discussion
> for sure). The Groovy AST transformation annotation `@Lazy` for example
> translates the field into a getter (without a setter, making it virtually a
> readonly field) which initializes the field once at the first invocation
> (there is a example of the generated code at Groovy docs[1]). If we follow
> this path we can easily implement it in Javascript as a enumerable get
> property descriptor. About `JSON.stringify`, it renders all enumerable
> properties of a object, including getters, so it will initialize the field
> and represent it as any other property. My previous decorator example could
> be loosely interpreted as:
>
> ```js
> const foo = {
>   get bar() {
> if (!this.hasOwnProperty('_bar')) {
>   this._bar = 3;
> }
> return this._bar;
>   },
> };
>
> // JSON.stringify would write the correct bar value, initalizing it if
> necessary
> JSON.stringify(foo) // "{"bar":3}"
> ```
>
> We could make a setter too, but the logic to implement it it's a lot more
> complex and subject to confusion
>
> On June 27, 2018 10:11, Isiah Meadows  wrote:
> > If you're wanting to propose new places for decorators, you'd have much
> better luck here: https://github.com/tc39/proposal-decorators
>
> I think that the main proposal is already long and complex, maybe it's a
> better idea to finalize it first and then start a new proposal about this
> others decorators places (as with function expression decorators and
> function parameters decoratos).
>
> [1] http://groovy-lang.org/metaprogramming.html#xform-Lazy
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] New syntax for lazy getters

[Augusto Moura]

On June 27, 2018 09:23, kai zhu  wrote:
> what would happen if you tried to JSON.stringify foo? a core-value of
javascript to industry is as an idiot-proof/least-surprise language for
serializing json-data across browser <-> server.  junior-programmers who
naively employ hard-to-serialize things like custom-getters in their
low-level code, mostly end up annoying senior-programmers when they have to
debug high-level integration-code that have problems baton-passing those
states around.

Depends on the chosen implementation (which will be open for discussion for
sure). The Groovy AST transformation annotation `@Lazy` for example
translates the field into a getter (without a setter, making it virtually a
readonly field) which initializes the field once at the first invocation
(there is a example of the generated code at Groovy docs[1]). If we follow
this path we can easily implement it in Javascript as a enumerable get
property descriptor. About `JSON.stringify`, it renders all enumerable
properties of a object, including getters, so it will initialize the field
and represent it as any other property. My previous decorator example could
be loosely interpreted as:

```js
const foo = {
  get bar() {
if (!this.hasOwnProperty('_bar')) {
  this._bar = 3;
}
return this._bar;
  },
};

// JSON.stringify would write the correct bar value, initalizing it if
necessary
JSON.stringify(foo) // "{"bar":3}"
```

We could make a setter too, but the logic to implement it it's a lot more
complex and subject to confusion

On June 27, 2018 10:11, Isiah Meadows  wrote:
> If you're wanting to propose new places for decorators, you'd have much
better luck here: https://github.com/tc39/proposal-decorators

I think that the main proposal is already long and complex, maybe it's a
better idea to finalize it first and then start a new proposal about this
others decorators places (as with function expression decorators and
function parameters decoratos).

[1] http://groovy-lang.org/metaprogramming.html#xform-Lazy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: [Proposal] ignoreCase method

[Isiah Meadows]

I would be a fan of adding a `string.compare(other, {ignoreCase = false,
unicode = false})` that purely works by character code/code point and is
required to return 1, 0, or -1. That would be easier to spec, and is more
generally useful when you're working with strings for computers, not people.

But that's largely independent of this proposal.


-

Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com

On Wed, Jun 27, 2018 at 11:37 AM, Robert Wozniak 
wrote:

> Hi,
>
>
>
> I think you’re right, It could be simpler to do it like that.
>
>
>
> I have checked “localeCompare”, it does compare case sensitive strings but
> it doesn’t compare strings in an array and to do it, you will have to
> execute the method as many times as strings in an array. By using
> ignoreCase method, you will pass specific array and the method will do it
> for you inside. Second thing, “localeCompare” returns numbers: 0, 1, -1, -2
> depends on the result, a method proposed by me returns true or false.
>
>
>
> Another thing would be that “localeCompare” is heavier that ignoreCase
> method. I think we should have lightweight alternative to compare case
> sensitive strings.
>
> ___
> 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] ignoreCase method

[T.J. Crowder]

On Wed, Jun 27, 2018 at 6:03 PM, Oriol _  wrote:
>> (`.localeCompare(stringOne, undefined, {sensitivity: "base"})` **is**
> fairly verbose, so I'd probably have a utility function for it.)
>
> I would just create a collator outside the loop:

I meant verbose to write every time you need to do a case-insensitive
comparison; instead, I'd drop a utility function in my standard lib
somewhere.

I like that approach to creating that utility function, though. :-)

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

Re: [Proposal] ignoreCase method

[Oriol _]

> (`.localeCompare(stringOne, undefined, {sensitivity: "base"})` **is**
fairly verbose, so I'd probably have a utility function for it.)

I would just create a collator outside the loop:

```js
const stringOne = "Matheus";
const manyStrings = ['robert', 'lucas', 'matheus'];
const {compare} = new Intl.Collator(undefined, {sensitivity: "base"});
if (manyStrings.some(s => compare(s, stringOne) == 0)) {
    // Yes, it was found
}
```

-- Oriol


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

Re: Re: [Proposal] ignoreCase method

[T.J. Crowder]

On Wed, Jun 27, 2018 at 4:37 PM, Robert Wozniak 
wrote:
> ...it does compare case sensitive strings but
> it doesn’t compare strings in an array and to do it, you will have to
> execute the method as many times as strings in an array

That's not a problem. For the "does this string match any in this array"
case, use `Array#some`:

```js
const stringOne = "Matheus";
const manyStrings = ['robert', 'lucas', 'matheus'];
if (manyStrings.some(s => s.localeCompare(stringOne, undefined,
{sensitivity: "base"}) == 0)) {
// Yes, it was found
}
```

(`.localeCompare(stringOne, undefined, {sensitivity: "base"})` **is**
fairly verbose, so I'd probably have a utility function for it.)

> ...and the method will do it for you inside.

There's not all that much in it, doing the loop within the standard API
function vs. outside it. If it's a hotspot for execution, it'll get
aggressively optimized either way. If it isn't, you don't care.

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

Re: Re: [Proposal] ignoreCase method

[T.J. Crowder]

On Wed, Jun 27, 2018 at 4:37 PM, Robert Wozniak 
wrote:
> ...Second thing, “localeCompare” returns numbers: 0, 1, -1, -2 depends
> on the result, a method proposed by me returns true or false.

This makes your method markedly less useful than `localeCompare`. It's
really useful to know not just that the strings are equal or not equal, but
how they relate to one another lexicographically. For instance, for sorting:

```js
const array = ["c", "a", "B"];
array.sort((a, b) => a.localeCompare(b, undefined, {sensitivity: "base"}));
console.log(array); // "a", "B", "c"
```

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

Re: Re: [Proposal] ignoreCase method

[Robert Wozniak]

Hi,

I think you’re right, It could be simpler to do it like that. 

I have checked “localeCompare”, it does compare case sensitive strings but it 
doesn’t compare strings in an array and to do it, you will have to execute the 
method as many times as strings in an array. By using ignoreCase method, you 
will pass specific array and the method will do it for you inside. Second 
thing, “localeCompare” returns numbers: 0, 1, -1, -2 depends on the result, a 
method proposed by me returns true or false.

Another thing would be that “localeCompare” is heavier that ignoreCase method. 
I think we should have lightweight alternative to compare case sensitive 
strings.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] New syntax for lazy getters

[Isiah Meadows]

If you're wanting to propose new places for decorators, you'd have much
better luck here: https://github.com/tc39/proposal-decorators

I do agree this is an obvious place for a decorator, and it is probably the
ideal way of specifying it for object properties, but your larger proposal
of adding decorators for objects would have better luck there.

-

Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com

On Wed, Jun 27, 2018 at 8:23 AM, kai zhu  wrote:

> What it's doesn't cover (and in my opinion should be the focus of a new
> proposal) is Decorators for literal objects. Something like the code below
> is yet not proposed:
>
> ``` js
> const foo = {
>   @lazy bar: 3,
> };
> ```
>
>
> what would happen if you tried to JSON.stringify foo? a core-value of
> javascript to industry is as an idiot-proof/least-surprise language for
> serializing json-data across browser <-> server.  junior-programmers who
> naively employ hard-to-serialize things like custom-getters in their
> low-level code, mostly end up annoying senior-programmers when they have to
> debug high-level integration-code that have problems baton-passing those
> states around.
>
> kai zhu
> kaizhu...@gmail.com
>
>
>
> On 12 Jun 2018, at 9:07 PM, Isiah Meadows  wrote:
>
> BTW, I proposed similar (lazy values) 9 months ago [1], and it's been
> on the list plenty of times [2]. I'd personally *love* to see it
> happen, but I find it not very likely it'd make it, especially as a
> property (since decorators can rectify that).
>
> [1]: https://esdiscuss.org/topic/lazy-evaluation
> [2]: https://www.google.com/search?q=site%3Aesdiscuss.org+lazy+
> property+OR+getter+OR+setter
>
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Tue, Jun 12, 2018 at 8:48 AM, Andrea Giammarchi
>  wrote:
>
> FWIW, I think to keep it simple `lazy: true` would be enough for the time
> being.
>
> Having the new descriptor inside the descriptor seems a bit over
> engineering
> at this point, imo, but having a field already won't exclude, in the
> feature, the ability to improve that field (similar way addEventListener on
> DOM got promoted from `(type, handler, boolean)` signature to `(type,
> handler, boolean || options)`)
>
> I also agree that `lazy field = expr` is a different beast, and it won't
> play well with descriptors as we know, but it might allow overwrites if
> accessed directly.
>
> I wouldn't mind that as long as it plays well with objects and classes, and
> as long as there is an official way to lazy define properties, and if it
> could be so lazy that if redefined disappears, in that direct assignment
> form, it would be a solution to all my cases.
>
> Regards
>
>
> On Tue, Jun 12, 2018 at 2:37 PM,  wrote:
>
>
> Actually, by malleable I meant only configurable:true, so one can change
> it via Object.defineProp… api, I did not mean necessarily to define it as
> value.
>
> I have no strong opinion on what should be there after the first access,
> but it boils down on how will it be exposed via Object.defineProperty,
> really, because as little as possible should be changed, IOW as much as
> possible retained.
>
> So on case things are defined as (only pondering the property descriptor
> here, the call is obvious):
>
>  { lazy: true, get: () => Math.random() } … [1]
>
> or, bigger example:
>
>  { lazy: { configurable: false }, enumerable: false, get: () =>
> foos.length, set: x => console.log(`set ${x}`) } … [2]
>
> Then what should be generated is indeed a getter so that setter may be
> retained as well in [2].
>
> If the definition is:
>
> { lazy: { configurable: false, writable: false, enumerable: true, compute:
> () => Math.random() }, enumerable: false } … [3]
>
> then it defines a value (which is not enumerable until first accessed thus
> created; contrived example, I know).
>
> This post also shows a proposal how to, in future proof way, define what
> attributes will the replaced getter/value have: put it In lazy field of
> prop
> descriptor, lazy: true means shortcut for “the default way / Inherit from
> what is there now”.
>
> Herby
>
> On June 12, 2018 2:02:28 PM GMT+02:00, Aadit M Shah
>  wrote:
>
> Okay, so my previous statement about field declarations in classes
> being
> invalid was incorrect. I didn't see Andrea's link to the class field
> declarations proposal[1]. Hence, from what I understand we're
> considering the following syntax:
> const zeros = { head: , lazy tail: this };
>
> class Random {
>   lazy value = Math.random();
> }
>
> As for semantics, Herby's philosophy of "malleable unless specified
> otherwise" makes sense. Hence, the above code would be transpiled to:
> const zeros = {
>   head: ,
>   get tail() {
>   return Object.defineProperty(this, "tail", {
>   value: this
>   }).tail;
>   }
> };
>
> class Random {
>   get value() {
>   return Object.defineProperty(this, "value", {
>   value: Math.random()
>   }).value;
>   }
> }
>
> I guess we'd also be adopting the 

Re: [Proposal] ignoreCase method

[Isiah Meadows]

BTW, have you tried `string.localeCompare(other, null, {sensitivity:
"base"})` or `sensitivity: "accent"`?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/localeCompare

-

Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com

On Wed, Jun 27, 2018 at 7:35 AM, Michael Luder-Rosefield <
rosyatran...@gmail.com> wrote:

> Would it not be simpler to simply change the signature from
> `function(value, arrayOfStrings)` to `function(...values)`?
>
> I'd also suggest that a better, more general purpose formulation of
> comparing a string against multiple values might be to use #match.
> Something like:
>
> ```
> const checkString = (str, { ignoreCase, startsWith, endsWith, equals }={}
> ) => {
> const start = startsWith || equals ? '^' : '';
> const end = endsWith || equals ? '$' : '';
> const rx = v => new RegExp(`${start}${v}${end}`,ignoreCase && 'i');
>
> return { against: (...values) => values.some(value =>
> str.match(rx(value))) };
> }
> ```
>
>
> On Wed, 27 Jun 2018 at 11:50 Robert Wozniak 
> wrote:
>
>> Hi everyone,
>>
>> ignoreCase - JavaScript proposal
>>
>> It's a proposal to implement a new function to compare two strings but
>> without case sensitivity.
>>
>> The proposal is bringing an important function, which is being used in
>> Java. Many times in my career I had to compare two strings but ignore case
>> sensitivity.
>>
>> I had to convert it first and then I could compare. I'd like developers
>> to be able to use the function and compare two strings without worrying
>> about case sensitivity.
>> 1. Syntax
>>
>> String.prototype.ignoreCase = function(value, arrayOfStrings) {
>> var secondOption = value.toLowerCase() || 
>> arrayOfStrings.join(',').toLowerCase().split(',');
>> var firstOption = this.valueOf().toLowerCase();
>> if(typeof secondOption === 'object') {
>> for(var i = 0, l = arrayOfStrings.length; i < l; i++) {
>> if(firstOption === secondOption[i]) {
>> return true;
>> break;
>> }
>> }
>> } else {
>> if(firstOption === secondOption) {
>> return true;
>> } else {
>> return false;
>> }
>> }
>> };
>>
>> Above code presents *ignoreCase* function and what's happening inside.
>>
>> The function takes two parameters:
>>
>> (value, arrayOfStrings)
>> 1.1
>> "value" parameter
>>
>> The value parameter is the string which is going to be compared with the
>> parent string chosen by the developer, for example:
>>
>> const stringOne = "Matheus";stringOne.ignoreCase("matheus"); // true;
>>
>>
>> 1.2
>> "arrayOfStrings" parameter
>>
>> The "arrayOfStrings" parameter is an array of strings, which are going to
>> be compared with the parent string chosen by the developer. Once the parent
>> string equals one of the strings in an array, it will return true and stops
>> iterating through.
>>
>> Example:
>>
>> const stringOne = "Matheus";const manyStrings = ['robert', 'lucas', 
>> 'matheus'];stringOne.ignoreCase('', manyStrings) // true;
>>
>> 2. Response
>>
>> The function is going to return true or false. The result depends on
>> equality between chosen strings.
>> 3. How does
>> it work?
>>
>> The function converts all of the strings, which the developer chose to
>> the lower case. After performing the previous operation, it compares all of
>> them. If at least one, equals the provided parent string, then the function
>> returns true.
>>
>>
>> You can the proposal on my GitHub:
>> https://github.com/robertjwozniak/ignoreCase
>>
>>
>> --
>> Regards,
>> Robert Wozniak
>> ___
>> 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: [Proposal] New syntax for lazy getters

[kai zhu]

> What it's doesn't cover (and in my opinion should be the focus of a new 
> proposal) is Decorators for literal objects. Something like the code below is 
> yet not proposed:
> 
> ``` js
> const foo = {
>   @lazy bar: 3,
> };
> ```

what would happen if you tried to JSON.stringify foo? a core-value of 
javascript to industry is as an idiot-proof/least-surprise language for 
serializing json-data across browser <-> server.  junior-programmers who 
naively employ hard-to-serialize things like custom-getters in their low-level 
code, mostly end up annoying senior-programmers when they have to debug 
high-level integration-code that have problems baton-passing those states 
around.

kai zhu
kaizhu...@gmail.com



> On 12 Jun 2018, at 9:07 PM, Isiah Meadows  wrote:
> 
> BTW, I proposed similar (lazy values) 9 months ago [1], and it's been
> on the list plenty of times [2]. I'd personally *love* to see it
> happen, but I find it not very likely it'd make it, especially as a
> property (since decorators can rectify that).
> 
> [1]: https://esdiscuss.org/topic/lazy-evaluation
> [2]: 
> https://www.google.com/search?q=site%3Aesdiscuss.org+lazy+property+OR+getter+OR+setter
> 
> -
> 
> Isiah Meadows
> m...@isiahmeadows.com
> www.isiahmeadows.com
> 
> 
> On Tue, Jun 12, 2018 at 8:48 AM, Andrea Giammarchi
>  wrote:
>> FWIW, I think to keep it simple `lazy: true` would be enough for the time
>> being.
>> 
>> Having the new descriptor inside the descriptor seems a bit over engineering
>> at this point, imo, but having a field already won't exclude, in the
>> feature, the ability to improve that field (similar way addEventListener on
>> DOM got promoted from `(type, handler, boolean)` signature to `(type,
>> handler, boolean || options)`)
>> 
>> I also agree that `lazy field = expr` is a different beast, and it won't
>> play well with descriptors as we know, but it might allow overwrites if
>> accessed directly.
>> 
>> I wouldn't mind that as long as it plays well with objects and classes, and
>> as long as there is an official way to lazy define properties, and if it
>> could be so lazy that if redefined disappears, in that direct assignment
>> form, it would be a solution to all my cases.
>> 
>> Regards
>> 
>> 
>> On Tue, Jun 12, 2018 at 2:37 PM,  wrote:
>>> 
>>> Actually, by malleable I meant only configurable:true, so one can change
>>> it via Object.defineProp… api, I did not mean necessarily to define it as
>>> value.
>>> 
>>> I have no strong opinion on what should be there after the first access,
>>> but it boils down on how will it be exposed via Object.defineProperty,
>>> really, because as little as possible should be changed, IOW as much as
>>> possible retained.
>>> 
>>> So on case things are defined as (only pondering the property descriptor
>>> here, the call is obvious):
>>> 
>>>  { lazy: true, get: () => Math.random() } … [1]
>>> 
>>> or, bigger example:
>>> 
>>>  { lazy: { configurable: false }, enumerable: false, get: () =>
>>> foos.length, set: x => console.log(`set ${x}`) } … [2]
>>> 
>>> Then what should be generated is indeed a getter so that setter may be
>>> retained as well in [2].
>>> 
>>> If the definition is:
>>> 
>>> { lazy: { configurable: false, writable: false, enumerable: true, compute:
>>> () => Math.random() }, enumerable: false } … [3]
>>> 
>>> then it defines a value (which is not enumerable until first accessed thus
>>> created; contrived example, I know).
>>> 
>>> This post also shows a proposal how to, in future proof way, define what
>>> attributes will the replaced getter/value have: put it In lazy field of prop
>>> descriptor, lazy: true means shortcut for “the default way / Inherit from
>>> what is there now”.
>>> 
>>> Herby
>>> 
>>> On June 12, 2018 2:02:28 PM GMT+02:00, Aadit M Shah
>>>  wrote:
 Okay, so my previous statement about field declarations in classes
 being
 invalid was incorrect. I didn't see Andrea's link to the class field
 declarations proposal[1]. Hence, from what I understand we're
 considering the following syntax:
 const zeros = { head: , lazy tail: this };
 
 class Random {
   lazy value = Math.random();
 }
 
 As for semantics, Herby's philosophy of "malleable unless specified
 otherwise" makes sense. Hence, the above code would be transpiled to:
 const zeros = {
   head: ,
   get tail() {
   return Object.defineProperty(this, "tail", {
   value: this
   }).tail;
   }
 };
 
 class Random {
   get value() {
   return Object.defineProperty(this, "value", {
   value: Math.random()
   }).value;
   }
 }
 
 I guess we'd also be adopting the syntax for private fields and static
 fields? For example, lazy #value and lazy static #value?
 
 On Tue, Jun 12, 2018, at 7:32 AM, he...@mailbox.sk wrote:
> 
> 
> On June 12, 2018 11:32:22 AM GMT+02:00, Aadit M Shah
>  wrote:>> Actually, 

Re: [Proposal] ignoreCase method

[Michael Luder-Rosefield]

Would it not be simpler to simply change the signature from
`function(value, arrayOfStrings)` to `function(...values)`?

I'd also suggest that a better, more general purpose formulation of
comparing a string against multiple values might be to use #match.
Something like:

```
const checkString = (str, { ignoreCase, startsWith, endsWith, equals }={} )
=> {
const start = startsWith || equals ? '^' : '';
const end = endsWith || equals ? '$' : '';
const rx = v => new RegExp(`${start}${v}${end}`,ignoreCase && 'i');

return { against: (...values) => values.some(value => str.match(rx(value)))
};
}
```


On Wed, 27 Jun 2018 at 11:50 Robert Wozniak 
wrote:

> Hi everyone,
>
> ignoreCase - JavaScript proposal
>
> It's a proposal to implement a new function to compare two strings but
> without case sensitivity.
>
> The proposal is bringing an important function, which is being used in
> Java. Many times in my career I had to compare two strings but ignore case
> sensitivity.
>
> I had to convert it first and then I could compare. I'd like developers to
> be able to use the function and compare two strings without worrying about
> case sensitivity.
> 1. Syntax
>
> String.prototype.ignoreCase = function(value, arrayOfStrings) {
> var secondOption = value.toLowerCase() || 
> arrayOfStrings.join(',').toLowerCase().split(',');
> var firstOption = this.valueOf().toLowerCase();
> if(typeof secondOption === 'object') {
> for(var i = 0, l = arrayOfStrings.length; i < l; i++) {
> if(firstOption === secondOption[i]) {
> return true;
> break;
> }
> }
> } else {
> if(firstOption === secondOption) {
> return true;
> } else {
> return false;
> }
> }
> };
>
> Above code presents *ignoreCase* function and what's happening inside.
>
> The function takes two parameters:
>
> (value, arrayOfStrings)
> 1.1
> "value" parameter
>
> The value parameter is the string which is going to be compared with the
> parent string chosen by the developer, for example:
>
> const stringOne = "Matheus";stringOne.ignoreCase("matheus"); // true;
>
> 1.2
> "arrayOfStrings" parameter
>
> The "arrayOfStrings" parameter is an array of strings, which are going to
> be compared with the parent string chosen by the developer. Once the parent
> string equals one of the strings in an array, it will return true and stops
> iterating through.
>
> Example:
>
> const stringOne = "Matheus";const manyStrings = ['robert', 'lucas', 
> 'matheus'];stringOne.ignoreCase('', manyStrings) // true;
>
> 2. Response
>
> The function is going to return true or false. The result depends on
> equality between chosen strings.
> 3. How does
> it work?
>
> The function converts all of the strings, which the developer chose to the
> lower case. After performing the previous operation, it compares all of
> them. If at least one, equals the provided parent string, then the function
> returns true.
>
>
> You can the proposal on my GitHub:
> https://github.com/robertjwozniak/ignoreCase
>
>
> --
> Regards,
> Robert Wozniak
> ___
> 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

[Proposal] ignoreCase method

[Robert Wozniak]

Hi everyone,

ignoreCase - JavaScript proposal

It's a proposal to implement a new function to compare two strings but
without case sensitivity.

The proposal is bringing an important function, which is being used in
Java. Many times in my career I had to compare two strings but ignore case
sensitivity.

I had to convert it first and then I could compare. I'd like developers to
be able to use the function and compare two strings without worrying about
case sensitivity.
1. Syntax

String.prototype.ignoreCase = function(value, arrayOfStrings) {
var secondOption = value.toLowerCase() ||
arrayOfStrings.join(',').toLowerCase().split(',');
var firstOption = this.valueOf().toLowerCase();
if(typeof secondOption === 'object') {
for(var i = 0, l = arrayOfStrings.length; i < l; i++) {
if(firstOption === secondOption[i]) {
return true;
break;
}
}
} else {
if(firstOption === secondOption) {
return true;
} else {
return false;
}
}
};

Above code presents *ignoreCase* function and what's happening inside.

The function takes two parameters:

(value, arrayOfStrings)
1.1
"value" parameter

The value parameter is the string which is going to be compared with the
parent string chosen by the developer, for example:

const stringOne = "Matheus";stringOne.ignoreCase("matheus"); // true;

1.2
"arrayOfStrings" parameter

The "arrayOfStrings" parameter is an array of strings, which are going to
be compared with the parent string chosen by the developer. Once the parent
string equals one of the strings in an array, it will return true and stops
iterating through.

Example:

const stringOne = "Matheus";const manyStrings = ['robert', 'lucas',
'matheus'];stringOne.ignoreCase('', manyStrings) // true;

2. Response

The function is going to return true or false. The result depends on
equality between chosen strings.
3. How does it
work?

The function converts all of the strings, which the developer chose to the
lower case. After performing the previous operation, it compares all of
them. If at least one, equals the provided parent string, then the function
returns true.


You can the proposal on my GitHub:
https://github.com/robertjwozniak/ignoreCase


-- 
Regards,
Robert Wozniak
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss