Сообщение о Fatal на мыло
protected $error_level;
protected $email;
public function __construct($email, $error_level=NULL){
//mail('fenyx@turmir.com', 'qwe', 'asdsad');
register_shutdown_function(array(&$this, 'error'));
$this->asd='ads';
$this->email=$email;
$this->error_level=(!isset($error_level))?E_ERROR:$error_level;
}
public function error(){
$last_error=error_get_last();
if(($last_error['type']&$this->error_level)==$last_error['type']){
mail($this->email, "Error Message", var_export($last_error, true), "From:Debug Fatal<fatal@class.php>");
}
}
}
//Использование
//$fatal=new fatal('email@domen.com', E_ERROR|E_WARNING);
//asdasdasd();
Не плоди сущностей без надобности (с) Уильям Оккам
В контексте только посылки сообщений о ошибке - конечно смысла в организации класса нет - использование одной функции будет гораздо эффективней, а организация класса не дает никаких преимуществ. Класс имеет смысл организовывать в случаях когда речь идет о едином механизме посылки всех сообщений.
Ну во первых я уж ни как не тринеровался
мда. ну не мешало бы.
тогда я присоединяюсь к мнению RussianSpy.
Я имею ввиду
Не плоди сущностей без надобности (с) Уильям Оккам
А где здесь ООП? Слова class и private?
Я имею ввиду
И в чем же конкретно нужно тренироватся? ))
И как сказывается класс на превышение памяти? ))
И напоследок радуют необоснованные суждения, хотя первышение было из-за большого xml файла, но это к делу не относится ))
И как сказывается класс на превышение памяти? ))
И напоследок радуют необоснованные суждения, хотя первышение было из-за большого xml файла, но это к делу не относится ))
Суждения вполне обоснованные - так как использование классов только ради "красивее и удобочитаемей" в контексте веб-приложения говорит о достаточно затратном подходе. Я это имел ввиду.
А где здесь ООП? Слова class и private?
если говорить о ООП - то конечно нигде. :) но я думаю что имелось ввиду использование классов как таковое, а не именно подход.
Наконец, правильно ли осуждать выбор парадигмы исходя из кажущейся нецелесообразности применения таковой на примере вырванного из контекста фрагмента кода?
ООП в принципе изначально задумывалось как способ облегчения работы над громадными проектами, где занято сразу много разработчиков. Тут нет ничего этого.
В данном конкретном случае причина использования класса только одна - "чтобы лучше читалось". И вот один кусок так написан, другой, третий, засовывается в какой-нибудь проект и на выходе получаем неповоротливого монстра, жрущего ресурсы как свинья печенье.
А учитывая, что подобный подход вообще встречается очень часто, то не стоит удивляться уродливым огромным монстрам вроде Pinnacle Studio 10 или Nero 8, которые "весят" по 2-3 Гб и несут функционал, как у аналогичных решений которые легче их в несколько сотен раз.
Эхх.. Где те времена, когда подобные товарищи уже в принципе не могли стать программистами по определению в виду ограниченности ресурсов?....
Расскажи мне, друг любезный, что это за вторая такая функция мистическая? Ты собираешься переменные инициализировать в отдельной функции? Зачем?
Наконец, правильно ли осуждать выбор парадигмы исходя из кажущейся нецелесообразности применения таковой на примере вырванного из контекста фрагмента кода?
Ну во первых с чего собственно? Во вторых как правильно заметил преверженец собственно такого языка :) - где здесь ООП? Оборачивание функционала в класс - может быть имеет смысл, но всегда надо отдавать себе отчет - это дополнительный расход памяти. Автор абсолютно без каких либо обоснований создал класс - и не привел никаких доводов чем это эффективней, кроме того, что это "красивее и удобночитаемей". Ну так впринципе телепатов среди нас нихт. Догадываться о том что он имел ввиду - оно надо? Кстати, я бы в следущий раз автору рекомендовал говорить о том что всетаки тренировался, потому как если писал это на рабочий проект - так за такое надо давать швабру в руки.
Если это просто такая извращенная реализация функции - то мне честно говоря загадка зачем. Если это была задумка как более чем наполовину глобальный класс (а каждый объект потенциально может быть не локальным) - то нах на каждый эррор_левел создавать свой объект (например)? Как говорится - тут же дело не в ООП - просто объясните что изменилось бы если класс не использовался - правильный ответ НИЧЕГО. Мифическая красота и удобство - это в данном контексте херь полная - видно в киеве тоже мля жарко.
По сути вобщемто мне похеру - ну нравится комуто множить классы - ну и пусть. Но не вижу ничего страшного в таком случае, сказать ему что он херней занимается - в любом случае мне кажется полезно посмотреть на свое творение чужими глазами - если в ответ на наши возражения найдется достойное обоснование - так это же хорошо, и нам полезно. Ну а если я и русский шпион правы - ну так нам респект, а автору есть над подумать. В чем проблема то? :)
Безусловно код можно потом оптимизировать (интересно занимается ли в наше время этим кто-нибудь?), но все таки мне кажется что все же лучше изначально стараться писать, используя более оптимальные и эффективные решения.
Возможно проглядел, но показалось, что изначально спор был о выборе парадигмы, как таковой, для решения конкретной задачи, а не о нерациональности использования того или иного подхода при помощи того или иного языка ввиду его (языка) хм... ректальной реализации.
Хотя да, ка краз таки с замечанием о реализации ПХП абсолютно согласен.
Ладно, холивары тут ни к чему.
Присоединюсь к Zorkus'u и полюбопытствую - причем здесь ООП? :)
Да, знаю, и более того, поддерживаю точку зрения о том, что в ПХП одна-две ф-ии, представленные в виде методов класса отстают в производительности, но, как уже упомянул ранее, изначально спор был не об этом. Может быть показалось...
А вот именно в ожидании подобных допущений я и писал:
Или самодостаточность класса дает возможность судить о его непринадлежности к чему-то "большому и светлому"? Ну так, если мне не изменяет память, как раз ООП и не поощряет излишнего "связывания", особенно элементарных классов.
Что ж, спору нет. Оставлю количество причин на совести топикстартера.
Искренне сожалею, что уже их не застал; без подколок, хотя и сам не понимаю, как могу ностальгировать по тому, чего не ощутил на своей шкуре.
Приведу тупенький утрированный примерчег. Предположим, что проект более-менее тесно завязан на ООП, так стоит ли включать в него просто "левые" самописные ф-ии? Не собьет ли это с толку читателя кода, который по привычке и умолчанию подразумевает, что "лысыми" ф-ми в таком проекте априори могут быть либо методы, вызываемые в контексте экземпляров содержащего класса, либо "нативные" ПХПшные функции, с которыми уже ничего не поделать? Или нет, спрошу иначе. Только ли меня это сбивает с толку? :) Ничего не могу поделать, это напрягает, даже больше, чем использование свойств в языках, где это позволено синтаксисом... ОК, прекращаю делиться "тараканами", уверен, у многих своим жить негде.
Словами не описать. Жарко было вчера, ну а сегодня это прямо ад на земле.
И вправду, видимо в жаре :D
А ничего кроме мусорных каментов по сути не получил, прекланяюсь перед гуру(просто влом спорить и безтолку) убежал тренирватся и молицца на ваши аватары
ЗЫ себена заметку... Купить метлу и лопату, записаться в отряд дворников
на самом деле может быть масса причин, почему использовать классы вместо функций - начиная от "мине так удобно" ... но при этом надо отдавать себе отчет - смысла особого использовать классы нет вне ООП-подхода.
Хотя мальчиг помоему абиделся и забег :) Он ждал фанфаров а не биздежа. А фанфары кончилися. :)
Вот такая судьба всег хениев. вечно им фанфаров не хватает.
Словами не описать. Жарко было вчера, ну а сегодня это прямо ад на земле.
мда. а мы с женой еще к тому же консервацией занимаемся. И ремонтом. у мну от перфоратора уже руки дрожат.
Зато жена попробовала новый рецепт - огурцы с абрикосами. Пахнуть абалденно - как на вкус - попробуем через недельку.
зачем сразу впадать в амбицию? надо просто отдавать себе отчет в том, что есть задачи и адекватные им средства. в общем случае - использования ООП в скриптовых языках надо избегать. потому что это медленно. если ваш класс является частью большого проекта, выдержаного в ООП стиле - это одно. если вы создаете свою библиотеку функций для собственных нужд, то городить класс для отправки почты, когда можно обойтись парой функций - это просто излишне.
нравится функциональный подход - пожалуйста - переписать код проблем не составит.
у меня есть программист, который ВСЕ реализует с использованием ООП стиля. его не волнует, что он решает задачи, где этот подход просто вреден и что его программы от этого работают гораздо медленее, чем могли бы. так вот он тоже путает процедурный подход и функциональное программирование :) функциональное программирование - это совсем другое.
Из всей темы вынес одну замечательную мысль - надо наконец собраться и съездить к вам в Киев)))
ЗЫ может кого-нибудь даже удастся выцепить пива попить ;)
Из всей темы вынес одну замечательную мысль - надо наконец собраться и съездить к вам в Киев)))
ЗЫ может кого-нибудь даже удастся выцепить пива попить ;)
это мы завсегда пожалуйста, добро пожаловать. правда, я последнее время все меньше стал уважать бутылочное пиво... приходится разоряться и таскаться по пивоварням :)
Хотя мальчиг помоему абиделся и забег :) Он ждал фанфаров а не биздежа. А фанфары кончилися. :)
Вот тут уважаемый пенсионер (форума) ты ошибся, такая мелоч не может обидеть. А фанфаров ждать - смешно, они всегда рано заканчиваются :).
меня всегда поражали люди ну например типа мицгола - ну или если брать не столь клинически выраженные случаи - вот эта тема например.
Странны люди надувающие губки - "всегда пишите код МАКСИМАЛЬНО оптимизированный, прогоняете каждый возможный цикл, экономите каждый байт памяти?" "ничего кроме мусорных каментов по сути не получил" - со слезками на глазах (хоть "такая мелочь не может обидеть"). Так ты кроме мусора по сути ничего и не написал. Что бы получить чтото толковое - так надо либо толковое вначале ответить - кроме "красиво смотрицца". Если критика наносит вред вашей самооценке берите пример с того же мицгола - он эту прогблему решил кардинально все что ему не нравица - ставил в блок-лист. Нах правдо тогда лезть вообще в интернет - мне лично не ясно. Помогло ли это самооценке мицгола - я тоже хз.
В принципе я собственно к чему - надо добавить кнопку для аффторов - "Не бейте меня - я кИсо" )))
ТОгда темы помеценные данной кнопкой не могут комментироваться иначе как только "Великолепно!", "Восхитетительно!", "В мемориз!" :):)
ну, чтож, это их право, не буду им мешать :)
to Fenyx
боюсь мне придется согласится с остальными
убирать эту функцию в класс было не самое верное решение
пример того как оно могло бы выглядеть вне класса
$e = error_get_last();
if (!$e || (($e['type'] & ($l ? $l : E_ERROR)) != $e['type'])) return;
mail($m, "Error Message", var_export($e, true), "From:Debug Fatal<error_send@domain.com>");
}
register_shutdown_function("error_send", "mail@domain.com", E_ERROR|E_WARNING);
объем кода изрядно уменьшился и вызов не сильно изменился
Странны люди надувающие губки - "всегда пишите код МАКСИМАЛЬНО оптимизированный, прогоняете каждый возможный цикл, экономите каждый байт памяти?" "ничего кроме мусорных каментов по сути не получил" - со слезками на глазах (хоть "такая мелочь не может обидеть"). Так ты кроме мусора по сути ничего и не написал. Что бы получить чтото толковое - так надо либо толковое вначале ответить - кроме "красиво смотрицца". Если критика наносит вред вашей самооценке берите пример с того же мицгола - он эту прогблему решил кардинально все что ему не нравица - ставил в блок-лист. Нах правдо тогда лезть вообще в интернет - мне лично не ясно. Помогло ли это самооценке мицгола - я тоже хз.
В принципе я собственно к чему - надо добавить кнопку для аффторов - "Не бейте меня - я кИсо" )))
ТОгда темы помеценные данной кнопкой не могут комментироваться иначе как только "Великолепно!", "Восхитетительно!", "В мемориз!" :):)
Эх кисо кисо, столько буков написать и ради чего? ))) Поднял свой авторитет в своих же глазах? Ай подловил маленького - маладца, возьми с полки пирожок, ну или корма там, только не ной больше ))) Тему можно закрывать т.к кроме флуда более тут ничего не предвидется