const obj = { a: 'b', c: 'd', [Symbol.iterator]: function * () { for (const kv of Object.entries(this)) { yield kv } } } for (const [key, val] of obj) { console.log('key=' + key) console.log('val=' + val) }

> "key=a" > "val=b" > "key=c" > "val=d"

насколько я знаю, div1 никогда не сможет находиться между вторым и четвертым силами css)

const obj = { a: 'b', c: 'd', [Symbol.iterator]: function * () { for (const kv of Object.entries(this)) { yield kv } } } for (const [key, val] of obj) { console.log('key=' + key) console.log('val=' + val) }

Итерируемый на уровне языка != итерируемый на уровне памяти.

Итерируемый на уровне языка != итерируемый на уровне памяти.

Что значит на уровне языка? Какая разница между тем когда for of ищет Symbol.iterator в массиве и когда ищет Symbol.iterator в объекте? Или ты имеешь ввиду что в массиве это by design заложено?

ну я бы по-другому и не сделал)

Уже начали. Object.keys и т.д.

Но никак не закончат. Object.entries в черновике свежего стандарта, это немного не похоже на решение какой-то выдуманной тобой проблемы

Что значит на уровне языка? Какая разница между тем когда for of ищет Symbol.iterator в массиве и когда ищет Symbol.iterator в объекте? Или ты имеешь ввиду что в массиве это by design заложено?

В том что у тебя в итераторе создаётся новый объект, который содержит все пары. А в случае Мапы такого объекта не создаётся.

Но никак не закончат. Object.entries в черновике свежего стандарта, это немного не похоже на решение какой-то выдуманной тобой проблемы

Какую проблему я выдумал?

ну я бы по-другому и не сделал)

Да вот хз, может варианты еще какие есть тип тут сейчас неточность, есть, элемент с любым индексом больше 0 будет выше дива 2

const obj = { a: 'b', c: 'd', [Symbol.iterator]: function * () { for (const kv of Object.entries(this)) { yield kv } } } for (const [key, val] of obj) { console.log('key=' + key) console.log('val=' + val) }

Во, это уже называется полифилл :)

От этого for (const [k, v] of Object.entries({a:'b', c: 'd'})) { console.log('key='+k) console.log('val='+v) } до этого foreach (k, v) in {a:'b', c: 'd'} { console.log('key='+k) console.log('val='+v) }

В том что у тебя в итераторе создаётся новый объект, который содержит все пары. А в случае Мапы такого объекта не создаётся.

а ты про семантику использования ну тут согласен

ну я бы по-другому и не сделал)

Спасибо за помощь ) сейчас преподу отправлю, посмотрим, что ответит

Вот тот же твой пример обсахарить - и получился бы мой :)

Вот тебе сахарок: function* _(obj) { for (const key of Object.keys(obj)) { yield [key, obj[key]]; } } for (let [key, value] of _({ a: "A", b: "B"})) { console.log(`${key}: ${value}`); }

От этого for (const [k, v] of Object.entries({a:'b', c: 'd'})) { console.log('key='+k) console.log('val='+v) } до этого foreach (k, v) in {a:'b', c: 'd'} { console.log('key='+k) console.log('val='+v) }

Первый вариант лучше.

Спасибо за помощь ) сейчас преподу отправлю, посмотрим, что ответит

давай)

Вот тебе сахарок: function* _(obj) { for (const key of Object.keys(obj)) { yield [key, obj[key]]; } } for (let [key, value] of _({ a: "A", b: "B"})) { console.log(`${key}: ${value}`); }

Но всё равно это промежуточная функция. Гораздо эффективней переделать Object.entries, чтобы он итерировал

Потому что массив из одного ключа и одного значения это ужасно некрасиво

Но всё равно это промежуточная функция. Гораздо эффективней переделать Object.entries, чтобы он итерировал

Зачем?

Если уж так - то лучше ключ и значение отдельно

Т.е. вместо 1 метода ты предлагаешь сделать 3? map, filter и reduce?

Но всё равно это промежуточная функция. Гораздо эффективней переделать Object.entries, чтобы он итерировал

Одно и тоже. Что то Object.entries возвращает генератор, что этот сахарок

Т.е. вместо 1 метода ты предлагаешь сделать 3? map, filter и reduce?

Нет

