Полноценный рут на Win — это «выполнить из-под пользователя SYSTEM». Он и так закрыт, технически, т.к. требует некоторых танцев с бубном для использования. А «Администратор» — это вообще не рут, даже не близко.
Реального выбора на PC пока нет. Как минимум, для геймеров и win-разработчиков. И не будет, пока не потеряется фактическая монополия win. А она не потеряется, пока не появится выбор. Замкнутый круг.
3-4 однотипных — «ну неудобно». С т.з. производительности, конечно, нужно смотреть в каждом конкретном случае. В том же C++ влияние на производительность от «дополнительных DTO» — гораздо сильнее, чем в managed-языках, но ключевой момент именно в балансе «удобство\эффективность\производительность», в зависимости от конкретных целей и задач.
Зависит от конкретной ситуации и требований. С методом, допустим, принимающим восемь строк очень неудобно и ошибкоопасно работать — а это случай из реальной практики. Обертка всего этого в DTO убрала кучу «случайных» ошибок.
"Что и требовалось доказать" — язык нужно выбирать под задачу. Подавляющее большинство задач "общего назначения" — лучше решаются на C#, чем на C++, т.к. C++ сейчас является всё-таки языком "местного назначения".
Он рвёт в клочья в определенном наборе задач, но слишком сильно удорожает разработку "in general".
P.S. Сам знаю оба, использую по уместности.
С целью, естественно, максимальной гибкости системы. Туда же и тему выше про многоженство\многомужество, в мире куча разных вариантов, и стоит поддерживать все, тем более, что это "почти бесплатно" с т.з. кода
man.get_married(woman) — женить man на woman.
man.is_married() — женат ли man?
man.is_married(woman) — женат ли man на этой woman?
man.get_wife() — получить информацию о той woman, на которой женат этот man.
но с полноценными пропертями это переписывается красивее…
man.GetMarried(woman) — жениться
man.Wife — возвращает жену или null
man.IsMarried — возвращает man.Wife != null
man.IsMarried(woman) — возвращаеет man.Wife == woman
Для многоженства надо писать вариант с man.Wives, с возвратом массива\списка\иного IEnumerable, ну и в прочем учесть
www реально не нужен, это пережиток прошлого, я бы, если честно, вообще это перестал считать "поддоменом" и в виде исключения прямо удалял из запроса на уровне браузеров...
Даже вариант «в начале» уже отличный. А наличие возможности улучшать геном — прямой путь к искусственной эволюции в ее нормальном понимании. Сейчас, увы, искусственная деволюция — спасают заведомо негодные элементы.
Реального выбора на PC пока нет. Как минимум, для геймеров и win-разработчиков. И не будет, пока не потеряется фактическая монополия win. А она не потеряется, пока не появится выбор. Замкнутый круг.
Никаких исходников им МС 100% не даст.
"Умерла, так умерла".
есть же isomorphic-fetch, например
Это практически везде так, кроме электроники, в электронике граница "а вот не публикуем цены" проходит где-то по 300-500к.
"Что и требовалось доказать" — язык нужно выбирать под задачу. Подавляющее большинство задач "общего назначения" — лучше решаются на C#, чем на C++, т.к. C++ сейчас является всё-таки языком "местного назначения".
Он рвёт в клочья в определенном наборе задач, но слишком сильно удорожает разработку "in general".
P.S. Сам знаю оба, использую по уместности.
Сигнатура (int, int, int) вообще "не очень" по сути своей, там уже явно тянет отдельной структурой Params.
Однозначно, это должно быть личное решение экземпляра класса.
А то в некоторых странах этот метод вытащен в паблик, хоть и "наоборот".
С целью, естественно, максимальной гибкости системы. Туда же и тему выше про многоженство\многомужество, в мире куча разных вариантов, и стоит поддерживать все, тем более, что это "почти бесплатно" с т.з. кода
Вот я хотел это написать, но комментарий отредактировать не получилось.
Так-то стоит обоих наследовать от Person.
Для устранения путаницы должно быть так, ИМХО:
man.get_married(woman) — женить man на woman.
man.is_married() — женат ли man?
man.is_married(woman) — женат ли man на этой woman?
man.get_wife() — получить информацию о той woman, на которой женат этот man.
но с полноценными пропертями это переписывается красивее…
man.GetMarried(woman) — жениться
man.Wife — возвращает жену или null
man.IsMarried — возвращает man.Wife != null
man.IsMarried(woman) — возвращаеет man.Wife == woman
Для многоженства надо писать вариант с man.Wives, с возвратом массива\списка\иного IEnumerable, ну и в прочем учесть
Сегодня утром Steam пропатчился и в списке изменений есть исправления, судя по всему, как раз этого.
https://store.steampowered.com/news/53677/
www реально не нужен, это пережиток прошлого, я бы, если честно, вообще это перестал считать "поддоменом" и в виде исключения прямо удалял из запроса на уровне браузеров...