Где?? что??? я вправду хочу взглянуть на возможные решения. Где это я глумился?


да хрен с ним, с указателем. Главное чтобы мысль реализовалась  в таблице хранить базовый обьект можно, и виртуальность кое-как работает..плохо что все "кое-как" 

пример инкапсуляции + полиморфизма. c наследованием в пакетах не получиться..



Это сообщение отредактировал(а) v2v - 12.5.2009, 10:00

как обьект хранить тоже не получится..  
  

v2v, аватар хороший, 2 раза по монитору стукнул уже рукой  

ясное дело что это всего лишь жалкая имитация нужного поведения...

Это сообщение отредактировал(а) v2v - 12.5.2009, 10:10

а причем тут ООП?   

ну не то что бы совсем нет - NOCOPY NOCOPY-OBJECT

Это сообщение отредактировал(а) DimW - 12.5.2009, 10:53

Для того чтобы реализовать полиморфные свойства объекта, необходимо иметь возможность для экземпляра потомка, используя интерфейс предка вызывать метод потомка, если он переопределен.
Реализуется это, в классике, созданием таблицы виртуальных (динамических) методов, которая заполняется в конструкторе.
Ввиду того, что в PL/SQL нет такого понятия, как "ссылка на процедуру", без динамики, реализовать это не удастся.

A eсли уж тыкать в то, что похоже на указатели, то от чего бы не тыкнуть сразу в REFsы? 


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