Код (Text): Failed loading z:/windows/openserver/modules/php/PHP-7.1/ext/php_xdebug.dll xdebug самый последний 2.4.1. Как подружить?
Это консольный вывод. А при запуске как модуля SAPI пишет вот что: Код (Text): Точка входа в процедуру php_log_err не найдена в библиотеке DLL php7ts.dll
В RC4 писали, что добавлена поддержка 7.1. Хотя, beta2 вышла совсем недавно, может еще не успели впилить поддержку. Эхх, придется ждать, пока икс-дебагеры подтянутся.
Собери из исходников. Пока 7.0 была в стадии разработки - релизы с сайта плохо работали, а ветка в репозитории - на ура шла.
@Sergey108 а нафига тебе это надо? Зачем тебе дебагать на нестабильной бете? Одно дело, когда ты хочешь посмотреть, как че запустится и как работает быстро - тут xDebug надо отключать. что там в 7.1 что тебе надо на ней работать когда она в бете2 но ты не собираешь из исходников сам при этом?
Скорее для фана, чем для работы. А xdebug нужен для дебага в CLI. Пускалось бы все в браузере можно было бы и обойтись var_dump'ом, но в консоли сложновато будет.. Пытаюсь собрать из исходников, но блин, phpize не запускается, говорит конфигов нет. До этого скомпилил PHP. Буду дальше тыркать, надеюсь не зря потрачу время.
Ну вот например, такая ситуация PHP: /** * Получить размер потока (stream) в байтах или null, если размер неизвестен. * Вернуть 0 в таком случае было бы некорректно. Поток может быть 0 длины. * Бросить исключение тоже не лучший вариант. * Возвращать параметром флаг? Боже упаси. * Не использовать тайп хинты? Вполне себе вариант, но с тайп хинтами лучше. */ public function getSize(): ?int; Ответил?
могу, но не хочу. почему бред? вот определил я интерфейс, где метод foo должен возвращать только int. я лучше сделаю этот контракт явным, и не дам клиенту сделать ошибку в реализации интерфейса (не дам ослабить постусловие). где тут бред? и про nullable. очень удобное нововведение. тайп хинтам его очень не хватало, как по мне. аргументов приводить не буду, их в RFC достаточно.
phpdoc решает же эту задачу. Нет? Какой нахрен смысл превращать простой скриптовый язык в подобие более низкоуровневого языка с ограничениями? Эти ограничения происходят от архитектуры. А в PHP это просто притянутые за уши "фильтры" поверх универсального контейнера, который по факту точно так же может хранить что угодно и дальше. Так не всё ли равно, где происходит схлопывание этой неопределённости? У тебя в методе, где ты всё контролируешь? Или у хз кого и где, и ты начинаешь тупо верить, что тебе реально прислали то, что хотели. Это не избавляет от ошибок с неверным типом. Это только маскирует их.
phpDoc делает видимость решения задачи, но никак не влияет на нее. Хорошо, если у человека IDEшка парсит доки, а если нет? (хотя это маловероятно) PHP хоть и скриптовый язык, все-же он достаточно мощный, на нем пишут крупные приложения, и, согласись, тайп хинты помогают в управлении сложностью. Помогают тем, что не позволяют допускать ошибок с неверными типами (в PHP 5 пришлось бы писать кучу if(!valid) throw new ... в методах, которые ожидают конкретный тип). Ах да, оговорюсь, что все сказанное в силе для "строгого режима (strict_types=1)". Без этого режима полезность тайп хинтов, действительно, под сомнением. Надо было раньше уточнить, что я имею в виду этот режим. И, я полагаю, что ты говорил про простой режим, где тайп хинты служат только для неявного каста типов? Или о строгом режиме у тебя то-же мнение?
Даже без стрикта есть польза PHP: /** * @return string */ function foo() { return 0; } var_export( foo() == "a" ); // true function bar() : string { return 0; } print_r( bar() == "a" ); // false, wow :)
ну то есть вместо того, чтобы использовать === ты просто пытаешься сделать неявный костыль. Да, он неявный. Ты по факту проверяешь тип, хотя ты не используешь === для проверки типа. А в других местах такого не будет, но ты будешь ждать уже, что все везде будут указывать хинт, и должно хватать == вместо ===. Теперь у == появляется ожидаемое неявное поведение, подменяющее ===. А это жопа на самом деле. Так что я за тайп хинты конечно же, но на текущий момент они нафиг не нужны никому никогда. Просто некоторые пытаются свои страхи переложить на язык, который будет за этим следить, не понимая, что по факту следить надо за собой и другими разрабами. В результате происходит подмена понятий в скриптовом языке, ты начинаешь ждать хорошего поведения от языка, а программы пишут люди. Как следствие, закладывается неявная мина, которая рванёт рано или поздно. Вот такую печаль я вижу.
@MiksIr Пользы было бы больше, если бы твой пример бросал исключение Все это очень сомнительно в плане полезности, так как происходит неявно. Да, с тайп хинтом есть гарантия, что метод вернет строку и только строку; с возвращаемыми типами проблем, вроде, не предвидится. Но с параметрами все немного интересней. А что, если == никогда не использовать, а === онли? Я вот не использую == никогда. С 2 параграфом согласен, есть и такие люди. Но можно страхи не перекладывать а избавиться от них и пользоваться новым инструментом, извлекая пользу.
ты не можешь. ПХП такой, какой есть. Если ты всё новое сделаешь, это будет не пхп. Тогда проще сразу на го перепрыгнуть. Какой смысл делать монстра. Тайпхинты требуют люди, которые пришли в пхп и не приняли его концепцию. Его преимущество в отсутствии типов. Если добавить, то многое портится, а не улучшается. Да, страхи уходят, но по факту, они вылезут потом ещё в большем виде, потому что тупо добавляют неявное поведение. А это капец, господа.
Смысла в этом потоке не найдено Какой же неявный, если я явно использую приведение типов. Я то все правильно напишу. А вот тот, кто потом этот код будет сопроводжать - не уверен. И если у него в интерфейсе будет string, то я могу работать со строкой А кто ты такой, что бы за всех говорить? На лицо тотальное непонимание процесса разработки. Уверен, что в объектном стиле ты пишешь только потому, что "так надо", не понимая, зачем оно вообще. А оно в общем о том же все, о том же. Мы работаем с языком с динамической слабой типизацией, и с этим стоит смириться что в == в некоторых случаях нужно приводить типы, что в === в некоторых случаях нужно приводить типы. Причем, поиметь проблемы можно в обоих случаях. Код (Text): php > $a = "2"; php > $b = "2"; php > $c = "7"; php > var_export($a === $b); true php > $a += 5; php > var_export($a === $c); false
@igordata Какая еще концепция? Получается, разработчики самого ZE и PHP взяли вдруг и не поняли концепцию своего языка? Да, изначально это был скриптовой язык, но времена 3 и 4 PHP ушли безвозвратно. Десктопные приложения и расширения для PHP писать на PHP конечно тот еще фетиш, но веб приложения, подчеркиваю, - приложения писать на PHP можно, и скриптами это назвать язык не поворачивается. И в то-же время его самый большой недостаток. Вот что-что, но массивы сделаны шикарно, в них динамическая типизация очень кстати, но в остальных случаях переменная должна быть определенного типа, иначе начинается вынос мозга, когда переменная в начале была строкой а под конец вдруг превратилась в объект. Щас хоть параметры могут быть типизированными, уже легче жить. Но я не отрицаю ситуаций, когда динамическая типизация будет предпочтительнее статической. Но таких ситуаций стало очень мало с появлением PHP7. Это твое мнение, доводов не вижу, давай уже аргументы. Какое такое неявное поведение добавляют тайп хинты в строгом режиме? От чего и стоит ожидать неявности, так это от динамических структур, когда однажды переменная из числа может превратиться в массив. Посмотри на вордпресс. Вся эта тяжесть глобалов и не следование конвенциям типизации тянутся с самого его начала. И во что он превратился? Правильно, в кусок говна. P.S. Это лишь мое личное мнение. В свою веру никого обратить не пытаюсь. P.S.S. Споры ни к чему не приводят, просто признайте, что я прав )) шутка, конечно
вот об этом я и говорю. Я не смиряюсь с этим. Для меня слабая типизация - достоинство скриптовых языков. Вот и всё. То, что ты считаешь, что двойное равно это привидение типов только потому, что ты задал это в методах - это и есть та проблема, о которой я говорю и которую ты хочешь понять. У тебя привидение типов при двойном равно. Это ж абсурд. По факту сейчас есть тройное равно, которое твой пример решает без муток. Получается, что твоя версия делает лишние движения, которые не нужны. такой умный шо пездец. Люди в пхп приходят и просят то, к чему привыкли. Те, кто занимаются развитием языка делают то, что потребно. А в реальности компании нанимают джавистов, т.к. пхпшников хороших фиг да маленько. А джависты просят привычное окружение. Конец. Пхп обрастает признаками компилируемых языков. Ну... Кто-то вот рад. Я - нет. Не понимаю, нахрена мешать два разных направления. ты даже тройное равно не используешь, нахрен тебе мои аргументы? Ты с предметом разговора не сталкивался. Я привёл аргументы почему это плохо. А ты не привёл аргументов почему это хорошо. Так что свои сначала приведи. если для тебя слабая типизация недостаток, то нахрена ты используешь такой дефектный инструмент? Есть же другие языки. Зачем блин жрать кактус? потому, что это и не массивы, кстати =) если у тебя в программе строка в объект превращается, значит ты хреновый программист. Тебе значит нужно, чтобы язык не давал тебе лажать. Отлично. Переменная не может сама по себе в объект превратиться, только если ты её где-то сам превратил или из некоего метода или функции получил. А если ты надумал что-то получать из метода или функции, то стоит удосужиться прочесть что именно эта функция возвращает и не присваивать одной переменной десять разных значений в разных местах программы. Это блин всё попахивает гоном на GOTO и напрашивается аналогия про вилку с пробкой, потому что вы видите ли вилкой себе в глаз тыкаете и вам больно. Не делайте проблем и не будет проблем. а мне легче жить, когда я могу передать в функцию и строку и число и массив. А если такого не будет, то нужно делать здравую перегрузку. Это всё потянет перестройку всего языка, и он из простого превращается в сложный. При этом он будет инвалид по сравнению с языками, где это было изначально предусмотрено и есть куча оптимизаций под типы. в примере Миксера есть неявное сравнение типов при двойном равно, которое НЕ ДОЛЖНО по спекам типы сравнивать. Для этого действия есть тройное равно. при чем тут блин глобалы? Ты ещё Ленина сюда приплети. Он тащит багаж. Это причина. А сейчас ВП очень даже клёвая цмска. Мнение основывается на аргументах. Где аргументы-то? Пока это просто фантазии в ногу с модой. При этом ты даже не знаешь про тройное равно, но при этом имеешь блин мнение о типизации =) Да ну.
Вот тут подробнее. Ты экстрасенс? Если так, то хреновый экстрасенс. Все, что я увидел, так это то, что ПХП динамический язык и строгая типизация не его "фишка", потому тайп хинты не нужны, потому что добавляют неявное поведение. Какое нахрен неявное поведение? Параметр ожидает число а ты передал строку? - получи исключение. Все очень явно. Главное использовать это правильно. Я приводил аргументы почему это хорошо, но ты не захотел их воспринимать. Если ты слышал об ООП и дизайне, то наверняка сталкивался с понятиями предусловий и постусловий. Так вот тайпхинты хорошо в этом помогают. Еще аргумент? Ну, теперь не нужно проводить проверки на корректность типа. Исключение будет выброшено автоматически. Чем не аргументы? у меня-то нет, но частенько приходилось работать с чужим кодом. Тут я с тобой соглашусь, пример притянут за уши, и конечно, все зависит от программиста. Так никто не призывает от этого отказываться. Я не говорю, что динамическую модель надо выпиливать, нет, она необходима, этож пэхэпэ в конце-концов. Я просто говорю, что там, где ожидается конкретный тип, можно застраховаться и указать его явно без дополнительных проверок аргумента. ахахах. С юмором у тебя в порядке ))) клевая цмска. хахаха. Стильно, модно, молодежно и никаких фантазий, все очень реально и все используется. Про тройное ровно знаю, читай внимательней. Вот только давай без этого, хочешь подисскутировать, будь добр не принижать собеседника. Эмоции оставь при себе. Короче. Консенсус таков. ПХП это мощный язык программирования с динамической типизацией, которая является мощным инструментом в умелых руках. О чем ты меня спрашивал и я ответил: строгая типизация привносит мощный инструмент по управлению сложностью и запрещает некоторые вольности. Имхо, для больших проектов, это упрощает поддержку и разработку программы, так как делает ее (программу) более явной. Больше явного поведения === меньше багов.
Тайпхинты к строгой типизации отношения не имеют и никак ее не меняют Даже статической типизацией пхп не начианает обладать, хотя и приближается. По-этому и зовутся они всего-лишь "хинтами".