Best-ЯП-вброс, или «а ваш ЯП так может?»

Ну, считай строки. Всяки фильтрации и экшоны допилишь сам, а я уже в пижаме.

Т.е. у тебя так много строк написано просто чтобы почитать какой сигнал пришел?)

Может действительно шрифт мелкий, поэтому еще раз уточню словами: на скрине полноценный демон десктопных уведомлений.

У тебя - просто читалка сигналов, куцая, без фильтрации.

В случае Пыха, твой аналог будет таким:

<?php
$dbus = new Dbus;
$dbus->Open_dbus("DBUS_BUS_SESSION");
while (1==1) {
 if (($dbus->RegisterMessage()) and ($dbus->IsMethodCall("org.freedesktop.Notifications","Notify")))) {
  $message = $dbus->ParseMessage();
  print_r($message);
 }
}

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

У тебя - просто читалка сигналов, куцая, без фильтрации.

Добавишь if (sig.Name = «чё там тебе надо») будут нотификации.

У тебя - просто читалка сигналов, куцая, без фильтрации.

У меня полноценный d-bus клиент.

на скрине полноценный демон десктопных уведомлений.

Нет.

while (1==1)

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

что за ублюдочный язык этот ваш пхп… лучше уж откопайте стюардессу.

fun f(x: Any) {
    when (x) {
        is String -> print("x is a String")
        is Int -> print("x is an Int")
        else -> print("Unknown type")
    }
}

А это что за бейсик?

это что-то котлинообразное, +- так же можно на православной яве.

на скрине полноценный демон десктопных уведомлений.

Полноценным он станет, когда будет содержать полную реализацию спеки:

https://specifications.freedesktop.org/notification-spec/latest/index.html

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

https://openjdk.org/jeps/406 — вливайся.

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

вот эта часть.

Добавишь if (sig.Name = «чё там тебе надо») будут нотификации.

Не будут.

У меня полноценный d-bus клиент.

Не полноценный. Чтобы он был полноценным - ему сначала нужно создать этот /org/freedesktop/Notifications, потом создать в нем интерфейсы, добавить методы\сигналы\свойства, сделать для всего этого интроспекцию, и уже потом мониторить. И не просто мониторить, а отвечать как нужно, ответами той структуры которая нужна.

интересно как это покрыть тестами.

например для «123» ))

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

Чо?)

интересно как это покрыть тестами.

Не совсем понял.

Не совсем понял.

у тебя как будто есть строка и как будто есть число.

ну и вот мне интересно, твоя реализация 123 и «123» различает или нет.

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

Хорошее замечание. Через пару часов напишу полноценную реализацию с интеграцией куда нужно =)

Можно пойти еще дальше:

while (1===1)

чтобы еще и тип значений проверялся на равенство.

is_numeric(«1») == true

лучше просто реализуй хелоуворлд с твоего скрина, но без батареек.

Не полноценный.

Ага, ну так не демон, а «чорт» какой-то

Чтобы он был полноценным

Автору надо почитать определение демона

сделать для всего этого интроспекцию, и уже потом мониторить. И не просто мониторить, а отвечать как нужно, ответами той структуры которая нужна.

Дерзай, весь мир у твоих ног.

Так и должно быть чеееел, ты же ввел число, то что оно в стрингах, вывод на экран и должен сказать что это число .

Мне всё же интересно, а зачем работать с переменной одновременно как с числом и как со строкой? В чём сакральная польза? Разве строка и число… эмм… не слишком разные вещи?

Я могу представить ситуацию, где динамическая типизация была бы интересна. Например, функция ожидает структуру с двумя полями, а мы туда передаём совершенно другую структуру, в которой 10 полей, но два из них идентичны тем, которые функция ожидает. И ЯП позволяет это сделать. Это весело и выразительно.

А вот желание иметь строку или число в одной единице — этого не понимаю.

Мне всё же интересно, а зачем работать с переменной одновременно как с числом и как со строкой? В чём сакральная польза? Разве строка и число… эмм… не слишком разные вещи?

Затем что дебилы проектировавшие d-bus, слишком много на себя взяли, и решили что их писалка-читалка должна уметь всё и сразу. Поэтому чтобы с этим работать (а на это завязано уже очень многое), приходится принимать эти правила.

