— «если что то идет не так, то не важно кто виноват надо это пресекать, а единая система „
скажу отличие Error от Exception по другому ))
Exception — это те Error которые случаются время от времени, неизвестно когда будет следующая. При этом мы их можем спокойно обработать и пойтить работать(скрипт) дальше. Нам нет необходимости изменять существующий скрипт.
Но истинные Error — как бы не обрабатывали — не исчезнут, для пресекания подобной ошибки нужно лезть в код и править там ))
согласен — это как раз таки случай Исключительной ситуации, поскольку юзер может запросить что угодно, и ошибка («что не положено») произойдёт не по нашей вине, но мы как порядочные кодеры — ее не пропустим — отловим и обработаем.
но вот присваивания значения неизвестным свойствам, запрос неизвестных свойств — это явно ошибка логики, поэтому такой запрос — именно ошибка, а не Exception который упомянут чуть выше =)
Соглашения об именования — можно было бы и придерживаться. но опять таки
посмотрите на пример в посте с прямоугольником.
У него есть виртуальное свойство «area» которое я могу прочитать, но по понятным причинам — я его не могу установить — было несколько бредово))
И в данном случае соглашение об именовании никак бы не помогло разрешить ситуацию =)
По поводу отлавливания ошибок через Exception — вопрос спорный довольно.
По скольку исключения и ошибки все таки — разные по своей сути.
Деление на 0 в большинстве случае исключительная ситуация, которая произошла скорее по непонятным причинам — чем осознанно или в следствии опечатки — была вызвана конструкция $x/0;
А вот ошибки нам указывают на явные огрехи, которые были допущены при проектировании, разработки и т.д.
В то время как ошибку можно устранить всегда, исключительные ситуации в истинном своем лице происходят по различным независящим практически от нас причинам =)
на самом деле — никаких наворотов, а наоборот — проще некуда.
просто функции __get & __set различают в данном случае свойства типа
1.protected
2.protected у которых есть getter|setter
3.свойства которых у объекта вовсе нет
плюс к тому, debug_backtrace — позволяет показать — где в действительности произошла ошибка(т.е. в каком скрипте на какой строке произошла попытка вызова несуществующей переменной)
1. isset в данном случае использовать ни в коем случае нельзя, посколько если значения свойства будет NULL — isset = вернет false, в то время как само свойство всё таки существует =)
2. если не пользоваться сеттерами/геттерами и присваивать вот так вот — в атоматическом режиме. т.е. если есть свойство (protected|private) то его присваивать — теряется смысл самих методов __get & __set и сокрытия свойства в protected
мне кажется вы не совсем поняли.
автоподстановка никуда не пропадает, точно также можно сгененировать их в ZDE
НО данный класс — добавляет функциональности.
Если просто сгенерировать/прописать сеттеры/геттеры — вы не сможете воспользоваться элементарным присваиванием без функции.
Вы должны будете писать $obj->setName('Michael') вместо того, чтобы просто написать $obj->name='Michael';
Когда пишешь геттер/сеттер — ты в любом случае пишешь его вручную. где бы ты этого не писал.
А вот, если Вы имели ввиду — полностью автоматизация без прописывания методов setProp|getProp — вот это действительно сомнительный подход. При таком подходе — вобще теряется смысл в геттерах/сеттерах ))
Поправочка.
Вроде все правильно - и ограничения по времени есть, и по вычислительным мощностям.
Естественно решения должны укладываться в рамки, чтобы пройти в зачет.
Но выигрывает все же то решение, которое поступило на сервер раньше остальных.
Пусть даже остальные прошедшие в зачет работают в 2 раза быстрее.
"Программист - это машина", "Bytecode - все, остальное - ничто"
Типичное заблуждение вобще многих.
Ничто не мешает программисту быть творческой личностью.
Вобще программист - это всего лишь название вакансии. И то, что люди работают одну и туже работу - еще ничего не значит.
Хаха да и только. Целая куча правильных комментариев, можно в книги сразу пихать по книгам.
Но на самом деле вы говорите об иголке в стоге сена.
Посмотрите на досуге код топовых цмс и широко распространненых скриптов. А также код более чем серьезных ресов по рунету хотя бы (если конечно найдете, где его посмотреть ;) ). Из зарубежных можешь хотя бы на воблу (vbulletin) посмотреть.
Высказывания вроде - "код - как будто обезьяна писала","быдло да и только" и т.д. - цветочки по сравнению с тем, что встречается в них.
Но ведь работают, так что привыкайте и глупо злиться каждый раз. Я только посмеиваюсь - да и то по доброму уже.
В конце концов - прав тот, у кого это работает. Кто то разглагольствует и пишет по несколько лет "идеальные" системы, а кто то пишет за ночь и зарабатывает на хлеб, масло и латинских цып ;)
Ну и кто прав?
Ну а тот - кто самый умный, может быть научите тех кто похуже нормально программировать и думать, вместо того, чтобы быдлить первого встречного-поперечного.
Никогда не отказывал в просьбе разъяснить "юнцам" что да как, да примеры для осмысления подкинуть. И вам того советую - в один из дней ваш ученик может заработать миллион, а предложить вам заработать второй совместно =)
скажу отличие Error от Exception по другому ))
Exception — это те Error которые случаются время от времени, неизвестно когда будет следующая. При этом мы их можем спокойно обработать и пойтить работать(скрипт) дальше. Нам нет необходимости изменять существующий скрипт.
Но истинные Error — как бы не обрабатывали — не исчезнут, для пресекания подобной ошибки нужно лезть в код и править там ))
php ведь язык регистронезависимый ;)
это как раз таки избыточность, которая ни к чему =)
зачем придумывать, ограничивать себя по именованию — когда можно сделать как в посте и писать дальше, не заботясь об именовании =)
согласен — это как раз таки случай Исключительной ситуации, поскольку юзер может запросить что угодно, и ошибка («что не положено») произойдёт не по нашей вине, но мы как порядочные кодеры — ее не пропустим — отловим и обработаем.
но вот присваивания значения неизвестным свойствам, запрос неизвестных свойств — это явно ошибка логики, поэтому такой запрос — именно ошибка, а не Exception который упомянут чуть выше =)
посмотрите на пример в посте с прямоугольником.
У него есть виртуальное свойство «area» которое я могу прочитать, но по понятным причинам — я его не могу установить — было несколько бредово))
И в данном случае соглашение об именовании никак бы не помогло разрешить ситуацию =)
По скольку исключения и ошибки все таки — разные по своей сути.
Деление на 0 в большинстве случае исключительная ситуация, которая произошла скорее по непонятным причинам — чем осознанно или в следствии опечатки — была вызвана конструкция $x/0;
А вот ошибки нам указывают на явные огрехи, которые были допущены при проектировании, разработки и т.д.
В то время как ошибку можно устранить всегда, исключительные ситуации в истинном своем лице происходят по различным независящим практически от нас причинам =)
просто функции __get & __set различают в данном случае свойства типа
1.protected
2.protected у которых есть getter|setter
3.свойства которых у объекта вовсе нет
плюс к тому, debug_backtrace — позволяет показать — где в действительности произошла ошибка(т.е. в каком скрипте на какой строке произошла попытка вызова несуществующей переменной)
2. если не пользоваться сеттерами/геттерами и присваивать вот так вот — в атоматическом режиме. т.е. если есть свойство (protected|private) то его присваивать — теряется смысл самих методов __get & __set и сокрытия свойства в protected
ru.php.net/manual/ru/language.oop5.overloading.php
автоподстановка никуда не пропадает, точно также можно сгененировать их в ZDE
НО данный класс — добавляет функциональности.
Если просто сгенерировать/прописать сеттеры/геттеры — вы не сможете воспользоваться элементарным присваиванием без функции.
Вы должны будете писать $obj->setName('Michael') вместо того, чтобы просто написать $obj->name='Michael';
Иногда второй вариант более чем предпочтителен.
Как то не понятно.
Когда пишешь геттер/сеттер — ты в любом случае пишешь его вручную. где бы ты этого не писал.
А вот, если Вы имели ввиду — полностью автоматизация без прописывания методов setProp|getProp — вот это действительно сомнительный подход. При таком подходе — вобще теряется смысл в геттерах/сеттерах ))
Между привычным(обычным) ооп в других языках и этой(которую Вы указали) большая разница.
Опять таки, на мой взгляд — я привел наиболее близкую к реальности реализацию данной функциональности в пхп.
Возможно найду время чуть позже. и постараюсь расписать разницу — чем такой ооп(с массивами) отличается от привычного)
Напишите хотя бы личкой ;)
Вроде все правильно - и ограничения по времени есть, и по вычислительным мощностям.
Естественно решения должны укладываться в рамки, чтобы пройти в зачет.
Но выигрывает все же то решение, которое поступило на сервер раньше остальных.
Пусть даже остальные прошедшие в зачет работают в 2 раза быстрее.
скоро это когда?
скоро - понятие растяжимое.
сервис интересен, но знать когда - было бы лучше, потому что не хотелось бы
каждый день чего то ожидать, а получить это через год.
Типичное заблуждение вобще многих.
Ничто не мешает программисту быть творческой личностью.
Вобще программист - это всего лишь название вакансии. И то, что люди работают одну и туже работу - еще ничего не значит.
Но на самом деле вы говорите об иголке в стоге сена.
Посмотрите на досуге код топовых цмс и широко распространненых скриптов. А также код более чем серьезных ресов по рунету хотя бы (если конечно найдете, где его посмотреть ;) ). Из зарубежных можешь хотя бы на воблу (vbulletin) посмотреть.
Высказывания вроде - "код - как будто обезьяна писала","быдло да и только" и т.д. - цветочки по сравнению с тем, что встречается в них.
Но ведь работают, так что привыкайте и глупо злиться каждый раз. Я только посмеиваюсь - да и то по доброму уже.
В конце концов - прав тот, у кого это работает. Кто то разглагольствует и пишет по несколько лет "идеальные" системы, а кто то пишет за ночь и зарабатывает на хлеб, масло и латинских цып ;)
Ну и кто прав?
Ну а тот - кто самый умный, может быть научите тех кто похуже нормально программировать и думать, вместо того, чтобы быдлить первого встречного-поперечного.
Никогда не отказывал в просьбе разъяснить "юнцам" что да как, да примеры для осмысления подкинуть. И вам того советую - в один из дней ваш ученик может заработать миллион, а предложить вам заработать второй совместно =)