угу это неверный подход просто

Мде... Давайте в языке упростим возможность косячить?

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

Мде... Давайте в языке упростим возможность косячить?

я если что асинхронные конструкторы не защищал, а наоборот но контраргумент выше был не очень)

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

знакомы понятия цикломатическая сложность? побочные эффекты? мутабельность? и тд

знакомы понятия цикломатическая сложность? побочные эффекты? мутабельность? и тд

ну от части - тем более, если перевести эти определения в пару фраз особой сложности тогда вообще не вижу

ну от части - тем более, если перевести эти определения в пару фраз особой сложности тогда вообще не вижу

зачем от кода добиваются детерминизма?

зачем от кода добиваются детерминизма?

ну если я правильно понял о чем ты - для большей логичности полагаю

ну если я правильно понял о чем ты - для большей логичности полагаю

код и так логичен, языки программирования построены на логике

ну да кажется я тут в сементический ад попаду) логика бывает разная)

так что в иди туда - не знай куда тоже может быть свой логика)

только ее понятность нам будет менее очевидна)

какими качествами должна обладать строчка кода чтобы быть детерминированной?

я бы вообщем заменил на слово - понятной мне кажется так было бы проще)

я бы вообщем заменил на слово - понятной мне кажется так было бы проще)

Math.random() не детерминирован но он понятен

const car = await new Car(‘red’) ты можешь для всех случаев выполнения программы сказать какой будет результат?

const car = await new Car(‘red’) ты можешь для всех случаев выполнения программы сказать какой будет результат?

Это зависит от конструктора Car. И await тут не нужен.

Это зависит от конструктора Car. И await тут не нужен.

если есть await значит есть побочный эффект

а почему нет? если изначально знаешь алгоритмы класса

а почему нет? если изначально знаешь алгоритмы класса

куда твой асинхронный конструктор стучится?

если есть await значит есть побочный эффект

В await 0 есть побочный эффект?

В await 0 есть побочный эффект?

это вообще запустится?

это вообще запустится?

Да. await может принимать любое значение, не только промис.

Да. await может принимать любое значение, не только промис.

тогда нет потому что он раскладывается на константу и await там не нужен значит не реальный пример

"куда твой асинхронный конструктор стучится?" не совсем понимаю вопроса... что значит стучится?

тогда нет потому что он раскладывается на константу и await там не нужен значит не реальный пример

await не нужен, потому что функция, вызванная с new, априори не может вернуть промис

await не нужен, потому что функция, вызванная с new, априори не может вернуть промис

почитай сообщения выше мы тут странные идеи Дмитрия обсуждаем

ничего странного в них нет - разве что вам непривычно ну так я и предлагаю это сделать для тех кому нужно

"куда твой асинхронный конструктор стучится?" не совсем понимаю вопроса... что значит стучится?

асинхронные операции нужны для асинхронного ввода вывода как правило это либо файловая система либо обращение в интернет

либо обработка скрипта

либо обработка картинки

и много чего еще

в твоем случае что?

да чего только там нет... изначально вообще загрузка модулей под нужны класса в зависимости от параметров создания

так

давай начнем вот с чего

знаешь методологию SOLID в ООП?

первый принцип S - Single responsibility principle

так класс и не меняется

так класс и не меняется

дай пример реального асинхронного конструктора

принцип единственной ответственности

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

async class Car{ constructor(color...){ [this.part1, this.part2, this.part3] = await Promise.all([ get_path1(color1), get_path2(color2), get_path3(color3), ]); }}

это?

ну типа того да

что значит твое get_path2?

ну какая-нибудь часть машины

или ты про что имеешь в виду - текстура например

Почему машина ищет свои части?

load_texture

так лучше?

да, но все еще почему машина сама ищет свои текстуры? если это отдельный класс

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

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

машина это не сборщик машины разные сущности

если это машина - то ты должен в конструкторе предоставить все материалы

Если это машина — то после чертежа обязан сразу показать готовую тачку

кому должен? для меня это стереотип почему я должен конструктору предоставлять все материалы? если я могу просто указать то, что мне нужно

кому должен? для меня это стереотип почему я должен конструктору предоставлять все материалы? если я могу просто указать то, что мне нужно