Вместо того чтобы сделать всё строкой (как в случае файлов например), а процессинг строк оставить на откуп конкретным программам и программистам, эти дебилы ввели туда кучу типов - что привело к переусложнению кода, как своего, так и прикладного. Туда же и дебилы потакающие этому, в данном случае Freedesktop. Вот в своей спеке на сраный Notify сделали например replaces_id uint32 - это чтобы что?

Ладно, в случае например с БД - это нужно, потому что сама БД имеет инструментарий для работы с числами - сравнение там, ин\декременты, арифметику и тд. Здесь же это не используется никак.

Рядом с uint32 replaces_id расположился int32 expire_timeout - это нахера-то? Ребзя из Freedesktop предполагают, что у меня может скопиться ~4.2 миллиарда уведомлений? Или что таймаут может сработать через -30 секунд?

Было бы это все string - было бы на порядок проще.

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

https://ibb.co/JjbHHH3F

Убедился, что за 97 строк можно написать полноценный независимый демон десктопных уведомлений, который к тому же подхватывает цвета системной темы? ;)

А вот желание иметь строку или число в одной единице — этого не понимаю.

не «строку» и «число», а тип или тип.

interface Status {}

class Ok : Status
class Postponed : Status
class Declined : Status

fun f(s: Status) {
    when (s) {
        is Ok -> {...}
        is Postponed -> {...}
        is Declined -> {...}
    }
}

следи за руками: лишний статус не пройдет, компилятор скажет «говно шлешь в функцию». если добавится новый статус тоже сломается, компилятор скажет «ты забыл добавить обработку».

каеф.

Было бы это все string - было бы на порядок проще.

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

Эээ...мне кажется в Топике - кандидат на самый длинный и непонятный код :-)

даже на tcl точно короче. 'package require dbus;'(https://chiselapp.com/user/schelte/repository/dbus/wiki?name=Manual page) и ещё 3-4 строки.

знатоки python наверняка могут выкатить 2-х строчник

а зачем работать с переменной одновременно как с числом и как со строкой? В чём сакральная польза? Разве строка и число… эмм… не слишком разные вещи?

Представь, что тебе приходит навороченный json у которого где-то в глубине вместо 123 лежит «123». Ну так послали почему-то . Не все можно контролировать.

Представь, что тебе приходит навороченный json у которого где-то в глубине вместо 123 лежит «123». Ну так послали почему-то . Не все можно контролировать.

JSON это в принципе текст. Хоть 123.45 туда засунь, хоть 123e23, хоть «сто двадцать три» - это текст, просто какие-то байты. Пройдя через парсер, текст превращается в структуру, поля которой уже не просто байты, а байты типизированные. Это у нормальных людей так. Видимо у пхпшников принято парсить json в мапу, а потом каждую ноду мапы отдельно валидировать специально для этого написанной функцией и вручную кастовать типы. Я ответственно заявляю, что это говнокодинг во всей своей красе и могуществе.

Пройдя через парсер, текст превращается в структуру, поля которой уже не просто байты, а байты типизированные

как ты ловко «парсером» обозвал целую подсистему под названием Serializer. Парсинг байтиков там лишь этап. И в промышленном пыхе это принято делать примерно так https://symfony.com/doc/current/serializer.html#the-serialization-process-normalizers-and-encoders

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

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

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

Тогда прошу простить, зря быканул) Но если код сознательно не типизирован то это беда гореписателя, а не язычка.

JSON это в принципе текст. Хоть 123.45

Не совсем. 123 парсится в число, а «123» парсится в строку. У слишком типизированных язычков может случиться облом.

Не совсем. 123 парсится в число, а «123» парсится в строку.

чтобы что? А знаю! Чтобы потом в коде захерачить вот такое

<?php
function get($what) {
 if ($what=="test") {
  echo "String: $what\n";
 }
 if ($what==123) {
  $what=$what+1;
  echo "Int: $what\n";
 }
}