От этого for (const [k, v] of Object.entries({a:'b', c: 'd'})) { console.log('key='+k) console.log('val='+v) } до этого foreach (k, v) in {a:'b', c: 'd'} { console.log('key='+k) console.log('val='+v) }

Если зайти из далека JS хорош тем что коммюнити очень открыто к новым предложениям Если ты сможешь обосновать нахрен это нужно в следующей версии стандартна, распишешь синтаксис и будешь мейнтейнить обсуждение этой фичи - то твою идею примут

Одно и тоже. Что то Object.entries возвращает генератор, что этот сахарок

Разница только в нативности :) Сахарить свой код не дожидаясь стандартов - это старая жкверевская привычка, и всё же она старая :)

Разница только в нативности :) Сахарить свой код не дожидаясь стандартов - это старая жкверевская привычка, и всё же она старая :)

Я вру! Object.entries возвращает массив. Так что мой сахарок даже попроизводительнее будет, так как он ленивый

Разница только в нативности :) Сахарить свой код не дожидаясь стандартов - это старая жкверевская привычка, и всё же она старая :)

Ты можешь нативно писать Object.Entries.forEach

Если зайти из далека JS хорош тем что коммюнити очень открыто к новым предложениям Если ты сможешь обосновать нахрен это нужно в следующей версии стандартна, распишешь синтаксис и будешь мейнтейнить обсуждение этой фичи - то твою идею примут

Нет, я прекрасно проживу без этого. Меня просто удивило то, из-за чего я и пондял эту тему - что мы тут сахарим черновые стандарты следующих лет (!!!), а в сраном пхп это с нулевых, если не раньше

Я вру! Object.entries возвращает массив. Так что мой сахарок даже попроизводительнее будет, так как он ленивый

Ленивость != скорость во многих кейсах.

Ленивость != скорость во многих кейсах.

Если будет early return то очень даже

V8 умеет перемалывать через map, filter и т.д. очень производительно.

Нет, я прекрасно проживу без этого. Меня просто удивило то, из-за чего я и пондял эту тему - что мы тут сахарим черновые стандарты следующих лет (!!!), а в сраном пхп это с нулевых, если не раньше

ну JS вырос из скриптов анимации в браузере, а php задумывался как ЯП

Я вру! Object.entries возвращает массив. Так что мой сахарок даже попроизводительнее будет, так как он ленивый

Object.entries может быть гораздо производительней твоих отдельных вызовов

V8 умеет перемалывать через map, filter и т.д. очень производительно.

сколько лет вы программируете?

сколько лет вы программируете?

Зависит от того, что называть программированием.

Зависит от того, что называть программированием.

ну если сильно утрировать C#/JS

ну JS вырос из скриптов анимации в браузере, а php задумывался как ЯП

Что не мешает разработчикам стандартов делать гигантские шаги в отказе от старья :) А нам мечтать о всякой переслащённо фигне :) Я вот линк хочу, но многие не хотят

Что не мешает разработчикам стандартов делать гигантские шаги в отказе от старья :) А нам мечтать о всякой переслащённо фигне :) Я вот линк хочу, но многие не хотят

Что тебе из линка надо?

Что тебе из линка надо?

То же, что и от вышеупомянутого пхпшного форыча

Запись и красота кода

var top = from await getItems() select name where id > 5 order by updatedDate desc group by groupId having groupId > 10;

omg

То самое говно, которое дотнетчики избегают сейчас.

Видимо, ты не в курсе о цепочной записи

Проблема в том, что она длиннее, мусорнее и недекларативнее

Хотя в каком-то виде реализуема и в жс нативно

В курсе. В js уже есть эта цепочная запись.

А вот ту ебанину, которую ты написал выше не нужно.

var top = from await getItems() select name where id > 5 order by updatedDate desc group by groupId having groupId > 10;

с первого дня релиза линка избегал SQL-like записи цепочка гораздо понятнее и легче контроллируется

Так что тебе надо из линка, чего нет в js?

с первого дня релиза линка избегал SQL-like записи цепочка гораздо понятнее и легче контроллируется

но длиннее и тяжелее читается

скобки и аргументы хотя бы

в новых стандартах JS будет пайплайнинг что гораздо лучше чем линк

