Enfernuz (Автор тем)

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1
getItem, ошибка в реализации или документации
 
В документации написано, что getItem возвращает таблицу.

Однако, вызов getItem("client_codes", 0) возвращает строку с номером счёта (индекс может быть и ненулевой -- ситуация не меняется). То есть, ошибка либо в документации, либо в реализации функции.
Публикация списка изменений в новых версиях QLua.
 
Я, быть может, плохо искал, но в документации нигде не вижу списка изменений, внесённых в каждой следующей версии.Беглый взгляд по файлу "Интерпретатор языка Lua.pdf" в поисках новых функций или дополнения информации к существующим -- не слишком надёжный способ.


Например, в версии 7.16 (по сравнению с 7.14) добавили функцию "sysdate" (технически, она там была и до этого, но опустим этот момент) и выделили под неё отдельный пункт. В короткий срок я об этом узнать не могу -- только чтение мануала.
Задокументировать nilable / nonnilable поля в используемых структурах
 
Хотелось бы, чтобы в документации помимо перечисления полей для возвращаемых библиотекой объектов (из обычных функций API и из коллбэков On*) было также указано, может ли значение отсутствовать или нет.
Сейчас приходится делать практически наугад, что заметно осложняет создание схемы объектов, например, в тех же Protocol Buffers: например, в том же trans_reply от OnTransReply не указано, может ли отсутствовать order_num. Я так понимаю, что может отсутствовать, в случае если это невалидная тразакция. С сериализацией null в бинарных протоколах, скажем так, не очень, поэтому мне приходится делать это поле не примитивом, а строкой, и на стороне десериализации трактовать пустую строку как null. И таких полей великое множество. Если бы в документации было указано, что nillable, а что -- нет, то это существенно облегчило бы задачу и бонусом добавило бы производительности в конечное решение.
Возврат nil из некоторых функций, не отличить штатную отработку от ошибки
 
Многие функции библиотеки в результате своей работы возвращают nil. Но есть такие, которые возвращают nil и в случае "нормального" (в логическом смысле) режима работы.
Например, функция SearchItems. Если передать ей коллбэк "function(t) return false end", то ожидая получить пустую таблицу на выходе (= пустой массив в Lua, "индексов, удовлетворяющих условию, не найдено"), на самом деле мы получаем nil. Тот же самый nil мы получим, если произошла ошибка в коллбэке. Тем самым, получив nil, сложно понять, не нашлось ли индексов по условию или это в коллбэке ошибка.

Ещё функции, где возникают подобные вопросы:
getMoneyEx -- что в случае ошибки во входных параметрах (например, передал nil в качестве всех параметров), что в случае просто отсутствия информации (допустим, указали валюту, которой нет на лимитах -- это ведь не ошибка?) возвращается nil. Т.е. непонятно, то ли в аргументах ошибка, то ли просто информация не найдена.
getDepoEx -- аналогично;
getFuturesLimit - аналогично;
getFuturesLHolding -- аналогично;
getSecurityInfo -- тут спорно, т.к. nil можно трактовать как отсутствие информации по переданной паре аргументов. Т.е. что nil, что {} в данном случае -- в принципе, одинаково можно понять. nil даже получше будет, наверное.

Например, есть функции, где отсутствие информации трактуется как "не nil", и где ошибочные ситуации не задокументированы:
getClassSecurities -- возвращает пустую строку;
getMoney -- возвращает параметризованную таблицу со значениями по умолчанию (нули);
getDepo - см.getMoney;
getCandlesByIndex -- возвращает ({}, 0, ""), если запросили несуществующих тег;
CalcBuySell - возвращает (0, 0), если передать nil'ы в качестве аргументов;
getParamEx -- возвращает таблицу, если намеренно передать "испорченные" аргументы;
getParamEx2 -- см. getParamEx;
getPortfolioInfo -- возвращает {};
getPortfolioInfoEx -- см. getPortfolioInfo;
getBuySellInfo -- см. getPortfolioInfo;
getBuySellInfoEx -- см. getPortfolioInfo.

Отдельно:
IsWindowClosed -- функция задокументирована так, что по  сути ожидать приходится возврата либо nil, либо true. Чем провинился  false? Имхо, false можно было возвращать, если окно есть, но не  закрылось (по каким угодно причинам); true -- окно закрылось; nil --  окно не найдено или ещё какая напасть.

Подводя итог, по факту имеем:
1) часть функций, где не задокументирован формат возвращаемых значений в случае ошибки, но всё-таки возвращающих не-nil (пустые таблицы, строки, ...);
2) часть функций, где формат возвращаемых значений задокументирован ("возвращает nil"), но его трудно отличить от ситуации, когда аргументы семантически верные, но по ним нет данных;
3) остальные функции, где формат возвращаемого значения в случае ошибки задокументирован и не nil (true/false, -1, ...).

Т.е. на лицо некоторая непоследовательность в подходе к возвращаемым значениям-ошибкам. По науке, в Lua есть механизм error() для сигнализирования ошибок, но я осознаю, что могут быть разные причины его не применять. И если уж так, то пихать nil только в случае ошибок -- другие ситуации не должны возвращать nil.
Как-то так. Возможно, где-то что-то упустил, т.к. функций много, и не везде я при тестировании делал пометки, но что есть, то написал.
Нужно либо эти моменты получше задокументировать, либо переделать "по-феншую" (хотя тут, скорее всего, малой кровью не обойтись, т.к. уже написано немало кода с использованием существущего механизма).

P.S.
Функция SearchItems, по моим впечатлениям, страдает ещё от неверной работы фичи "если в коллбэке вернёте nil, то поиск индексов остановится и вернёт все подходящие индексы до этого момента + тот, на котором остановились": у меня почему-то SearchItems упорно возвращал nil, а коллбэк был что-то типа "function(t) if t.sec_code == 'AFKS' then return nil else return false end", при том, что этот же слегка изменённый коллбэк "function(t) if t.sec_code == 'AFKS' then return true else return false end" исправно выдавал массив из трёх элементов. Но этот момент я ещё потестирую отдельно на досуге. Написать всё-таки хотел не об этом, но побудила на написание поста именно она.
Страницы: 1
Наверх