тебе не кажется это запущеным случаем идиотии? Ну окей, тебе прилетел кривой json. Ну окей, ты по какой-то причине не стал слать его нафиг, и решил принять и обработать. И? Вот тут у меня теряется нить логики. Вместо того, чтобы сконвертировать «123» в 123 на этапе десериализации, ты решил втащить ошибку клиента в структуру. Ну а дальше то что? Ты для, цитирую «приходит навороченный json» навороченного json-а собрался для каждой ноды написать функцию, которая в ифах проверяет тип значения и (хер его знает, что там дальше можно сделать, кроме как кастонуть к нужному значению)… ну это же бред.

Я не говорю, что ты глупый, или язык плохой. Пример, который ты дал плохой.

Представь, что тебе приходит навороченный json у которого где-то в глубине вместо 123 лежит «123». Ну так послали почему-то

Если тебе нужно обрабатывать данные, у которых не строгий формат, то в этом случае ты этот json на этапе валидации/каста преобразуешь в каноническое представление (в котором уже не бывает такого, что "где-то в глубине вместо 123 лежит «123») и это представление уже передаёшь дальше. Таким образом в функциях, реализующих непосредственную бизнес-логику, приседания вида «ой, а это у нас число или строка на входе» делать уже не приходится.

Что там? Такой страшный ужас, который стыдно в читабельном виде запостить?

Пых-пых всё ещё живой? Я думал с изобретением реакта это всё отправилось на помойку.

Он сейчас жив примерно так же как ныне мёртвый Delphi в 2010ых. Среди программистов предпенсионного возраста, которые из-за синдрома утёнка боятся или не могут изучить что-то современное и до сих пор ковыряют ложкой фрактал плохого дизайна.

А причём здесь React и PHP? Одно для клиента, другое - для сервера.

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

Вообще нет, они существуют для более эффективного управления памятью (меньше расход, быстрее доступ). Никаких существенных гарантий корректности они не дают.

println есть

Видимо при том, что с появлением SPA генерация html на сервере стала не нужна

А Json’ы отдавать (или в чём там взаимодействие с сервером ведётся нынче) тоже React будет?

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

Пых же это не только язык для бекенда, но и шаблонизатор. С переходом на современную архитектуру фронтенда, его услуги генератора html страничек стали бесполезными. А делать rest api можно на любом другом языке.

Что там? Такой страшный ужас, который стыдно в читабельном виде запостить?

https://minidevices.top/notifyd.txt

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

Конкурентных преимуществ у него поболее чем врожденных пороков его, и врожденных пороков других ЯП вместе взятых. Хотя смотря конечно для чего.

Во-первых, огромное комьюнити. Любое что только может придти в голову - уже кто-то делал. Все документировано, испробовано, проверено. Советов, подсказок - полный интернет;

Во-вторых поддержка встроенных операторов. Для машинного кода пофигу, человеку приятно - экономит время;

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

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

В-пятых, достаточно большое количество модулей для повседневной жизни. Рядом с работой с картинками (рисованием) расположился модуль для форматирования HTML, чуть дальше модуль работы с последовательным портом, а рядом с ним модуль работы со временем;

В-шестых, что тоже весьма котирую - легкость биндинга С-функций. То есть по сути ПЫХ может быть банальной очеловеченной оберткой для любого линуксового фреймворка, как существующего, так и будущего;

В-седьмых, при этом он имеет читабельный (относительно) С-подобный синтаксис, что уж точно лучше Python и Ruby;

В-восьмых, нормальное различие в коде переменных и функций;

И это я еще в дебри не лез =)

Кто-то там посоветовал «считать строки».

https://ibb.co/ZRY9gnLL

На скриншоте - полностью готовая подсистема десктопных уведомлений, работающая без привязки к «демонам уведомлений», а сама являющаяся демоном, который прописывается (не подсасывается к готовым демонам, а именно прописывается) в d-bus и выводит freedesktop notifications (даже от chromium умудряется).

Ну и соответственно, настройки этой штуки конфигурируются в панели управления.

Надо еще док приучить не выводить tooltip-окна, лол.

В общем, полноценный готовый работающий демон уведомлений - 160 строк, конфигуратор - 174 строки (можно сократить поудаляв лишние неиспользуемые css-стили).

Суммарно было потрачено 8 часов на демон, и 4 часа на конфигуратор. Самым сложным в демоне оказался алгоритм поднятия окон уведомлений вверх, по закрытию одного из них или нескольких.

Так-то.