Следуя странным шаблонам для некоторых, разве я не могу этого сделать? Компилятор говорит, что Invalid constraint for formal generic parameter
class PARENT[G -> CHILD[like Current]]
feature -- Access
children: LIST[G]
end
class CHILD[H -> PARENT[like Current]]
feature -- Access
father: H
end
уметь делать что-то вроде
class WIDOW_PARENT
inherit
PARENT[BLACK_CHILD]
end
class BLACK_CHILD
inherit
CHILD[WIDOW_PARENT]
end
Если я не сделаю это с универсальностью, мне придется переопределить дочернюю коллекцию из
children: LIST[CHILD]
в children: LIST[BLACK_CHILD]
в класс WIDOW_PARENTfather: PARENT
в father: WIDOW_PARENT
в класс BLACK_CHILDвместо того, чтобы указывать его только в предложении наследования ... Надеюсь, это имеет смысл
Поскольку я решил это с помощью ответа Alexanders, я застрял в дальнейшем, выполняя проверку соответствия. Я пытаюсь установить HTTP-маршрутизатор в зависимости от сущностей, и если это дочерний объект, он должен иметь возможность выполнить http: // хост: порт / объект / дочерний_объект / идентификатор, чтобы получить все дочерние объекты из объекта. Для этого я хотел бы добавить к универсальному маршрутизатору проверку. На чем-то вроде ANY_PARENT_DB_ENTITY
типа
if ({G}).conforms_to ({CHILD_DB_ENTITY[ANY_PARENT_DB_ENTITY]}) then
friend.act_like_a_father
else
friend.act_like_a_mate
end
В современном Eiffel привязанные типы не могут использоваться в формальных универсальных ограничениях, поэтому возникает ошибка. По-прежнему возможно иметь взаимные ограничения, явно повторяя типы классов:
class PARENT [G -> CHILD [PARENT [G]]]
class CHILD [H -> PARENT [CHILD [H]]]
С этим изменением пример компилируется.
@Pipo Разве это не ({G}).conforms_to ({CHILD_DB_ENTITY [PARENT_DB_ENTITY [G]]})
?
К сожалению, G - это DB_ENTITY [G-> DB_ENTITY], иначе мне не нужно проверять соответствие ;-), но спасибо!
Отредактировал свой вопрос, чтобы добавить эту проблему
@Pipo Будет ли добавление неуниверсальных родительских классов ABSTRACT_PARENT
и ABSTRACT_CHILD
, ссылки наследования с PARENT
на ABSTRACT_PARENT
и изменение ограничений на G -> ABSTRACT_CHILD
?
да, но тогда мне пришлось бы изменить мою коллекцию и сущность на указанные типы. Это означает, что мне пришлось бы переопределить их в дочерние элементы, чтобы не использовать их ... потерю полиморфизма, см. github.com/phgachoud/sit_eiffel в случае ...
Для меня все еще лучшее решение, и единственное решение для всего моего шаблона - это переопределить в моем классе маршрутизатора метод set_handler
с помощью
deferred class
CHILD_DB_ENTITY[H -> PARENT_DB_ENTITY[CHILD_DB_ENTITY[H]]]
inherit
DB_ENTITY
feature
parent: H
ENTITY_HANDLER[G -> DB_ENTITY, H -> DB_SERVICE[G] create make end]
feature
item_prototype: detachable G
set_handler
do
setting_url_("http://host:port/" + {like item_prototype}.out)
...
end
end -- Class
CHILD_ENTITY_HANDLER[G -> CHILD_DB_ENTITY[PARENT_DB_ENTITY[G]], H -> DB_SERVICE[G]]
inherit
ENTITY_HANDLDER
redefine
set_handler
end
feature
set_handler
do
Precursor
setting_url_("http://host:port/" + ({like item_prototype}).out + "/" + ({like item_prototype.parent}).out + "/{id}")
end
end -- Class
PARENT_ENTITY_HANDLER[G -> PARENT_DB_ENTITY[CHILD_DB_ENTITY[G]], H -> DB_SERVICE[G]]
inherit
ENTITY_HANDLDER
redefine
set_handler
end
feature
set_handler
do
Precursor
setting_url_("http://host:port/" + ({like item_prototype}).out + "/" + ({like item_prototype.children.item}).out + "/{id}")
-- children being a LINKED_LIST[PARENT_DB_ENTITY]
end
end -- Class
Я надеялся, что есть способ получить это с помощью полиморфизма в том же классе, но также имеет смысл переопределить его таким образом ...
Многие спасибо, к сожалению, после того, как я застрял, когда хочу выразить это в структуре Compliance_to
if ({G}).conforms_to ({CHILD_DB_ENTITY[PARENT_DB_ENTITY[CANNOT_PUT_ANY_SO_GOES_TO_INFINITE]]}) then
, ограничении или просто неправильном шаблоне дизайна ...