Впрочем, если это надо переиспользовать, то конечно лучше цепочная, потому что оборачивать это в чейн будет гораздо ужаснее

в новых стандартах JS будет пайплайнинг что гораздо лучше чем линк

йамми

хочу пайплайнинг в дотнет

хочу пайплайнинг в дотнет

Он есть уже фиг знает сколько времени.

F# называется.

Уточню: в C#.NET

В C# уже и так говна навалом. Ещё и пайплайн тащить.

Вот вообще без враппера: Object.prototype[Symbol.iterator] = function* () { for (const key of Object.keys(this)) { yield [key, this[key]]; } } for (let [key, value] of { a: "A", b: "B"}) { console.log(`${key}: ${value}`); } Но так делать не стоит

А ещё я хочу кортежи. А ещё out-переменные.

Ладно, подожду null-coalesce, не буду никого нервировать

А ещё я хочу кортежи. А ещё out-переменные.

Кортежи у тебя есть.

Я уже про жс

ERROR: S client not available

Я тоже.

Вот вообще без враппера: Object.prototype[Symbol.iterator] = function* () { for (const key of Object.keys(this)) { yield [key, this[key]]; } } for (let [key, value] of { a: "A", b: "B"}) { console.log(`${key}: ${value}`); } Но так делать не стоит

у тебя теперь есть персональный котел в аду)

у тебя теперь есть персональный котел в аду)

Написано же "так делать не стоит")

Вот вообще без враппера: Object.prototype[Symbol.iterator] = function* () { for (const key of Object.keys(this)) { yield [key, this[key]]; } } for (let [key, value] of { a: "A", b: "B"}) { console.log(`${key}: ${value}`); } Но так делать не стоит

Я запомню и если что буду всё сваливать на тебя :)

Я запомню и если что буду всё сваливать на тебя :)

Тяжело что-то говорить, когда тебя уже бьют ногами.

А ещё я хочу кортежи. А ещё out-переменные.

А out переменные кривые, поэтому их брать не будут.

Ок

Особенно в js, где типов нет.

out переменные не нужные когда есть деструктуризация

out переменные не нужные когда есть деструктуризация

Нет.

возвращаешь столько переменных сколько нужно

возвращаешь столько переменных сколько нужно

Их суть не в этом.

Вот вообще без враппера: Object.prototype[Symbol.iterator] = function* () { for (const key of Object.keys(this)) { yield [key, this[key]]; } } for (let [key, value] of { a: "A", b: "B"}) { console.log(`${key}: ${value}`); } Но так делать не стоит

Ну отсутствие враппера всё же заменяет мутация прототипа. Такие штуки либо быть не должны, либо должны быть нативно и чисто )

А то я опять вспомню жквери, где простота, скорость и сахар реализуются за счёт надстройки над языком :)

возвращаешь столько переменных сколько нужно

А в том, что ты можешь писать подобный код if (!int.TryParse(str, out var num)) { throw new Exception(); } Console.WriteLine(num);

Но out переменные не работают с асинхронными методами, так как возникают проблемы.

Их суть не в этом.

Именно в этом

А в том, что ты можешь писать подобный код if (!int.TryParse(str, out var num)) { throw new Exception(); } Console.WriteLine(num);

А это всего лишь узкий случай их применения

А это всего лишь узкий случай их применения

Это основной их способ применения.

А в том, что ты можешь писать подобный код if (!int.TryParse(str, out var num)) { throw new Exception(); } Console.WriteLine(num);

Это ужастно особенно если вспомнить что можно возвращать и по ref

Это основной их способ применения.

Странно, что ты называешь частный случай основным способом, но я не буду с тобой спорить

туплеты намного элегантнее

Это основной их способ применения.

const {success, value: num} = int.tryParse(str)

туплеты намного элегантнее

Но подобный код будет выглядеть как говно.

туплеты намного элегантнее

Так их ещё никто не оскорблял ))

const {success, value: num} = int.tryParse(str)

Запихни это в if

Не надо запихивать это в if ни то и не другое

Не надо запихивать это в if ни то и не другое

Почему не надо? Try* как раз для этого и создаётся.

В остальных случаях надо возвращать структуры.

Потому что читабельность такого выражение в if плохая

Потому что читабельность такого выражение в if плохая

Значит у меня глаз замылен.

Пишу "по пачке в день" таких выражений.