Несоответствие типов: ожидалось real, а получено int

[S.Kuskov]

AX2009. Странное поведение коллекций Set и Array (для коллекции Map не воспроизводиться).
Почему в некоторых случаях не срабатывает неявное приведение типов?

    Set set = new Set(Types::Real);
    Array array = new Array(Types::Real);
    Map map = new Map(Types::Real, Types::Real);
    ;
    
//  set.add(0);         // Несоответствие типов: ожидалось real, а получено int.
//  array.value(1, 0);  // Несоответствие типов: ожидалось real, а получено int.
    map.insert(0, 0);   // ok

[pedrozzz]

Давно привык, там, где использую real и нет дробной части, ставлю после числа точку. Избавляет от подобных глюков.

set.add(0.);         // ok
array.value(1, 0.);  // ok
map.insert(0., 0.);  // ok

[S.Kuskov]

Цитата:

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

Давно привык, там, где использую real и нет дробной части, ставлю после числа точку. Избавляет от подобных глюков.

Это всё понятно. Можно использовать соответствующие литералы, а в случае переменных можно перед использованием перегнать значение из целочисленной переменной в вещественную. Только ради чего всё это делать? Я не вижу в этом никакого смысла. По-моему, необходимость делать это является следствием бага. Или всё-таки это фича? Тогда в чём её смысл?

[ShowPoint]

Это не бага, это следствие использования anytype в методах add и value. Компилятор не может сгенерить кастинг, поскольку нужный тип будет известен только при выполнении, и поэтому отдаёт параметр как есть. А классы Set и Array внутри strictly-typed, цитата из хелпа (метод add класса Set):

The value must be of the same type as the type assigned to the set when it was created.

[samolalex]

В третьей Аксапте наблюдается то же самое:

Цитата:

// set.add(0); // Несоответствие типов: ожидалось real, а получено int.
// array.value(1, 0); // Несоответствие типов: ожидалось real, а получено int.

Я думаю, что в коде метода Add() класса Set стоит проверка на тип добавляемого значения (enum Types), для примера:

static void TestTypesJob(Args _args)
{
    Types       type;
    ;

    type = typeof(0);
    info(enum2str(type));//Integer

    type = typeof(0.0);
    info(enum2str(type));//Real
}

Таким образом, я думаю, что это не баг.

[S.Kuskov]

А по какой причине тогда с коллекцией Map дела обстоят иначе?

[samolalex]

Цитата:

А по какой причине тогда с коллекцией Map дела обстоят иначе?

Возможно, по причине наличия в данном классе инверсии (изменения мест) ключа и значения.

[S.Kuskov]

Цитата:

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

Возможно, по причине наличия в данном классе инверсии (изменения мест) ключа и значения.

Не понял вас. Можете пояснить?

[samolalex]

Цитата:

Сообщение от S.Kuskov

Не понял вас. Можете пояснить?

Пример функции инвертирования (взят из книги Еременко, Шашкова)

Map invertMap(map _mapToInvert)
{
    mapIterator it;
    map result = new map(_mapToInvert.valueType(), _mapToInvert. keyType()) ;
    if(_mapToInvert.keyset().elements() != _mapToInvert.valueSet().elements())
    {
        return null;
    }
    
    it = new mapIterator(mapToInvert);
    while(it.more())
    {
        result.insert(it.value(), it.key());
        it.next();
    }
    return result;
}

Предположение о причине отсутствия проверки на типы в методах insert() класса Map сделал из того, что ключ и значение могут быть разных типов, и в силу этого в коде данного метода, скорее всего, решили опустить проверку, т.к. сочетаний типов "Ключ - Значение" может быть очень много.