несовместимость классов в php 5.2.10

[tf]

несовместимость классов в php 5.2.10

обновился с 5.2.9 до 5.2.10 и тут это
что за новое счастье в простом коде

Declaration of view_list::htmlEndForm() should be compatible with that of view_edit::htmlEndForm()

error_reporting(E_ALL + E_STRICT);
class view_list extends view_edit {

	public function htmlEndForm($jsModul){
	}

}

class view_edit {

	public function htmlEndForm(){
	}

}

 

[zerkms]

...

 

[tf]

какая то жесткая модель получается
непонимаю

-~{}~ 28.06.09 10:11:

бред какой то получается. если я хочу четко обозначить параметры функции я пишу abstract function и ограничиваю
а тут из типа, мы подумали за тебя

 

[Lightning]

.

 

[pilot911]

это давно уже вылезает, задолго до .10 версии

 

[Krishna]

tf
С добрым утром. Завязывай таки с наркотиками.

 

[tf]

несмешно

 

[zerkms]

tf
эх..... давай на примере:

function foobar(view_edit $object)
{
    $object->htmlEndForm();
}

$a = new view_list;
$b = new view_edit;

foobar($a);
foobar($b);

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

 

[grigori]

Version: 5.2.0<br />
<b>Strict Standards</b>: Declaration of view_list::htmlEndForm() should be compatible with that of view_edit::htmlEndForm() in <b>W:\test.php</b> on line <b>6</b><br />

 

[tf]

логичный вопрос, а зачем мне нужен именно такой интерфейс?
этот пример никак не годится, у него узко заточеное применение - view_list и view_edit выводят что-то одно исходя из одинаковых данных

а у меня view_list должен изменить свою работу исходя из внешних данных и из одной функции не должен вызыватся
какой вмысле в наследовании если потомок не может изменить свой интерфейс?

-~{}~ 29.06.09 02:27:

grigori ничего в этом хорошего не вижу

 

[grigori]

я лишь о том, что это не связано с апгрейдом

 

[tf]

уже есть жетское ограничение интерфейсов, и если ты хочеш 100% уверенность что foobar выполнится, надо использовать это

class view_list extends view_edit {
	public function htmlEndForm(){
	}  
}

class view_edit extends view_abstract{
	public function htmlEndForm(){
	}                    
}

abstract class view_abstract {  
	abstract public function htmlEndForm();
}

какой смысл в runtime error когда у нас уже есть Fatal error при использовании жестких интерфейсов

-~{}~ 29.06.09 02:51:

grigori угу, сначало надо писать дополнительно к E_ALL чтобы это увидеть, потом ненадо, а в будующем в Fatall добавят и будут у нас одни abstract public function

 

[grigori]

в ближайшие лет 5 в fatal не добавят
в e_all будет, но это уже выбор каждого

 

[tf]

тригер создается, событие тоже вроде создается
вроде все пофиксил у себя. сижу медитирую

public function getJsSetData($update=false) {
	return parent::getJsSetData(false);
}

 

[pilot911]

я не меньше твоего возмущен этой "логикой"

реально мешает работать в стрикт моде

 

[tf]

ппц поставил 5.3 и думаю зачем
ктонибуть мне может объяснить почему у меня все методы должны быть абстрактными?

 

[cDLEON]

Архитектура.... Не на ПХП гони, на свою архитектуру.
После того, как я перешёл на 5.3 у меня только в одном месте так заругалось. Из 60-70 классов.

 

[tf]

да, ага, у нас все гуд, вот это правильное решение? ага, какже

public function getJsSetData($update=false) { 
    return parent::getJsSetData(false); 
}

модераторы зайройте тему, смысла нет

 

[Духовность™]

а в чем проблема была? в том, что htmlEndForm был в одном случае с аргументом, а в другом - нет? я просто 5.3. еще не ставил...

 

[Lightning]

tf
Это не похоже на правильное решение.