MajorDoMo

Всем привет. Пытаюсь сделать автоматическое создание объектов для определенного набора данных. При этом если обработчик запускается повторно, то все ранее созданные таким образом объекты мне необходимо сначала удалить. Таким образом я создал объект. А вот каким образом мне объект $object удалить?

Никогда не задумывался об удалении объектов. создавать, да, например для регистрации нового WiFi устройства. Интересно для какой цели вам понадобилось удаление объектов? Может как то по другому можно решить задачу?

Bagir писал(а):Никогда не задумывался об удалении объектов. создавать, да, например для регистрации нового WiFi устройства. Интересно для какой цели вам понадобилось удаление объектов? Может как то по другому можно решить задачу?

У меня есть класс Port. Он имеет несколько наследников PortIn, PortOut и так далее. Класс-устройство, которому принадлежат эти Port, имеет механизм автонастройки своих портов. Допустим, на физическом устройстве я изменил тип порта с In на Out. Соответственно, тип наследника должен измениться с одного на другого. Механизма полиморфизма я не нашел, поэтому вижу решение только в удалении уже имеющегося порта и добавлении его заново с другим типом наследника.

Если я правильно понял, то у меня несколько похожая ситуация с объектами сети Z-Wave. Самый яркий пример это пульт и выключатели. У них есть совершенно другие свойства. Проще говоря, эти железки не такие как все остальные. Я долго думал как сделать всё это безобразие. Были мысли создать подклассы как в случае с классом keySensors, но всё же в случае с Z-Wave я просто объявляю в классе все возможные свойства и методы разнообразного железа.
Вероятно есть какой то предел, где побеждает решение создать подклассы, и вариант с объявлением несуществующих свойств.
Как итог, да, действительно удаление объектов может понадобится, если поставить задачу именно так, и в дальнейшем оперировать объектами классов. Но я бы попробовал решить задачу как то иначе без динамических объектов.
А как вы в дальнейшем работайте с этими созданными объектами портов? Лично я, из того что у меня есть, могу только сравнить с портами МегаД. При замене управляющего модуля можно, например, объявить порт выход как порт вход. И да, у него уже будут совсем другие свойства.
Просто при работе с этим устройством я в коде сильно привязываюсь к имени объекта. И я даже не представляю как бы это всё выглядело, если бы я заранее не знал имя этого объекта. То есть если бы имя было динамическое.
Трудно дальше рассуждать без полного понимания картины.

Именно о портах MegaD и идет речь. У меня есть два базовых класса: Меги и ее порта. Соответственно, ее порт ветвится на различные типы портов. У базового порта есть свойства: номер, имя класса родительской Меги и тип порта (потребность в наличии последнего сомнительна). У класса Меги есть метод, который перечитывает конфигурацию объекта Меги (по свойству айпи + пароль) и пересоздает/обновляет конфигурацию портов. Алгоритм простой: по имени объекта Меги подбираются все порты и сверяются текущие настройки портов по номерам с теми, что пришли с Меги. Вот как раз в этот момент и появляется необходимость полиморфизма. Если тип порта изменился, то и наследный класс должен поменяться тоже. Если появился новый порт, то он допишется в объекты портов. Единственный способ, как я вижу, это - удаление, т.к. полиморфить уже созданные объекты возможности, как я понимаю, нет.

По поводу того, как же они работают дальше? Вот тут и возникает необходимость делить класс на подклассы, т.к. каждый тип порта ведет себя по-разному в разных ситуациях, например, при изменении своего статуса. Если порт IN должен выполнить все действия, которые при изменении статуса должны происходить (например, изменить статус объектам-портам OUT), то порт OUT должен вместо этого при изменении своего статуса направить команду на саму Мегу. Именно универсализация и заставила меня отойти от общего набора свойств и поделить классы портов на ветки. Программерская лень безгранична, и, описав поведение каждому классу, механизм будет работать сам по себе, один раз считав настройки с Меги. Новая Мега - это добавление объекта и нажатие на кнопку самонастрйки. При этом скрипт megad.php вообще состоит из 10 строчек кода. Если полетит, я выложу отдельными классами для заинтересованных.

Дело становится интереснее. Просто МегаД это можно сказать основные руки и уши моей системы. Лень, да верно, она безгранична. Готов день писать код, чтобы потом выполнить задачу за пять минут, которая требует пары часов рутинной работы
Просто я пошел по другому пути работы с Мегой. Изначально всё базируется на объектах класса keySensors и Relays. Класс MegaD просто "линкует" эти классы с железом. Я не сильно дружу с паяльником, поэтому использую готовые блоки 7I7O. Поэтому назначение порта для меня заранее предопределено.

Короче, нашел только код удаления. Отдельной функции нет.

Сергей, а может все же сделать готовую функцию? Люди просят )) или хотябы массовое удаление из редактора