Изменение работы массивов в QSP
Мы изменяем логику работы массивов. Если раньше в одном элементе массива могли одновременно находиться и числовое, и строковое значение, то сейчас будет храниться всего лишь одно с признаком типа.
Это значит, что если в каких-либо играх используются переменные/массивы вида $A и A, то нужно следить, чтобы они не использовались одновременно.
Теперь о сути вопроса.
1. При присваивании значений переменным, присваивается то, тип которого указан в префиксе ($A или A):
A=‘45’ будет пытаться преобразовать строку ’45’ к числу 45. При успешном преобразовании записывается число. Если преобразовать не получается, то будет ошибка (также, как работало раньше).
$A=44 будет пытаться преобразовать число 44 к текстовому значению и в переменную запишется строка ’44’.
Указанный тип переменной - это то, какое значение в ней ожидается.
2. При получении значения переменной идет попытка получить тот тип, который указан в имени:
“$A” будет возвращать строку. Если записано число, то оно может преобразоваться к строке (см. далее).
“A” будет пытаться преобразовать хранимое значение к числу, чтобы вернуть число. Если записана строка, которая не может быть преобразована, то может вернуться ошибка (см. далее).
С получением значения переменной не все однозначно, т.к. описанный выше вариант с ошибкой может быть неочевиден для авторов.
Поэтому возможны 3 варианта:
1. Описанный выше вариант, где происходит преобразование типа к указанному типу переменной.
2. Почти то же самое, но если нельзя преобразовать строку (фактическое значение переменной) к числу, то возвращать 0.
3. Возвращать пустую строку при попытке получения строкового значения переменной, где фактически записано число. Аналогично возвращать 0 при попытке получения числового значения переменной, где фактически записана строка.
3й вариант вроде бы самый близкий к тому, что существует в QSP 5.7.0.
1й вариант самый гибкий.
2й вариант где-то между, но на мой взгляд странно, что иногда возвращаются корректные значения, а иногда внезапно 0.
Пытаюсь собрать аргументированные мнения.
Нельзя сделать так, чтоб при присвоении несоответствующего типа выдавалась ошибка? Сейчас разве не так?
Если автора хочет присвоить $a=‘text’, но путает и пишет a=‘text’, то он ожидает, что будет текст, а не 0 или ’’, Это только затруднит понимание ситуации. Аналогично, $a=45, автор будет производить с ним математические манипуляции. Но, сдается мне, что основная ошибка - пропущенный $, т.е. числовой переменной будут присваивать текст.
С присвоением проблем нет, проблема с получением значения.
Byte:
С присвоением проблем нет, проблема с получением значения.
Тогда поясните на спичках, для непрограммистов.
Как можно получить текст из числовой переменной? $a=b?
Это все обсуждение о прошлых играх, в которых уже использованы одноименные переменные? Я запутался…
Например, есть выражение “a+4”, которое нужно вычислить. Ожидается, что в “a” содержится число, но там может быть строка, потому что перед этим написали:
$a='dsfdsf'
Далее можно прочитать о тех 3 вариантах выше.
В первом случае будет попытка преобразования строки ‘dsfdsf’ в число, а если преобразовать нельзя (как в данном случае), то появится ошибка.
Во втором случае, если нельзя преобразовать, будет возвращен 0.
В третьем случае, так как реально хранимое значение - строка, а ожидается число, то вернется 0 (значение по умолчанию). Если здесь будет строка ’455’, то тоже вернется 0, в отличие от второго случая.
Да, в основном это касается существующих игр, где одновременно используются и строковые, и числовые значения в одном и том же массиве/переменной.
Хотя это применимо и к новому коду.
Я за то, что бы выводилась ошибка, а не попытки преобразований, ибо код работать не будет так, как задумывалось, а почему - будет сложно обнаружить. К примеру это а+4 будет лишь одной из 10 частей расчета, возможно, на это вообще не обратят внимания, если будет незначительная погрешность. Т.е. первый из ваших вариантов, но без попыток преобразования, лучше не стелить солому на грабли.
Смысла совсем убирать преобразования (генерируя вместо них ошибки) нет по той причине, что преобразования в куспе и так существуют повсюду, это часть языка. Более того, часть функций бы просто не работали без преобразований. Здесь же рассматривается конкретный случай с массивами, потому что он самый неочевидный, наверно.
Выбрали вариант 3. Логика простая: то, что записали, то должны и читать. Если читаем то, что не записывали, то возвращаем значение по умолчанию.