Да нет, это вполне себе модули (ну, некий частный случай с определёнными свойствами, которые вам — и не только вам — нужны). Я глумился именно над попыткой объяснять простое понятие (модуль — простая, базовая вещь) через сложное.
По мне, достаточно того, что bisect найдёт "сломали, когда вмержили ветку". Дальше проверяем уже её (что, как правило, не понадобится, если ветка была на одну задачу).
Ok, не те же (в принципе, понятно: скрытые классы делаются и без слова class; можно реализовать классы без скрытых классов, чисто как синтаксический сахар).
Вопрос: при "правильном" использовании класса (все поля инициализируются в конструкторе) объекты одного класса попадут в один скрытый класс?
Если да, то вопрос 2: использует ли это движок для оптимизации?
Ну и чуть сторонний вопрос 3: какой-нибудь linter может отслеживать, чтобы не попасть на деоптимизацию, или это надо переходить на TypeScript?
В Objective C так тоже можно, хотя язык не на прототипах.
Наверное, в качестве примера вам следовало задать функцию не прототипу, а экземпляру объекта, или переопределить метод где-то в середине цепочки наследования — при этом как раз всплывает разница между наследованием от прототипа и от класса.
Но я понял вашу мысль: что бы там ни было внутри — prototype-based поведение javascript будет эмулироваться до упора.
Моя мысль была — что если написали "class" — можно считать, что это настоящий класс (и получать выигрыш по быстродействию), пока программист не докажет обратное (а во всех руководствах будет написано "не делать так никогда, performance penalty"). Довольно очевидная оптимизация.
Статья, где описано преобразование — https://habrahabr.ru/post/154537/
Т.е. на итог получим "классы — сахар для прототипов, которые потом будут преобразованы в классы".
Вот я и думаю — разве создатели js-движка преобразования туда-обратно не захотят убрать? И не думали ли они об этом, ещё когда предложение только вносилось?
Абсолютно уверены? Перечитайте https://habrahabr.ru/post/154537/ и скажите, не сделает ли разумный разработчик javascript-движка классы классами, скатываясь в прототипы только при невозможности остаться в рамках класса?
(мрачно) Плюс (читал где-то) антибиотики там используют куда активнее, чуть ли не на каждый чих. Очень похоже на масштабный эксперимент, вот только если там и правда начнут умирать пачками — то и до нас докатится.
Насчёт классов в ECMAScript 6 — разве они не введены отчасти для того, чтобы "законно" иметь настоящие классы, без оверхеда от эмуляции через прототипы? Тут недавно проходила статья про оптимизации в V8, так там описывалось, как prototype-based объекты фактически преобразуются в class-based для ускорения, а тут можно сразу быстро сделать.
Не совсем — билет в посте _может_ быть корректно и однозначно выдан с датами прилёта/вылета по времени аэропортов (время и вылета, и прилёта — однозначное). Я же говорил про ещё худшую проблему — когда дважды встречающееся местное время фигурирует в самом билете. И этого нельзя избежать при текущих правилах выдачи билетов, разве что переделать их, как предложил Drakoninarius.
Грубый пример: пусть вероятность словить баг 1%, вероятность того, что юзер баг зарепортит — 1%, что пробьётся через бюрократию — 1% (числа с потолка). Итого вероятность прохождения всей цепочки — один на миллион. Если у компании миллионы пользователей — есть шанс, что баг будет исправлен. Если тысячи — практически нет.
Конечно, есть ещё много других вещей, влияющих на вероятность исправления, но «количество запусков» всё же очень значимо.
Размер влияет на вероятность того, что они с этим багом уже сталкивались. Грубо говоря, приложение лучше протестировано (пользователями), чем малоизвестные.
Тут вы из-за бага пострадали, а представьте себе ситуацию: вылет в 2:30, а в 3:00 переводят часы назад на 1 час (дата не меняется). Вылет в первые 2:30 или во вторые?
С себя, как вы понимаете, никто увольнять не начинает.
Если есть кто-то сверху над Риком и менеджерами — возможно, он их уволит/уволил за некомпетентность. Это разумно (число грузовика — очень простой индикатор, и менеджер, не отслеживающий его, мягко говоря вызывает сомнения в своей компетентности).
Но в любом случае ситуацию уже довели до момента, когда Рика им было не сохранить. А манагеров ещё можно обучить и использовать.
О каком менеджменте вы говорите? Его не было как такового, одна большая ошибка с неизбежным плохим концом. Не возникло бы конфликта — случилось бы что-нибудь ещё. Начиная с того самого пресловутого грузовика и заканчивая тем, что разработчика могли сманить в другую фирму. Ну или Рик женился бы на ежихе и уехал жить в дурдом (весьма вероятно при таком ритме работы).
Понятно, что проблема была не в Рике. Не он создал эту ситуацию. Но решать её так или иначе надо. Не смогли по хорошему (договориться с Риком и ввести людей в проект так, чтобы любой кусок понимало хотя бы 2-3 человека) — значит, проиграли, надо бросать полотенце и начинать всё с начала.
Пофиг кто виноват, число грузовика = 1 — абсолютно ненормальная ситуация, давящая на всех. Кто-то должен был это прекратить — или Рик, или компания. Остальное — эмоции и поиск козла отпущения.
Странный подход. Не логичнее сменить антивирус? Возможно даже, через неделю сможете вернуться обратно.
Да нет, это вполне себе модули (ну, некий частный случай с определёнными свойствами, которые вам — и не только вам — нужны). Я глумился именно над попыткой объяснять простое понятие (модуль — простая, базовая вещь) через сложное.
"Модуль — это что-то вроде микросервиса" — как мне развидеть это? Завтра будет "функция — это что-то вроде http-запроса"?
По мне, достаточно того, что bisect найдёт "сломали, когда вмержили ветку". Дальше проверяем уже её (что, как правило, не понадобится, если ветка была на одну задачу).
Ok, не те же (в принципе, понятно: скрытые классы делаются и без слова class; можно реализовать классы без скрытых классов, чисто как синтаксический сахар).
Вопрос: при "правильном" использовании класса (все поля инициализируются в конструкторе) объекты одного класса попадут в один скрытый класс?
Если да, то вопрос 2: использует ли это движок для оптимизации?
Ну и чуть сторонний вопрос 3: какой-нибудь linter может отслеживать, чтобы не попасть на деоптимизацию, или это надо переходить на TypeScript?
В Objective C так тоже можно, хотя язык не на прототипах.
Наверное, в качестве примера вам следовало задать функцию не прототипу, а экземпляру объекта, или переопределить метод где-то в середине цепочки наследования — при этом как раз всплывает разница между наследованием от прототипа и от класса.
Но я понял вашу мысль: что бы там ни было внутри — prototype-based поведение javascript будет эмулироваться до упора.
Моя мысль была — что если написали "class" — можно считать, что это настоящий класс (и получать выигрыш по быстродействию), пока программист не докажет обратное (а во всех руководствах будет написано "не делать так никогда, performance penalty"). Довольно очевидная оптимизация.
Статья, где описано преобразование — https://habrahabr.ru/post/154537/
Т.е. на итог получим "классы — сахар для прототипов, которые потом будут преобразованы в классы".
Вот я и думаю — разве создатели js-движка преобразования туда-обратно не захотят убрать? И не думали ли они об этом, ещё когда предложение только вносилось?
Абсолютно уверены? Перечитайте https://habrahabr.ru/post/154537/ и скажите, не сделает ли разумный разработчик javascript-движка классы классами, скатываясь в прототипы только при невозможности остаться в рамках класса?
(мрачно) Плюс (читал где-то) антибиотики там используют куда активнее, чуть ли не на каждый чих. Очень похоже на масштабный эксперимент, вот только если там и правда начнут умирать пачками — то и до нас докатится.
Насчёт классов в ECMAScript 6 — разве они не введены отчасти для того, чтобы "законно" иметь настоящие классы, без оверхеда от эмуляции через прототипы? Тут недавно проходила статья про оптимизации в V8, так там описывалось, как prototype-based объекты фактически преобразуются в class-based для ускорения, а тут можно сразу быстро сделать.
Подозреваю, что так и делается. Криво, но это меньшее из зол.
Юзер часто не замечает, что что-то загрузило проц. Например, кривой javascript в браузере.
Если я правильно помню, в билетах время вылета и прилёта ставится по местному.
Грубый пример: пусть вероятность словить баг 1%, вероятность того, что юзер баг зарепортит — 1%, что пробьётся через бюрократию — 1% (числа с потолка). Итого вероятность прохождения всей цепочки — один на миллион. Если у компании миллионы пользователей — есть шанс, что баг будет исправлен. Если тысячи — практически нет.
Конечно, есть ещё много других вещей, влияющих на вероятность исправления, но «количество запусков» всё же очень значимо.
Тут вы из-за бага пострадали, а представьте себе ситуацию: вылет в 2:30, а в 3:00 переводят часы назад на 1 час (дата не меняется). Вылет в первые 2:30 или во вторые?
С себя, как вы понимаете, никто увольнять не начинает.
Если есть кто-то сверху над Риком и менеджерами — возможно, он их уволит/уволил за некомпетентность. Это разумно (число грузовика — очень простой индикатор, и менеджер, не отслеживающий его, мягко говоря вызывает сомнения в своей компетентности).
Но в любом случае ситуацию уже довели до момента, когда Рика им было не сохранить. А манагеров ещё можно обучить и использовать.
О каком менеджменте вы говорите? Его не было как такового, одна большая ошибка с неизбежным плохим концом. Не возникло бы конфликта — случилось бы что-нибудь ещё. Начиная с того самого пресловутого грузовика и заканчивая тем, что разработчика могли сманить в другую фирму. Ну или Рик женился бы на ежихе и уехал жить в дурдом (весьма вероятно при таком ритме работы).
Понятно, что проблема была не в Рике. Не он создал эту ситуацию. Но решать её так или иначе надо. Не смогли по хорошему (договориться с Риком и ввести людей в проект так, чтобы любой кусок понимало хотя бы 2-3 человека) — значит, проиграли, надо бросать полотенце и начинать всё с начала.
Пофиг кто виноват, число грузовика = 1 — абсолютно ненормальная ситуация, давящая на всех. Кто-то должен был это прекратить — или Рик, или компания. Остальное — эмоции и поиск козла отпущения.