Конструктор обобщённого типа.

[Vapaamies]

Сообщение от Stilet

Я, как консерватор, не парился бы по этому поводу.

Правильный ответ на эту реплику: "Флудерам слова не давали". Хотел было сразу написать, но сдержался. Как показала практика, зря.

Сообщение от min@y™

Мне просто нужен (был) конструктор переменного типа, который можно бы было юзать без приведения типов. Оказалось, что не всё так просто.

Так а чем обощенная функция не устраивает-то?

Другой способ организации фабрики класса -- объявление виртуального конструктора (который и есть фабрика класса по сути) и описание массива классов:

type
  TXmlOptionClass = class of TXmlOption;
  TXmlOptionClasses = array[TOptionKind] of TXmlOptionClass;

var
  XmlOpitionClasses: TXmlOptionClasses = (TXmlOptionOrdinal, TXmlOptionFloat,
    TXmlOptionPoint, TXmlOptionRect, TXmlOptionString, TXmlOptionIntList);

function TAbstractOption.NewChildOption(const AKind: TOptionKind;
  const AName: string = ''): TXmlOption;
begin
  Result := XmlOptionClasses[AKind].Create(AName);
end;

Это работает во всех известных мне версиях Delphi.

[min@y™]

Result := XmlOptionClasses[AKind].Create(AName);

До такого я не додумался. Спасибо.
Жаль, что не в тему - я полез в обобщённые типы, чтобы научиться с ними работать. До этого меня и старые варианты (с приведением типов) устраивали. При использовании твоего кода тоже понадобится приведение типа результата к типу переменной, в которую функция отдаёт значение.

[Vapaamies]

Сообщение от min@y™

При использовании твоего кода тоже понадобится приведение типа результата к типу переменной, в которую функция отдаёт значение.

Если цель -- избавление именно от приведения типа, можно и совместить:

function TAbstractOption.NewChildOption<T>(const AKind: TOptionKind;
  const AName: string = ''): T;
begin
  Result := T(XmlOptionClasses[AKind].Create(AName));
end;

[min@y™]

похоже, то, что надо.
в понедельник приду на работу - попробую.
спасиба.

[Utkin]

Это метод-процедура, а мне нада функцию. И не спрашивать, почему

А метод-процедуру в функцию не обернуть конечно? И не спрашивать почему?

[min@y™]

Если цель -- избавление именно от приведения типа, можно и совместить:

function TAbstractOption.NewChildOption<T>(const AKind: TOptionKind;
  const AName: string = ''): T;
begin
  Result := T(XmlOptionClasses[AKind].Create(AName));
end;

Вполне справедливый еррор. Преобразования типов в run-time ещё, видать, не придумали. Естественно, на этапе компайлинга неизвестно, к чему привести указатель, т.к. тип приведения заранее неизвестен жэж.

[Vapaamies]

Сообщение от min@y™

Вполне справедливый еррор. Преобразования типов в run-time ещё, видать, не придумали. Естественно, на этапе компайлинга неизвестно, к чему привести указатель, т.к. тип приведения заранее неизвестен жэж.

Тогда это не обобщения, а черт знает что. Код обязан компилироваться, поскольку это небезопасное приведение -- просто указатель к указателю. Можешь еще через as попробовать ради прикола. Преобразование типов в run-time, которое "не придумали" -- это as.

А вообще, я все выходные думал над этим кодом и не понял смысла обобщаемой операции. В обобщенном программировании это известная проблема курицы и яйца. Поскольку в Delphi нет вывода типов, передача имени типа при раскрытии обобщения не избавляет от описания переменной с явным указанием типа, что сводит на нет все преимущества обобщения. А если тип переменной задается явно, зачем вообще городить обобщения, не проще ли описать простое создание экземпляра конкретного типа? По коду даже короче будет.

var
  T: TXmlOptionString;
begin
  T := TXmlOptionString.Create(...);
end;

Если же речь о пакетной обработке или помещении в контейнер, там конкретный тип значения не имеет: работа ведется с общим типом-предком, в котором объявлен виртуальный конструктор, поскольку для создания и уничтожения объектов больше ничего знать не надо.

И наконец, с точки зрения компиляции, если бы этот код комплировался, он бы раскрывал обобщение в каждой точке вызова, фактически вставляя тело функции в каждом месте вызова. Догадываюсь, что на размер сейчас никто не смотрит, но при полном отсутствии выигрыша от обобщения это просто раздувание кода. Предполагал, что Delphi не умеет группировать сходные раскрытия обобщений для экономии кода, а оказалось, что этот код он вообще не компилирует.

[Человек_Борща]

Тогда это не обобщения, а черт знает что. Код обязан компилироваться, поскольку это небезопасное приведение -- просто указатель к указателю.

Вот тут я вас обломаю. <T> - обобщение некого класса, через абстрактное T, T - просто некий существующий класс.

В вашем коде Result компилятор пытаться привести к некому классу T которого не существует в природе, потому что на тот момент <T> уже стало TMyClass

Правильно:

procedure name<T>(...):<T>
begin
  REsult := <T>(...Crete(self));
end;

Но такое IDE не проглотит.
Есть абстрактные классы, а вот абстрактных результатов у функции быть не может. Delphi типизирован, это вам не JavaScript где return это и int, string, bool, float, double и object одновременно.
Абстрактный класс просто упрощает некоторую реализацию класса операций над неким типом данных, на пример раньше приходилось самому писать TMyIntegerList, теперь это делает delphi за нас в виде TList<Integer>.

[min@y™]

Короче, я думаю забить на этот подход болт, так как действительно во многих частных случаях он не имеет симсыла. Заюзать я его хотел только с целью выкинуть приведение типов и неизменность кода конструктора при добавлении новых потомков TXmlOption.

Вобщем, дануегонах, других задач - мешок. Столько времени просрал, жалко.

[ResourceSpace]

Хочу поковыряться в сабже. Какая у вас версия Делфи (или кого там)? А то моя не поддерживает эту фичу.