Тесты тестам рознь. Есть такие, что просто проверяют, что метод был вызван, хотя по коду это и так видно. Если кто-то решит это сломать - код-ревью же есть, не вслепую пишем. Вот такими тестами можно пожертвовать. А если какая нетривиальная логика/алгоритм, валидация - там тесты это просто обязательно, я считаю. Одни говорят "не будем писать тесты", другие говорят "сейчас устроим TDD во все поля". Почему нельзя остановиться на середине и тестировать только важные вещи?
Люблю на досуге почитывать блог https://dolphin-emu.org/, эмулятор для Wii. На какие хаки только не приходится идти в эмуляторе, чтобы запустить Wii-игру на PC/Android.
Интерфейс называется iTransport - так не принято, скорее Transport или Transportable.
У геттеров предпочтительнее не использовать префикс get: name() вместо getName()
Пример, конечно, синтетический, но непонятно, зачем интерфейс с неэкспортируемыми методами, который не обладает логикой кроме как установки полей структуры.
Эмбеддинг используется, чтобы эмулировать наследование - это не совсем идиоматично. Лучше стараться избегать такого и использовать другие решения.
Функция создания структуры возвращает интерфейс, хотя идиоматичнее возвратить конкретный тип: в Go т.н. structural typing поэтому паттерны из Java/PHP не так работают: предпочтительнее возвращать конкретные типы, а определять и использовать интерфейсы уже на уровне консьюмера/клиента, тогда структура автоматически приведется к интерфейсу без строгой номинальной привязки. Т.е. некий код говорит, что он хочет принимать в качестве аргумента нечто, что ведет себя как утка, и приведение конкретного типа к интерфейсу происходит в этот момент. Неидиоматично объявлять, что некая структура изначально удовлетворяет какой-то интерфейс (что это её якобы неотъемлемое свойство).
По сути же это просто функция, которая возвращает разные реализации интерфейса на основе входных параметров. Такого же полно в библиотеках на Go. Что этом плохого? В том, что это можно назвать "шаблоном"?
>Просто геттер должен возвращать закэшированную немутабельную копию
В конечном счёте много мороки на ровном месте: храним мутабельные, которые нельзя шарить, возвращаем иммутабельные (или аллокация, или оборачивать в интерфейс). Поэтому два пути: лепить трудноподдерживаемое спагетти или писать по-нормальному, но инвестировать в набор GC рантайма для файнтюнинга.
Не знал, что Хабр не умеет в отложенное схлапывание нескольких уведомлений в одно, это забавно. Сам я личной почтой вообще не пользуюсь, поэтому про какие-то уведомления даже не думал.
Есть такое. Более того, в рантайме есть PAL (по крайне мере, раньше было) - это, по сути, реализация подмножества Windows API средствами Unix, чтобы первоначально Windows-only код весь не переписывать (этакий простецкий winelib). В итоге и семантика виндовая, зато полная совместимость... В mono тоже был слой эмуляции Виндовой подсистемы (в основном I/O)
Но это, мне кажется, обычная практика в целом. Ведь у многих остальных языков (например Go) то же самое, только наоборот - повсюду семантика Unix, которая со скрипом заводится на Windows (приходится эмулировать). Но на это мало кто обращает внимание.
Мутабельные векторы тоже так себе идея. Если где-то случайно зашарить объект по ссылке не склонировав, то внезапно позиции рандомных объектов связаны и поди отладь что не так
>C4ET4uK 07.05.2021 в 08:04 Это просто говорит о том, что Minecraft не очень хорошо написан
Там такая история, что первоначально позиции были заинлайнены в объекты, и метод перемещения выглядет как-то вроде setPosition(1, 2, 3), что обновляло 3 поля примитивных типа без выделения памяти. Но такой подход очень неудобен, т.к. простейшие векторные вычисления превращаются в спагетти. В итоге было переписано в код вида setPosition(new Vector(1, 2, 3)) что моментально увеличило нагрузку на GC до 600 мб/с. Ну и pointer chasing если это массивы объектов (а их в Minecraft много)
> Java больше возможностей для fine-tune-инга чему способствует проработанная Memory Model и целый зоопарк Garbage Collector-ов на все случаи жизни
Все как бы немного наоборот - зоопарк сборщиков это не то что бы преимущество, а просто следствие отсутствия value objects, в итоге нагрузка на сборщик неизмеримо больше, чем в C# или Go, где by value обьекты присутствуют. Я помню в Minecraft было нормой выделять 600 мб/с мусора из-за использования векторов/матриц. В библиотеке JBullet автору приходилась написать инструментацию байткода для использования пула векторов/матриц. В C#/Go такие проблемы отсутствуют как класс.
Доводилось сравнивать реализации VM различных языков (как хобби люблю ковыряться во внутрянках рантаймов) и по моему скромному мнению Hotspot это самая продвинутая VM (по крайней мере, из мейнстримовых) по числу оптимизаций и прочих плюшек (V8 наверное где-то рядом). Правда, большая часть оптимизаций это попытки исправить неудачные моменты языка...
То, что на Java часто овериндженирят - это уже другой вопрос.
>На Линуксе же он работает только пока не начнёшь подключать родные библиотеки С++
Что вы имеете в виду? Проброс исключений C++ через фреймы CLR? Конфликты между пользовательскими обработчиками сигналов и тех что устанавливает CLR? Разница в ABI у C++ библиотек? Отсутствие COM/Winapi? Отсутствие C++/CLI?
Оборачивал библиотеки на C и не увидел проблем, кроме несуразностей вроде присутствия Unicode-маршалинга как Utf16 в P/Invoke и отсутствия Utf8 (но не знаю как с этим в .net core)
Java тормозит на запуске, особенно холодном, что сильно заметно по GUI и консольным утилитам. Но горячий сервер-то не должен тормозить, особо нет причин для этого. JVM это state of the art.
>Durability is the ability of a physical product to remain functional, without requiring excessive maintenance or repair, when faced with the challenges of normal operation over its design lifetime
Переносный смысл:
>In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently. For example, if a flight booking reports that a seat has successfully been booked, then the seat will remain booked even if the system crashes.
Выглядит так, что прочность/стойкость вполне подходят, хоть и со скрипом. Неизменность это скорее одно из проявлений durability. Вообще постоянство/неизменность могут ввести в заблуждение как термин, как будто данные не должны меняться. "Способность оставаться работоспособным при определённых форс-мажорах" это скорее вообще "надёжность [хранения]"?
Если взять определение, то очень похоже:
>Надёжность — свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных условиях применения, технического обслуживания, хранения и транспортирования
Тесты тестам рознь. Есть такие, что просто проверяют, что метод был вызван, хотя по коду это и так видно. Если кто-то решит это сломать - код-ревью же есть, не вслепую пишем. Вот такими тестами можно пожертвовать. А если какая нетривиальная логика/алгоритм, валидация - там тесты это просто обязательно, я считаю. Одни говорят "не будем писать тесты", другие говорят "сейчас устроим TDD во все поля". Почему нельзя остановиться на середине и тестировать только важные вещи?
>Это просто способ переложить вину. Менеджер чтобы продать называет нереальные сроки, а потом заставляет программиста под ними подписаться
Поэтому сроки нужно согласовывать с разработчиками и сразу выделять пул некритичных фич на вылет, если сроки поедут.
Люблю на досуге почитывать блог https://dolphin-emu.org/, эмулятор для Wii. На какие хаки только не приходится идти в эмуляторе, чтобы запустить Wii-игру на PC/Android.
Интерфейс называется iTransport - так не принято, скорее Transport или Transportable.
У геттеров предпочтительнее не использовать префикс get: name() вместо getName()
Пример, конечно, синтетический, но непонятно, зачем интерфейс с неэкспортируемыми методами, который не обладает логикой кроме как установки полей структуры.
Эмбеддинг используется, чтобы эмулировать наследование - это не совсем идиоматично. Лучше стараться избегать такого и использовать другие решения.
Функция создания структуры возвращает интерфейс, хотя идиоматичнее возвратить конкретный тип: в Go т.н. structural typing поэтому паттерны из Java/PHP не так работают: предпочтительнее возвращать конкретные типы, а определять и использовать интерфейсы уже на уровне консьюмера/клиента, тогда структура автоматически приведется к интерфейсу без строгой номинальной привязки. Т.е. некий код говорит, что он хочет принимать в качестве аргумента нечто, что ведет себя как утка, и приведение конкретного типа к интерфейсу происходит в этот момент. Неидиоматично объявлять, что некая структура изначально удовлетворяет какой-то интерфейс (что это её якобы неотъемлемое свойство).
Ну да, примеры об одном, текст о другом.
По сути же это просто функция, которая возвращает разные реализации интерфейса на основе входных параметров. Такого же полно в библиотеках на Go. Что этом плохого? В том, что это можно назвать "шаблоном"?
Про escape analysis много говорят при обсужлении темы тормозов Java, но по факту он работает только для небольшой горстки тривиальных случаев.
>Просто геттер должен возвращать закэшированную немутабельную копию
В конечном счёте много мороки на ровном месте: храним мутабельные, которые нельзя шарить, возвращаем иммутабельные (или аллокация, или оборачивать в интерфейс). Поэтому два пути: лепить трудноподдерживаемое спагетти или писать по-нормальному, но инвестировать в набор GC рантайма для файнтюнинга.
Не знал, что Хабр не умеет в отложенное схлапывание нескольких уведомлений в одно, это забавно. Сам я личной почтой вообще не пользуюсь, поэтому про какие-то уведомления даже не думал.
>Виндовые дефолты отовсюду торчат.
Есть такое. Более того, в рантайме есть PAL (по крайне мере, раньше было) - это, по сути, реализация подмножества Windows API средствами Unix, чтобы первоначально Windows-only код весь не переписывать (этакий простецкий winelib). В итоге и семантика виндовая, зато полная совместимость... В mono тоже был слой эмуляции Виндовой подсистемы (в основном I/O)
Но это, мне кажется, обычная практика в целом. Ведь у многих остальных языков (например Go) то же самое, только наоборот - повсюду семантика Unix, которая со скрипом заводится на Windows (приходится эмулировать). Но на это мало кто обращает внимание.
Del
Что такое "омоложение"? Выглядит как шило на мыло.
Мутабельные векторы тоже так себе идея. Если где-то случайно зашарить объект по ссылке не склонировав, то внезапно позиции рандомных объектов связаны и поди отладь что не так
>C4ET4uK 07.05.2021 в 08:04 Это просто говорит о том, что Minecraft не очень хорошо написан
Там такая история, что первоначально позиции были заинлайнены в объекты, и метод перемещения выглядет как-то вроде setPosition(1, 2, 3), что обновляло 3 поля примитивных типа без выделения памяти. Но такой подход очень неудобен, т.к. простейшие векторные вычисления превращаются в спагетти. В итоге было переписано в код вида setPosition(new Vector(1, 2, 3)) что моментально увеличило нагрузку на GC до 600 мб/с. Ну и pointer chasing если это массивы объектов (а их в Minecraft много)
> Java больше возможностей для fine-tune-инга чему способствует проработанная Memory Model и целый зоопарк Garbage Collector-ов на все случаи жизни
Все как бы немного наоборот - зоопарк сборщиков это не то что бы преимущество, а просто следствие отсутствия value objects, в итоге нагрузка на сборщик неизмеримо больше, чем в C# или Go, где by value обьекты присутствуют. Я помню в Minecraft было нормой выделять 600 мб/с мусора из-за использования векторов/матриц. В библиотеке JBullet автору приходилась написать инструментацию байткода для использования пула векторов/матриц. В C#/Go такие проблемы отсутствуют как класс.
.dll в .NET это же ни разу не .so
Это как просить переименовать .jar в .so
В остальном - "так исторически сложилось" :)
Доводилось сравнивать реализации VM различных языков (как хобби люблю ковыряться во внутрянках рантаймов) и по моему скромному мнению Hotspot это самая продвинутая VM (по крайней мере, из мейнстримовых) по числу оптимизаций и прочих плюшек (V8 наверное где-то рядом). Правда, большая часть оптимизаций это попытки исправить неудачные моменты языка...
То, что на Java часто овериндженирят - это уже другой вопрос.
>На Линуксе же он работает только пока не начнёшь подключать родные библиотеки С++
Что вы имеете в виду? Проброс исключений C++ через фреймы CLR? Конфликты между пользовательскими обработчиками сигналов и тех что устанавливает CLR? Разница в ABI у C++ библиотек? Отсутствие COM/Winapi? Отсутствие C++/CLI?
Оборачивал библиотеки на C и не увидел проблем, кроме несуразностей вроде присутствия Unicode-маршалинга как Utf16 в P/Invoke и отсутствия Utf8 (но не знаю как с этим в .net core)
Java тормозит на запуске, особенно холодном, что сильно заметно по GUI и консольным утилитам. Но горячий сервер-то не должен тормозить, особо нет причин для этого. JVM это state of the art.
Общий смысл:
>Durability is the ability of a physical product to remain functional, without requiring excessive maintenance or repair, when faced with the challenges of normal operation over its design lifetime
Переносный смысл:
>In database systems, durability is the ACID property which guarantees that transactions that have committed will survive permanently. For example, if a flight booking reports that a seat has successfully been booked, then the seat will remain booked even if the system crashes.
Выглядит так, что прочность/стойкость вполне подходят, хоть и со скрипом. Неизменность это скорее одно из проявлений durability. Вообще постоянство/неизменность могут ввести в заблуждение как термин, как будто данные не должны меняться. "Способность оставаться работоспособным при определённых форс-мажорах" это скорее вообще "надёжность [хранения]"?
Если взять определение, то очень похоже:
>Надёжность — свойство объекта сохранять во времени в установленных пределах значения всех параметров, характеризующих способность выполнять требуемые функции в заданных условиях применения, технического обслуживания, хранения и транспортирования
Правда, reliability это тоже надёжность