читай SOLID

кому должен? для меня это стереотип почему я должен конструктору предоставлять все материалы? если я могу просто указать то, что мне нужно

пятый принцип в ООП D - Dependency inversion principle “Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.”

переводя на простой язык, в конструктор должны поступать готовые данные

я понял эту идею, но я не понимаю ее значения как по мне гораздо удобнее, если конструктор берет на себя всю работу в чем тут возникают проблемы можете мне пояснить?

я понял эту идею, но я не понимаю ее значения как по мне гораздо удобнее, если конструктор берет на себя всю работу в чем тут возникают проблемы можете мне пояснить?

>в чем тут возникают проблемы можете мне пояснить? все эти принципы придумали только для одного чтобы контролировать сложность исходного кода если их не соблюдать - то по ходу роста проекта, исходный код будет очень сложно понимать

как по мне как раз таки сложность растет когда вместо просто создать - нужно применить пустой инит

или когда опять же нужно самому лишний раз что-то готовить

это как раз упрощает программирование

как по мне как раз таки сложность растет когда вместо просто создать - нужно применить пустой инит

попробуй написать проект на 10К и больше строк и поговорим

ERROR: S client not available

если и так не поймешь - могу отправить читать литературу

как по мне как раз таки сложность растет когда вместо просто создать - нужно применить пустой инит

две строчки кода не усложняют код

вопрос зачем они нужны?

зачем нужен пустой инит?

чтобы был?

сложность кода растет за счет смешивания понятий которые не надо смешивать

Зачем вообще на какие-то там функции, модули и прочее разбивать? Это слижком сложно. Ещё паттерны учить - это вообще фу-фу-фу. Предлагаю всё в одном файле писать! Так гораздо проще - не надо запариваться всякими непонятными мне штуками!

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

Я вот написала свой хелловорлд на 100 срочек и считаю именно так. Моё мнение, если что.

нет зачем-то нужно отделять создание и еще инициализацию

вопрос зачем они нужны?

лол. Чуть-чуть опоздала

я могу понять если нам не нужен объект целиком и потом его дособрать

но если я хочу получить сразу все - не вижу смысла вызывать дополнительные методы

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

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

но если я хочу получить сразу все - не вижу смысла вызывать дополнительные методы

ну чувак ты локально как то мыслишь

Если попробуешь следовать правилам - то окажется что смысла в использовании асинхронного конструктора и нет вовсе

смысл есть потому что остальные подходы по работе с асинхронностью хуже вообщем я все равно так и не понимаю: проблем с использованием переменных в конструкторе и что страшного произойдет, если конструктор сам выполнит все этапы создания по заданным свойствам для меня конструктор - это именно полноценный конструктор, который создает то, что тебе нужно и ограничивать его в возможностях я смысла пока не вижу, а разграничивать почему нет пенести ту же подготовку в класс не вопрос constructor(args){ prepare_create_car(argc); } prepare_create_car() {} для меня это лишь разница подходов... да можно было сделать все тоже через argc = prepare_create_car(); car = new Car(argc); просто для меня это как раз усложнее для меня проще это вынести во внутрь класса, а во вне лишь интерфейс нужных параметров

и по сути если речь идет про синхронности там вообще даже вопросов нет

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

и что в больших проектах пустые параметры конструкторов? или ах да классы вообще не используют?

>и что в больших проектах пустые параметры конструкторов? не понял когда мы про пустой конструктор говорили?

дык а зачем там тогда вообще нужны параметры? пусть тогда все в инит будет? пусть тогда уж конструктор совсем отдыхает) зачем там тогда вообще нужны параметры?

если он по сути ничего не создает

>дык а зачем там тогда вообще нужны параметры? читай тематическую литературу я уже упомянул куда копать

тут для меня два вариант или пустой инит - или пустой конструктор

срач со вчерашнего дня)) вы не устали?

>или ах да классы вообще не используют? используют с ограничениями которые я описал

срач со вчерашнего дня)) вы не устали?

а я сегодня подхватил) вчера не участвовал)

с утра нечего делать

?

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

тогда уж можно раздели вообще на два класса если вам так это нужно