Is this sarcastic?
On 21 Mar 2018 12:58, "kai zhu" <[email protected]> wrote:
> this is why let and const should *never* have been introduced. if we had
> stuck with just var, none of these petty-arguments and bickering among
> team-members/shops on scoping-styles that ultimately have *zero*
> productivity or benefit to web-projects would be possible.
>
> and there's nothing wrong with pre-declaring all variables at the
> top-level of a function (which is an es5 best-practice that’s still valid
> today), regardless whether some are only used in conditional-blocks or not,
> like this real-world example [1]:
>
> ```
> local.validateBySwaggerSchema = function (options) {
> /*
> * this function will validate data against schema
> * http://json-schema.org/draft-04/json-schema-validation.
> html#rfc.section.5
> */
> var $ref,
> circularList,
> data,
> dataReadonlyRemove2,
> ii,
> oneOf,
> schema,
> test,
> tmp;
> ...
> // dereference schema.$ref
> $ref = schema && schema.$ref;
> if (!$ref) {
> break;
> }
> ...
> tmp = typeof data;
> if (tmp === 'object' && Array.isArray(data)) {
> tmp = 'array';
> }
> ...
> if (schema === local.swaggerSchemaJson.definitions.jsonReference) {
> ...
> }
> ...
> };
> ```
>
> [1] https://github.com/kaizhu256/node-swgg/blob/2018.2.1/lib.swgg.js#L4076
>
> -kai
>
> On Mar 21, 2018, at 7:15 PM, Jordan Harband <[email protected]> wrote:
>
> ```
> if (someComplicatedCondition()) {
> doSomeLogic();
> doSomeOtherLogic(if.value, true);
> }
> ```
>
> On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo <[email protected]> wrote:
>
>> Here are my gripes with `let` and `const` returning values:
>>
>> 1) declaration lists are hard to read:
>>
>> if ((let x = 10, y = 20) > 15) {
>> // true, but what's being compared here? 10 or 20? (answer: 20)
>> }
>>
>> Although right now this is allowed and the last element is compared:
>>
>> if ((x = 10, y = 20) > 15) {
>> // result is true, 20 > 15
>> }
>>
>> 2) Destructuring assignments are also confusing, what's being compared
>> here?
>>
>> if(let [x,y] = [1,2]) {
>> }
>>
>> Again, this is allowed as of today:
>>
>> if([x,y] = [1,2]) {
>> // true, as it returns [1,2]
>> }
>>
>> 3) Nesting `let/const` would be either expected everywhere (not only
>> in the `if`) or a possible side effect from the implementation.
>> Similar to languages such as Perl.
>>
>> let x = foo(let y = 100, z = 200); // what's the scope of x and z?
>>
>> This leads to hard to read and very confusing code golf.
>>
>> That's why Golang went with something simple,
>> `if([declaration];[conditional])`, and avoided confusion over `:=`
>> assignments returning values anywhere in the code. `x:=( y:= 20 )` is
>> not allowed in Go.
>>
>> It expands on the 45-year tried-and-true structure of `for(;;)` to
>> create `if(;)` and keep the ES language simple and clear expanding on
>> its own concept of `for(;;)`.
>>
>> On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla <[email protected]>
>> wrote:
>> > OK I neglected to read the original post fully. My last post example
>> would
>> > be based on allowing `const` and `let` declarations to expressions in of
>> > themselves (in the case of multi variables, returning the last one). So
>> let
>> > me ask, what exactly would be the problem with this?
>> >
>> > On Wed, 21 Mar 2018 at 12:20 Naveen Chawla <[email protected]>
>> wrote:
>> >>
>> >> What would `if.value` look like in an example?
>> >>
>> >> Wouldn't it be possible to have something like `if(const x = getX() &&
>> >> const y = getY())` to capture more than just the conditional if
>> required?
>> >> I'm guessing that would probably break something somewhere, but I'm
>> not sure
>> >> what.
>> >>
>> >> On Wed, 21 Mar 2018 at 04:35 Jordan Harband <[email protected]> wrote:
>> >>>
>> >>> Is the use case only ever to capture the thing that serves as the
>> >>> conditional?
>> >>>
>> >>> If so, would perhaps something like `if.value` work better? Since
>> it's a
>> >>> keyword, it could be made to only work in the `if` block, and you
>> wouldn't
>> >>> need any of that odd multi-statement stuff in the conditional parens.
>> >>>
>> >>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo <[email protected]>
>> wrote:
>> >>>>
>> >>>> Proposal: inline let/const statements to declare and initialize
>> >>>> variables within if statements, so that temporary variables exist
>> only
>> >>>> within the if/else block scope.
>> >>>>
>> >>>> Reason: limits variable scope to the block where really needed, in
>> >>>> similar fashion to variables defined in for(;;) statements. This
>> >>>> improves readability while reducing unnecessary variables roaming
>> >>>> outside their needed block.
>> >>>>
>> >>>> The syntax would be very similar to the for(;;) assignment/test pair:
>> >>>>
>> >>>> if (let x = 100; x > 50) {
>> >>>> console.log(x); // 100
>> >>>> }
>> >>>> console.log(x); // ReferenceError
>> >>>>
>> >>>> // same for const
>> >>>> if( const x = foo(); typeof x === 'object' ) {
>> >>>> //...
>> >>>> }
>> >>>>
>> >>>> // the variable is available within any else block
>> >>>> // after its declaration
>> >>>> if (let x = foo(); x < 50) {
>> >>>> console.log(x); // y is not available here
>> >>>> } else if (let y = bar(); y > 0) {
>> >>>> console.log(x, y);
>> >>>> } else {
>> >>>> console.log(x, y);
>> >>>> }
>> >>>>
>> >>>> Right now there isn't a way to limit a variable to the if block:
>> >>>>
>> >>>> let x = 100;
>> >>>> if (x > 50) {
>> >>>> console.log(x);
>> >>>> }
>> >>>> // x is in scope, but may not be needed beyond the if statement
>> >>>> console.log(x);
>> >>>>
>> >>>> // or a non-strict assignment, which also "leaks" scope
>> >>>> if( (x = 100) > 50 ) {
>> >>>> // ...
>> >>>> }
>> >>>>
>> >>>> There are many "workarounds" available, here's a few:
>> >>>>
>> >>>> // workaround 1: can be remedied with a scope block
>> >>>> // but it's asymmetrical and non-idiomatic
>> >>>> {
>> >>>> let x = 100;
>> >>>> if (x > 50) {
>> >>>> console.log(x);
>> >>>> }
>> >>>> }
>> >>>>
>> >>>> // workaround 2: with a for statement
>> >>>> // but this is non-idiomatic, hard to read and error-prone
>> >>>> for (let x = 100; x > 50;) {
>> >>>> console.log(x);
>> >>>> break;
>> >>>> }
>> >>>>
>> >>>> If-initialization is available in many languages (Go, Perl and Ruby
>> >>>> come to mind) and are considered best practice in each one of them:
>> >>>>
>> >>>> // Golang - x is defined, assigned and conditionally tested
>> >>>> if x := 100; x > 50 {
>> >>>> // x is in scope here
>> >>>> } else {
>> >>>> // and in here
>> >>>> }
>> >>>> // x is not available here
>> >>>>
>> >>>> ###### Perl
>> >>>> if( my $x = 100 ) {
>> >>>> print $x;
>> >>>> }
>> >>>> print $x; # an error
>> >>>>
>> >>>> if ( ( my $x = myfoo() ) > 50 ) { # also ok in Perl
>> >>>> print $x;
>> >>>> }
>> >>>>
>> >>>> ###### Ruby
>> >>>> if ( x = 100 ) # parens required per style guide
>> >>>> puts(x)
>> >>>> end
>> >>>> puts(x) # unfortunately Ruby does not limit scope to if, so x
>> >>>> "leaks"
>> >>>>
>> >>>> I think this would be a great and important addition to the language.
>> >>>>
>> >>>> -Rodrigo
>> >>>>
>> >>>> PS: Just for the sake of comparison, Perl-style if-assignments could
>> >>>> also be an
>> >>>> option, albeit a very bad one IMO:
>> >>>>
>> >>>> if( ( let x = 100 ) > 50 ) {
>> >>>> }
>> >>>>
>> >>>> A Perl-style, value-returning let/const has readability issues, opens
>> >>>> quite a few fronts and sort of implies that let/const can return
>> >>>> values anywhere in the code outside if/else. On the other hand it
>> >>>> would fit with the currently if assignment if( x = y ). Definitely
>> not
>> >>>> recommended.
>> >>>> _______________________________________________
>> >>>> es-discuss mailing list
>> >>>> [email protected]
>> >>>> https://mail.mozilla.org/listinfo/es-discuss
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> es-discuss mailing list
>> >>> [email protected]
>> >>> https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
