Comments 25
Всегда надо выводить ВСЕ ошибки. Это уже столько раз обсуждалось, что удивительно, что это надо повторять.
Несомненно. Именно вывод не только всех ошибок, но и стека вызовов с помощью xdebug, помог мне натолкнуться на эту забавную особенность. И Вам того же рекомендую.
А я отключаю E_STRICT для совместимости со старыми классами разработаными под php-4. Например, некоторые пакеты из PEAR.
Не называйте, пожалуйста, то что было в PHP4 классами, не было там OOP.
Считаю использование кода написанного еще для PHP4 совместно с кодом написанным на PHP5 огромной ошибкой.
Обратная совместимость нужна для того чтобы проект написанный полностью под PHP 4.4 работал, допустим, на PHP 5.2, и совсем не для перемешки кода разных эпох.
Считаю использование кода написанного еще для PHP4 совместно с кодом написанным на PHP5 огромной ошибкой.
Обратная совместимость нужна для того чтобы проект написанный полностью под PHP 4.4 работал, допустим, на PHP 5.2, и совсем не для перемешки кода разных эпох.
Да и общий смысл не в выводе ошибок.
А в том, что видимо нас ждет окончание периода разброда и шатания, и применение static, abstract, private, protected, public и прочих умных слов потихоньку становится обязательным там, где оно и должно быть обязательным.
А в том, что видимо нас ждет окончание периода разброда и шатания, и применение static, abstract, private, protected, public и прочих умных слов потихоньку становится обязательным там, где оно и должно быть обязательным.
Это ещё что, вот «Паблик Морозов» мне весь мозг съел своей нелогичностью. Хотя, скорее всего, это просто показатель ограниченности моего мышления…
Если кто сможет объяснить по-человечески «как-так вышло-то?» — был бы очень благодарен.
Если кто сможет объяснить по-человечески «как-так вышло-то?» — был бы очень благодарен.
это та фича без которой не работали бы многие паттерны. Вы имеете право пользоваться закрытыми свойствами в рамках класса, учитывая что вы находитесь в контексте класса (A::callAction($a);), то использование закрытых методов объекта для вас допустимо. кстати пример — синглтон, вы вызываете конструктор (а это функция объекта) в контексте класса, хотя конструктор закрыт.
Это ваш глюк, связанный с неверным пониманием языка и ООП в частности. Как вами же и было замечено — надо всего-лишь объявить функцию init() с ключевым словом static, раз уж вы вызываете её статично.
и всё равно бы «test» не вывелось, т.к. выводится переменная статически связанная с первым классом, а не со вторым.
а вобще за такие действия как у автора руки отрывать надо ;)
а вобще за такие действия как у автора руки отрывать надо ;)
Вы невнимательно читаете код. Или намеренно троллите.
Не переменная, а константа.
Не с первым, а со вторым, потому что я использую позднее связывание, static:: а не self::
И глюк именно в текущей версии интерпретатора, язык позволяет статически вызывать любые методы, даже не объявленные статически.
Не переменная, а константа.
Не с первым, а со вторым, потому что я использую позднее связывание, static:: а не self::
И глюк именно в текущей версии интерпретатора, язык позволяет статически вызывать любые методы, даже не объявленные статически.
«Глюк в текущей версии» — это когда serialize объекта с приватными полями вызывает SEG_FAULT или просто крэшит интерпретатор без всяких сообщений (5.3.1).
Исторически так сложилось, что PHP позволяет нестатические функции вызывать статично. Возьмите за правило включать E_ALL | E_STRICT в девелоперском окружении.
Исторически так сложилось, что PHP позволяет нестатические функции вызывать статично. Возьмите за правило включать E_ALL | E_STRICT в девелоперском окружении.
поздно было невнимательно прочитал, согласен
хотя лично мне необходимость использование LSB остаётся неясной.
хотя лично мне необходимость использование LSB остаётся неясной.
а вызов предупреждения нужен, чтобы не ломать тонны уже написанного кода.
Пример сферичен же несколько.
В данном конкретном примере или вообще?
вообще.
дело в том, что с ООП познакомился на примере Java, где LSB не возможно и необходимость использования данных принципов, говорит мне о том, что ошибка в дизайне.
Поэтому я бы был рад услышать примеры использования LSB, реализация которых другим способом была бы минимум нелогична.
дело в том, что с ООП познакомился на примере Java, где LSB не возможно и необходимость использования данных принципов, говорит мне о том, что ошибка в дизайне.
Поэтому я бы был рад услышать примеры использования LSB, реализация которых другим способом была бы минимум нелогична.
Да не вопрос. Пример из жизни.
Допустим некая система имеет модульную структуру. Есть много модулей, у которых много общего — каждый модуль, например, имеет свой конфиг, который нужно загрузить и инициализировать.
Вполне логично создать некий абстрактный класс «абстрактного модуля», в который и вынести такие вот общие методы. А классы конкретных модулей будут наследоваться от этого абстрактного.
С использованием LSB нам не нужны никакие трюки, чтобы заставить работать абстрактный метод, определенный в родительском классе в конкретном классе-потомке. В наследованном конкретном определяем, допустим, константу, однозначно идентифицирующую данный класс, а в абстрактном родительском — используем ее через static::
Может немного сумбурно рассказал, но это реальный пример из реальной жизни.
Допустим некая система имеет модульную структуру. Есть много модулей, у которых много общего — каждый модуль, например, имеет свой конфиг, который нужно загрузить и инициализировать.
Вполне логично создать некий абстрактный класс «абстрактного модуля», в который и вынести такие вот общие методы. А классы конкретных модулей будут наследоваться от этого абстрактного.
С использованием LSB нам не нужны никакие трюки, чтобы заставить работать абстрактный метод, определенный в родительском классе в конкретном классе-потомке. В наследованном конкретном определяем, допустим, константу, однозначно идентифицирующую данный класс, а в абстрактном родительском — используем ее через static::
Может немного сумбурно рассказал, но это реальный пример из реальной жизни.
хм… идею понял, и даже согласен с тем, что такая реализация логична.
Может быть я не прав, и длинного холивара (дальше этого поста устраивать не хочу), но мне кажется, что возможна реализация через лоадер, в который можно вынести всю общую логику.
Хотя согласен с тем, что если хочется использовать минимум экземпляров классов, то реализация с использованием LSB будет хороша.
Может быть я не прав, и длинного холивара (дальше этого поста устраивать не хочу), но мне кажется, что возможна реализация через лоадер, в который можно вынести всю общую логику.
Хотя согласен с тем, что если хочется использовать минимум экземпляров классов, то реализация с использованием LSB будет хороша.
Это нормальное поведение. PHP пытается применить не статические функции класса к контексту вызывающего объекта (это часто вообще для языков с динамической моделью). Если вы хотите вызывать функцию класса вне контекста его экземпляра, то НЕОБХОДИМО об этом сказать интерпретатору.
Выше developer правильно пишет.
И первый пример (Second::init()) должен работать только в случае метода init(), где-либо объявленного как static (здесь с E_NOTICE, кстати, интерпретатор не ругался?), ну а уж во втором, где и контекст внутри совсем другого класса, совсем весело.
И первый пример (Second::init()) должен работать только в случае метода init(), где-либо объявленного как static (здесь с E_NOTICE, кстати, интерпретатор не ругался?), ну а уж во втором, где и контекст внутри совсем другого класса, совсем весело.
>>И первый пример (Second::init()) должен работать только в случае метода init(), где-либо объявленного как static
Вы неправы. Статический вызов метода, не объявленного явно статическим — это не фатальная ошибка. Это скорее фича языка, нежели баг. Интерпретатор предупреждает, что это нехорошо, но не должен останавливать выполнение.
А уж тем более не должно быть зависимости от контекста выполнения.
Сейчас я все более уверен в том, что это баг конкретной версии интерпретатора. И либо он будет исправлен, либо будет ужесточена политика по отношению к static методам.
Вы неправы. Статический вызов метода, не объявленного явно статическим — это не фатальная ошибка. Это скорее фича языка, нежели баг. Интерпретатор предупреждает, что это нехорошо, но не должен останавливать выполнение.
А уж тем более не должно быть зависимости от контекста выполнения.
Сейчас я все более уверен в том, что это баг конкретной версии интерпретатора. И либо он будет исправлен, либо будет ужесточена политика по отношению к static методам.
Sign up to leave a comment.
Возможно, баг в PHP, возможно фича…