Рад, что смог вдохновить и суперкруто, что у вас получилось! Про управление сервоприводами уже и не помню, но это и не важно, там под капотом все равно должно быть примерно тоже самое. Кстати, машинку из Lego я тоже делал, хоть и не такую маневренную)
Если предполагать, что типами в дженериках могут быть только "встроенные типы"(и то не все, а только самые простые вроде int/string), то это довольно сильно урезает функционал дженериков и тогда становится возможным полное удаление атрибутов из кода.
Но, как я отписался выше, для этого уже есть инструменты.
Спасибо за комментарий! Дженерики в PHP - это не тоолько про typehint. Это еще, например, вариантность типов, наследование типов. Вот тут можно почитать дискуссию о стираемых типах в PHP. Вот тут можно почитать про наследование типов атрибутов. Но даже если мы отбросим все это и оставим typehint только на стороне статического анализатора, то простого стирания атрибутов все равно будет недостаточно для нормальной работы PHP.
Вот пример со стиранием атрибутов, когда все будет работать отлично:
<?php
class Generic<T> {
public function add(T $val) {
$this->val = $val;
}
}
Вот пример, когда мы не можем просто так взять и стереть атрибуты:
<?php
class Generic<T> {
public function add($val) {
if(!$val instanceof T) {
throw new \Exception();
}
var_dump(T::class);
return new T();
}
}
Пример вымешленный, но идея должно быть понятна. В этом случае для каждого такого уникального атрибуты нужно завести отдельный класс с уникальным названием. Что я и сделал, оставив все typehint для runtime.
P.S. Вижу, что вы пишите про компиляцию PHP. Хочу пояснить, что библиотека полностью написана на PHP и не требует перекомпиляции самого движка PHP.
Вариант с кодогенерацией плох тем, что PHP проверяет все в runtime. Даже если добавить какие-то проверки типов во время генерации, то это будет противоречить общему принципу работы PHP.
По поводу добавления дженериков в сам язык - после изучения RFC и его обсуждений пришел к выводу, что должно произойти что-то кардинальное, чтобы их добавили: + RFC не сформирован до конца. Даже синтаксис (за 7 лет); + у текущего синтаксиса есть проблемы с парсингом (https://github.com/PHPGenerics/php-generics-rfc/issues/35#issuecomment-571546650); + сообщестовом отвергается варианты, которые идут по простому пути или противоречат общему принципу работы PHP. Вариант моей библиотеки, реализованный в самом PHP, может сильно увеличить расход памяти, хотя он не очень сложен в реализации. (https://github.com/PHPGenerics/php-generics-rfc/issues/42).
Исходя из этого, я не вижу предпосылок для добавления дженериков в сам PHP (хотя в Hack они добавлены в каком-то виде).
Несколько лет назад использовал Tomita парсер для разработки сервиса поиска жилья, который работает до сих пор. Вытаскивал нужную информацию из объявлений в соцсетях.
Репозиторий с примерами конфигов Tomita парсера, докер образ и тесты для всего этого дела можно посмотреть тут https://github.com/mrsuh/rent-parser
А вот тут можно почитать про сравнение Tomita парсера с регулярными выражениями и нейронными сетями https://habr.com/ru/post/328282
мне было интересно сделать все самому, в том числе разобраться с микроконтроллером и запрограммировать его
ESP8266 стоит недорого по сравнению с готовым RC пультом/приемником (в том числе потому, что пульт — это уже имеющийся смартфон)
запрограммировать контроллер можно как угодно и добавлять к нему нужные компоненты по мере их необходимости, что делает такое вариант более гибким (на мой взгляд)
Трубка сделана из пластика на 3D принтере (модель для fusion360 тут)
Вал — кусок велосипедной спицы.
По бокам подшипники с пыльниками размером 2*6*3 мм (я брал такие)
Внутри трубки и по бокам на подшипниках немного литола.
Подшипники вклеивал в трубку суперклеем. Им же проклеивал сцепку подшипника и спицы.
Вроде, про него больше нечего рассказать.
Круто! Не видел таких.
Поставил две аккумулятора, потому что по документации ESP8266 NodeMCU минимальное напряжение для стабильной работы должно быть не меньше 5V(тем способом, что я подключал). Ставить dc-dc upper не хотелось, поэтому просто подключил два аккумулятора.
Можно было поставить стабилизатор на 3.3V и подключаться в обход стабилизатора платы, но об этом уже поздно подумал.
Спасибо!
Тоже думал над тем, чтобы увеличить длину лодки или увеличить угол наклона вала, чтобы нос не задирался вверх.
А вообще хороший материал на эту тему есть тут: John Finch. «Advanced R/C boat modeling».
Спасибо за совет.
Делил корпус на как можно меньшее количество частей, чтобы было меньше проблем при склеивании. Если печатать так, чтобы линии печати были вдоль, то скорее всего прийдется разделить на три части.
Печатал PLA. С ABS пока плохо получается.
Дейдвуд внутри пустой. Рядом с подшипниками внутри и снаружи промазано литолом. Пробовал набивать весь дейдвуд литолом, но не зашло.
По тестам дейдвуд не протекает.
Рад, что смог вдохновить и суперкруто, что у вас получилось!
Про управление сервоприводами уже и не помню, но это и не важно, там под капотом все равно должно быть примерно тоже самое. Кстати, машинку из Lego я тоже делал, хоть и не такую маневренную)
Если предполагать, что типами в дженериках могут быть только "встроенные типы"(и то не все, а только самые простые вроде int/string), то это довольно сильно урезает функционал дженериков и тогда становится возможным полное удаление атрибутов из кода.
Но, как я отписался выше, для этого уже есть инструменты.
В таком случае уже есть Psalm Template Annotations)
Они как раз не добавляют ничего нового в язык. Не нужна генерация кода. Весь код проверяется статическим анализатором (отдельным или в IDE)
Спасибо за комментарий!
Дженерики в PHP - это не тоолько про typehint. Это еще, например, вариантность типов, наследование типов.
Вот тут можно почитать дискуссию о стираемых типах в PHP.
Вот тут можно почитать про наследование типов атрибутов.
Но даже если мы отбросим все это и оставим typehint только на стороне статического анализатора, то простого стирания атрибутов все равно будет недостаточно для нормальной работы PHP.
Вот пример со стиранием атрибутов, когда все будет работать отлично:
Вот пример, когда мы не можем просто так взять и стереть атрибуты:
Пример вымешленный, но идея должно быть понятна.
В этом случае для каждого такого уникального атрибуты нужно завести отдельный класс с уникальным названием. Что я и сделал, оставив все typehint для runtime.
P.S. Вижу, что вы пишите про компиляцию PHP. Хочу пояснить, что библиотека полностью написана на PHP и не требует перекомпиляции самого движка PHP.
Вариант с кодогенерацией плох тем, что PHP проверяет все в runtime.
Даже если добавить какие-то проверки типов во время генерации, то это будет противоречить общему принципу работы PHP.
По поводу добавления дженериков в сам язык - после изучения RFC и его обсуждений пришел к выводу, что должно произойти что-то кардинальное, чтобы их добавили:
+ RFC не сформирован до конца. Даже синтаксис (за 7 лет);
+ у текущего синтаксиса есть проблемы с парсингом (https://github.com/PHPGenerics/php-generics-rfc/issues/35#issuecomment-571546650);
+ сообщестовом отвергается варианты, которые идут по простому пути или противоречат общему принципу работы PHP. Вариант моей библиотеки, реализованный в самом PHP, может сильно увеличить расход памяти, хотя он не очень сложен в реализации. (https://github.com/PHPGenerics/php-generics-rfc/issues/42).
Исходя из этого, я не вижу предпосылок для добавления дженериков в сам PHP (хотя в Hack они добавлены в каком-то виде).
Несколько лет назад использовал Tomita парсер для разработки сервиса поиска жилья, который работает до сих пор. Вытаскивал нужную информацию из объявлений в соцсетях.
Репозиторий с примерами конфигов Tomita парсера, докер образ и тесты для всего этого дела можно посмотреть тут https://github.com/mrsuh/rent-parser
А вот тут можно почитать про сравнение Tomita парсера с регулярными выражениями и нейронными сетями https://habr.com/ru/post/328282
Сейчас попробую посчитать затраты на последнюю версию:
Итого: ~ 2830р
Это без учета вспомогательных инструментов и оплаты за доставку.
Может где-то ошибся, но примерная стоимость такая.
Вал — кусок велосипедной спицы.
По бокам подшипники с пыльниками размером 2*6*3 мм (я брал такие)
Внутри трубки и по бокам на подшипниках немного литола.
Подшипники вклеивал в трубку суперклеем. Им же проклеивал сцепку подшипника и спицы.
Вроде, про него больше нечего рассказать.
Поставил две аккумулятора, потому что по документации ESP8266 NodeMCU минимальное напряжение для стабильной работы должно быть не меньше 5V(тем способом, что я подключал). Ставить dc-dc upper не хотелось, поэтому просто подключил два аккумулятора.
Можно было поставить стабилизатор на 3.3V и подключаться в обход стабилизатора платы, но об этом уже поздно подумал.
Тоже думал над тем, чтобы увеличить длину лодки или увеличить угол наклона вала, чтобы нос не задирался вверх.
А вообще хороший материал на эту тему есть тут: John Finch. «Advanced R/C boat modeling».
Делил корпус на как можно меньшее количество частей, чтобы было меньше проблем при склеивании. Если печатать так, чтобы линии печати были вдоль, то скорее всего прийдется разделить на три части.
Думал об этом, но решил пока оставить без дополнительного покрытия. Нужно будет почитать на эту тему.
Да, PLA хорош для печати. ABS пока часто слоится и детали вообще не получаются.
Дейдвуд внутри пустой. Рядом с подшипниками внутри и снаружи промазано литолом. Пробовал набивать весь дейдвуд литолом, но не зашло.
По тестам дейдвуд не протекает.