Особенности наследования в Х++

Уважаемые мастера!
Необходима консультация!

Обнаружил одну интересную особенность, проявляющуюся при перекрытии методов в классах - потомках.

Если в родительском классе реализован метод с некоторым параметром не примитивного типа, то в классе потомке можно объявить метод с тем же именем, но с параметром совершенно другого (также не примитивного) типа.

Например, есть класс:
<div class='XPPtop'>X++</div><div class='XPP'>
[color=:blue]class[/color] Parent
{
 SomeClass value;

 [color=:blue]void[/color] setValue(SomeClass _value)
 {
    value = _value;
 }
}</div>

При этом я могу перекрыть метод setValue в потомке следующим образом:
<div class='XPPtop'>X++</div><div class='XPP'>
[color=:blue]class[/color] Child [color=:blue]extends[/color] Parent
{
 OtherClass otherValue;

 [color=:blue]void[/color] setValue(OtherClass _param)
 {
    otherValue = _param;
 }
}</div>

Кроме того, такой же трюк проходит и с типом возвращаемого значения.

Но! При попытке проделать то же самое с примитивными типами (скажем, подменить int на str) компилятор ругается "Перезагруженная функция имеет неправильно тип возвращаемого значения." или "Один из параметров для перезагруженная функции имеет неправильный тип.".

Как подозреваю, дело здесь в том, что все классы наследуются от Object, а все таблицы - от Common (с таблицами тоже все проходит "на ура"). Но, с другой стороны, приведение типов в данном случае вроде не имеет место, поскольку подменяемые описанным образом классы могут находиться в совершенно разных ветках иерархии. То есть, в моем примере класс OtherClass не является потомком SomeClass!

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

Вот я и думаю - можно ли закладываться на использование этого трюка, или же лучше сразу отказаться от "недокументированных" возможностей?

Заранее спасибо за ответы!

[Maxim Gorbunov]

Ну, стандартным механизмом это вряд ли является. Скорее это следствие некоторой ущербности интерпретатора X++. Проверка на приведение типов проводится только при компиляции. Runtime-проверка допустимости class cast не производится (интерпретатор с классами и таблицами обращается как с Object и Common - возможно, в целях повышения производительности).

Использовать или нет - ваше дело. Вряд ли интерпретатор существенно поменяется до версии 4.0.