Comments 18
Непостоянство spl_object_hash()
Тут скорее следует говорить об неуникальности хэша и в принципе поведение может неожидаемое, но документированное. Да и проблемой, по-моему, не является — если объект удалён (вернеё перенесен в мусор явно или концом области видимости), а его хэш продолжает использоваться в программе, то это явно ошибка в ней, похожая на ошибку битых указателей в C/C++. Или мне просто не приходит в голову зачем может понадобиться хэш уже недоступного объекта?
Тут скорее следует говорить об неуникальности хэша и в принципе поведение может неожидаемое, но документированное. Да и проблемой, по-моему, не является — если объект удалён (вернеё перенесен в мусор явно или концом области видимости), а его хэш продолжает использоваться в программе, то это явно ошибка в ней, похожая на ошибку битых указателей в C/C++. Или мне просто не приходит в голову зачем может понадобиться хэш уже недоступного объекта?
Дело в том, что клиентский код имеет возможность принудительно удалить объект без какой либо обратной связи с коллекцией, в которой хранится «непостоянный» хеш. Первый созданный после удаления объект будет иметь хеш удаленного объекта. При этом поведение коллекции является непредсказуемым.
Считать ли это проблемой? Пожалуй, нет, если выполнять грамотное удаление объекта и всех ссылок на него, но мир PHP далек от этих проблем. По крайней мере, я редко сталкивался с тем, что что-то где-то нужно подчищать.
Считать ли это проблемой? Пожалуй, нет, если выполнять грамотное удаление объекта и всех ссылок на него, но мир PHP далек от этих проблем. По крайней мере, я редко сталкивался с тем, что что-то где-то нужно подчищать.
А можно пример того, как «клиентский код удаляет объект без обратной связи с коллекцией»?
Да, пожалуйста:
Ох уж эти горячие клавиши…
Написав и запустив этот пример, я понял, что ошибался на счет работы unset(). Получается, что некоторые вещи, которые я написал были чушью.
Виноват, спасибо.
include '../bootstrap.php';
$map = new Rmk\Collection\StringHashTable('stdClass');
$object = new stdClass();
$map->set('key', $object);
var_dump(spl_object_hash($object));
var_dump($object);
var_dump($map);
// Где-то в клиентском коде.
$object = $map->get('key');
var_dump(spl_object_hash($object));
unset($object);
var_dump($object);
var_dump($map);
$object = $map->get('key');
var_dump($object);
var_dump(spl_object_hash($object));
Написав и запустив этот пример, я понял, что ошибался на счет работы unset(). Получается, что некоторые вещи, которые я написал были чушью.
Виноват, спасибо.
Угу, вопрос был как раз для того, чтобы было понятно почему проблемы нет.
Встречный вопрос:
получается, что нет способа удалить переменную и все ссылки на нее, кроме как удалять ссылки в их собственных областях видимости?
получается, что нет способа удалить переменную и все ссылки на нее, кроме как удалять ссылки в их собственных областях видимости?
Нету, и это, в общем, логично.
Выучите какой-нибудь серьезный язык. Со сборкой мусора. Чтобы демоны на нем не страшно писать было. С историей, серьезным кол-вом разработчиков. Ту же Java, например. Станет лучше как программист, перестанете писать бесполезные велосипеды на PHP, а когда дойдете до статей про организацию памяти, про многопоточность и т.д., поймете что надо заниматься еще и самообразованием, в.т.ч и теоретическим.
Спасибо за совет.
Я сомневаюсь, что у меня будет возможность заняться серьезным языком. Я не жалуюсь на работу с текущими технологиями. И ее достаточно много. И, кстати, я считаю ее серьезной.
Порядок в мире PHP наведут, и будет это не за горами. Сейчас крупные производители фреймворков (Zend, Symfony) готовят удобные качественные решения, которые позволят подняться на более высокий уровень всем использующим их разработчикам. В некоторых областях определяться лидеры, которые займут свою нишу и вряд ли кому-то ее уступят. Отрасль «зреет».
Я не пытаюсь, и никогда не буду, конкурировать с качественными, устоявшимися решениями. И таких как я будет много, когда важные и нужные вопросы безоговорочно решат.
Данный проект был попыткой сделать что-то хорошее и высокоуровневое, то, чего я не встречал и с удовольствием бы использовал. Но он провалился по причинам, описанным выше.
А заниматься самообразованием конечно же нужно, только вот поможет ли мне глубокое понимание Java в моей работе с PHP? Мне кажется, что есть куда более полезные знания для меня… Например, та же документация по unset().
Я сомневаюсь, что у меня будет возможность заняться серьезным языком. Я не жалуюсь на работу с текущими технологиями. И ее достаточно много. И, кстати, я считаю ее серьезной.
Порядок в мире PHP наведут, и будет это не за горами. Сейчас крупные производители фреймворков (Zend, Symfony) готовят удобные качественные решения, которые позволят подняться на более высокий уровень всем использующим их разработчикам. В некоторых областях определяться лидеры, которые займут свою нишу и вряд ли кому-то ее уступят. Отрасль «зреет».
Я не пытаюсь, и никогда не буду, конкурировать с качественными, устоявшимися решениями. И таких как я будет много, когда важные и нужные вопросы безоговорочно решат.
Данный проект был попыткой сделать что-то хорошее и высокоуровневое, то, чего я не встречал и с удовольствием бы использовал. Но он провалился по причинам, описанным выше.
А заниматься самообразованием конечно же нужно, только вот поможет ли мне глубокое понимание Java в моей работе с PHP? Мне кажется, что есть куда более полезные знания для меня… Например, та же документация по unset().
Простите, это смешно.
Я использую в работе Symfony. Версию 2 этого фреймворка видели? Лично у меня ощущение, что пишу на Java только с синтаксисом PHP и с худшим качеством проектирования. Даже не знаю, стоит ли спрашивать поможет ли вам в работе знание языка, где многое, что *сейчас* добавляется в мир PHP, было придумано и реализовано много лет назад.
Поможет ли вам знание языка с большей историей, лучше спроектированного, с большим кол-вом качественных библиотек, с большими возможностями? Вы все еще считаете, что нет?
Документация по unset — это лишь «как». Для того, чтобы понимать «почему», нужно изучать не PHP.
Вы пишите на «языке, который сделали одни дилетанты для других дилетантов»©. Продолжайте и оставайтесь дилетантом — выбор ваш.
Хочу заметить, что я не предлагаю отказаться от PHP. Есть области и случаи где его использование действительно будет оправдано. У этого языка есть свои достоинства как с точки зрения синтаксиса, так и с точки зрения того же найма персонала. Но надо четко понимать чем обусловлен выбор, какие плюсы и минусы есть, а не просто верить в волшебную фразу «facebook написан на PHP».
Я использую в работе Symfony. Версию 2 этого фреймворка видели? Лично у меня ощущение, что пишу на Java только с синтаксисом PHP и с худшим качеством проектирования. Даже не знаю, стоит ли спрашивать поможет ли вам в работе знание языка, где многое, что *сейчас* добавляется в мир PHP, было придумано и реализовано много лет назад.
Поможет ли вам знание языка с большей историей, лучше спроектированного, с большим кол-вом качественных библиотек, с большими возможностями? Вы все еще считаете, что нет?
Документация по unset — это лишь «как». Для того, чтобы понимать «почему», нужно изучать не PHP.
Вы пишите на «языке, который сделали одни дилетанты для других дилетантов»©. Продолжайте и оставайтесь дилетантом — выбор ваш.
Хочу заметить, что я не предлагаю отказаться от PHP. Есть области и случаи где его использование действительно будет оправдано. У этого языка есть свои достоинства как с точки зрения синтаксиса, так и с точки зрения того же найма персонала. Но надо четко понимать чем обусловлен выбор, какие плюсы и минусы есть, а не просто верить в волшебную фразу «facebook написан на PHP».
Я не хотел Вас рассмешить, возможно, вы не совсем так меня поняли.
Java бесспорно велика. И количеством светлых умов в сообществе, и качеством библиотек и даже синтаксисом. При том не только Java, С#, я, например, тоже очень уважаю. Я понимаю, что у любого умного человека можно многому научиться, и не так важно на каком или на скольких языках он умеет программировать. Дело в том, что ООП != Java; Design Patterns != Java; компонентный подход != Java. Пожалуй, все лучшее, что есть в мире программирования есть и в Java. Давайте разберемся почему так? Я вижу 2 основных критерия: много светлых голов + время. Ту историю, о которой вы говорите создали именно эти 2 фактора. Возможно, я ошибаюсь, поправьте меня.
Теперь вернемся к вопросу «нужно ли хорошему (а именно таким я хотел бы быть) PHP программисту изучать Java?».
Я считаю, что если есть стремление переходить на Java, то да. Во-первых, любые теоретические познания должны быть хорошо подкреплены практикой для достижения максимального эффекта. Эту практику нужно откуда-то брать и решение университетских задачек или написание калькуляторов (читайте велосипедов) будет слишком малым вкладом. На большее, человек, не имеющий основной работы в данной сфере, не будет способен по чисто экономическим показателям. Кушать то хочется… В итоге изучение конкретного языка, если нет цели переходить на него полностью, я, лично считаю малоэффективным. Я конечно не против иметь интересное хобби, но не более того.
Да, я смотрел Symfony 2 и даже подумывал начать на нем новый крупный проект, но все же решил дождаться ZF2, так как я ZF Way программист и ZF мне все таки ближе. Других адекватных причин выбора Symfony для себя я не нашел. Функциональная разница, на мой взгляд, между ними ничтожно мала.
Опять же, вернемся к нашему вопросу. Есть адекватные причины, по которым Вы работаете с PHP & Symfony. Я уверен, что их достаточно много. Что касается Вашего недовольства Symfony (по сравнению с Java), то сейчас нельзя писать Java Way код на PHP. Нужно все таки писать PHP Way код. Живой пример этому — мой проект, о котором написана эта статья.
Откровенно говоря, я не люблю такие фразы. Уж очень они похожи на:
На текущий момент я сделал выбор вкладывать не в конкретные технологии, а в фундаментальные инженерные знания, которые != даже самым развитым технологиям.
Java бесспорно велика. И количеством светлых умов в сообществе, и качеством библиотек и даже синтаксисом. При том не только Java, С#, я, например, тоже очень уважаю. Я понимаю, что у любого умного человека можно многому научиться, и не так важно на каком или на скольких языках он умеет программировать. Дело в том, что ООП != Java; Design Patterns != Java; компонентный подход != Java. Пожалуй, все лучшее, что есть в мире программирования есть и в Java. Давайте разберемся почему так? Я вижу 2 основных критерия: много светлых голов + время. Ту историю, о которой вы говорите создали именно эти 2 фактора. Возможно, я ошибаюсь, поправьте меня.
Теперь вернемся к вопросу «нужно ли хорошему (а именно таким я хотел бы быть) PHP программисту изучать Java?».
Я считаю, что если есть стремление переходить на Java, то да. Во-первых, любые теоретические познания должны быть хорошо подкреплены практикой для достижения максимального эффекта. Эту практику нужно откуда-то брать и решение университетских задачек или написание калькуляторов (читайте велосипедов) будет слишком малым вкладом. На большее, человек, не имеющий основной работы в данной сфере, не будет способен по чисто экономическим показателям. Кушать то хочется… В итоге изучение конкретного языка, если нет цели переходить на него полностью, я, лично считаю малоэффективным. Я конечно не против иметь интересное хобби, но не более того.
Я использую в работе Symfony. Версию 2 этого фреймворка видели? Лично у меня ощущение, что пишу на Java только с синтаксисом PHP и с худшим качеством проектирования. Даже не знаю, стоит ли спрашивать поможет ли вам в работе знание языка, где многое, что *сейчас* добавляется в мир PHP, было придумано и реализовано много лет назад.
Да, я смотрел Symfony 2 и даже подумывал начать на нем новый крупный проект, но все же решил дождаться ZF2, так как я ZF Way программист и ZF мне все таки ближе. Других адекватных причин выбора Symfony для себя я не нашел. Функциональная разница, на мой взгляд, между ними ничтожно мала.
Опять же, вернемся к нашему вопросу. Есть адекватные причины, по которым Вы работаете с PHP & Symfony. Я уверен, что их достаточно много. Что касается Вашего недовольства Symfony (по сравнению с Java), то сейчас нельзя писать Java Way код на PHP. Нужно все таки писать PHP Way код. Живой пример этому — мой проект, о котором написана эта статья.
Вы пишите на «языке, который сделали одни дилетанты для других дилетантов»©. Продолжайте и оставайтесь дилетантом — выбор ваш.
Откровенно говоря, я не люблю такие фразы. Уж очень они похожи на:
не просто верить в волшебную фразу «facebook написан на PHP».
На текущий момент я сделал выбор вкладывать не в конкретные технологии, а в фундаментальные инженерные знания, которые != даже самым развитым технологиям.
Вообще-то хеш не может и не должен быть «уникальным». Коллизии никто не отменял.
Если строковый ключ достаточно длинный, скажем 20к символов, то размер потребляемой оперативной памяти массивом вырастает ~ на 70% по сравнению со своим md5 хешированным аналогом. При этом время установки и доступа остается соизмеримым, но, конечно, в пользу «чистого» ключа.если ключ больше 64 символов — значить с логикой что-то не так
Пожалуй, самый главный вопрос, на который нужно дать ответ: «Готовы ли Вы заплатить такую цену по производительности за это решение?».НЕТ
В какой программе UML диаграграммы рисовали? это автоматизированный способ (имя код — программа собрала диаграмму, или руками?
Enterprise Architect
Все работы выполнялись вручную.
Что касается трансформаций «диаграмма — код» и «код — диаграмма», то они в моей версии остановились на уровне PHP4. Пишут, что все можно настроить, там редактируемые шаблоны, но не занимался этим.
Все работы выполнялись вручную.
Что касается трансформаций «диаграмма — код» и «код — диаграмма», то они в моей версии остановились на уровне PHP4. Пишут, что все можно настроить, там редактируемые шаблоны, но не занимался этим.
Sign up to leave a comment.
Коллекции объектов в PHP. Часть вторая