D-side

Идею я понял. Для её реализации, в сущности, нужно свести любую автоматизацию к программированию компа. А это значит, вопрос больше в наличии периферии для адаптации разных блоков. К сожалению, я не знаю, хватает ли для этого местного ассорти из периферии.

 

Логистику если нерфить, то только при наличии подключаемого к компу блока, который умеет слать приходящие предметы в разные трубы в зависимости от программы; а также очень не помешает некий агрегат, умеющий взаимодействовать (по заданной на Lua программе) с инвентарём других блоков. Если будет это - будет всё. Но при этом подскочит (эдак до уровня орбиты) спрос на программные продукты, и если предложения будет недостаточно, сервер почти опустеет - останутся только разработчики-любители и те, кто с ними сумел скооперироваться. Собственно, мне такой исход вполне по душе, но... я это я. Я тут просто человек, принципы проекта и важные решения не за мной.

По-моему, прежде чем конструировать язык разметки, необходимо собрать "рендерер", делающий интерфейс пользователя из некоего дерева (или списка) элементов. А потом уже придумывать сериализацию этого дерева (или списка) в некий язык разметки и обратно.

В любом случае, использование в качестве прототипа HTML мне видится неудачным выбором. Нам нужно скорее нечто вроде Markdown, похожий лёгкий по объёму и в обработке синтаксис.

Всегда срабатывает - подсчёт циклом.

local count = 0
for k, v in pairs(tab) do
 count = count + 1
end

Способа поумнее я не нашёл, и не уверен, что таковой вообще существует.

Есть вариант поддержания длины таблицы в отдельном поле, но это не всегда годится.

Возможно, может помочь это, хотя это скорее ультракороткий обзор всего языка: http://learnxinyminutes.com/docs/lua/

Это понятно. Просто, в приведенном примере поле file.filename нигде не используется. Используется же внешняя переменная filename (например, run = bind(shell.run, filename)). Отсюда и вопрос, зачем поле file.filename?

С остальным согласен.

Там, где объект будет использоваться, та внешняя переменная может уже быть недоступна. Скажем, это поле можно использовать для вывода файла на экран при наличии только объекта на этом файле.

Можно.

Во-первых, определение user наверху достаточно свести к {}, строчку с __index перенести внутрь new (self.__index = self), а методы, описанные в user'е, для экономии памяти лучше реализовать на нотации с двоеточием. Она работает предельно просто: вызов X:m(args) превращается в X.m(X, args)

Ну и user лучше написать с большой буквы, т. к. это класс, а из названия это не очевидно. User - гораздо лучше.

Как-то так:

function User:getPassword()
 return self.password
end
function User:setPassword(password)
 self.password = password
end

Обращаю внимание, что если методы getX и setX написаны с такой логикой, то они нафиг не нужны.

 

Вот в этой шпаргалке есть неплохой раздел по "ООП". Рекомендую.

Зачем в приведенном примере поле filename = filename? Ведь по сути будет использоваться только внешняя переменная filename.

В синтаксисе определения таблиц слева от = не переменная, а строковый ключ, написание которого подчиняется тем же правилам, что и переменные - чтобы его можно было вызывать через точку. Это короткая запись чуть более длинной:

{["filename"] = filename, <...>}

 

Но увеличит ли этот механизм наглядность? Например, встретив запись file.delete(), сразу ли вы определите какой именно файл удаляется?

Это зависит от программиста и определяется при создании объекта. Смысл можно заложить в само название переменной, куда он записан. Скажем, logfile.delete() - да, я однозначно пойму, что это, т. к. название переменной осмысленное.

 

Это, по моему, ни чуть не короче чем fs.delete("file").

В символах может и нет. Но по смыслу - это короче. Удалить сущность "файл" мы можем только из файловой системы. Но тут у нас в языке такой сущности нет - она косвенно выводится из того факта, что строка (!) обрабатывается функциями для файловой системы (!), значит это файл. В этом отношении код с привязкой даже нагляднее - независимо от того, с какими файлами мы работаем (а мы можем о них ничего не знать), мы можем отвести в коде осмысленное имя.

 

Справедливости ради стоит приложить аналогичный код на классе File, который я пока не написал, т. к. сегодня (буквально часа два назад) поставил свежий Linux Mint и накатил среду разработки в Lua.

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

 

Подобные штуки есть в куче языков. В стандартную библиотеку C++0x для этого (в том числе) ввели std::function, в Haxe и Haskell это просто часть языка. Многие считают такой приём чертой функционального стиля программирования, который я ещё не освоил, но стараюсь.

 

Работает это очень просто и код очень короткий. Берём функцию, указываем ей несколько первых аргументов - получаем функцию, которой надо указать только оставшиеся (если таковые есть):

function bind(f, ...)
 local higherArg = arg
 return function(...)
   return f( unpack(higherArg), unpack(arg) )
 end
end

Т. е. эта штука возвращает функцию, которая возвращает результат указанной вами функции, аргументами к которой выступает то, что вы указали при привязке (вызове bind), а затем то, что вы указали при вызове возвращённой из привязки функцией. Ещё ничего не закипело от обилия функций? Привожу пример.

Можете посмотреть сразу в интерпретаторе Lua. Это не слишком практичный пример, поэтому вот кое-что поинтереснее.

 

Допустим, вы хотите получить таблицу, содержащую путь к файлу и ряд команд, которые с ним можно выполнить без указания лишних данных. Примерно как у обычного объекта. Да, можно собрать класс "файл", но это не единственный способ, и у него свои недостатки. С биндом подобная штука записывается очень коротко:

filename = "file"
file = {
 filename = filename,
 run = bind(shell.run, filename), -- Можно смешивать функции из разных API
 delete = bind(fs.delete, filename) -- вообще без проблем
}
-- И эти операции можно вызывать без аргументов, забыв про API:
file.run() -- Запускаем файл
file.delete() -- Стираем файл

Конечно, в случае больших задач "нормальный" класс (с вызовами методов через двоеточие) предпочтительнее, поскольку даёт больше контроля над возвращаемыми значениями и обработкой возможных ошибок. Но если это не требуется, можно сэкономить время с помощью привязки. Есть и другие способы применения, на которые вы, может быть, наткнётесь сами.

Чаще всего это способ сэкономить на объёме кода, уложив повторяющийся аргумент. Компактнее, чем это делает вынесение в переменную, хотя потребляет несколько больше оперативной памяти, ведь такие "методы" будут создаваться каждый раз на каждую привязку. Осторожней с этим.

 

Это часть более крупной библиотеки, которую я пишу вот тут, на гитхабе. Потом перейду к каркасику для приложений, состоящих из менюшек (что покрывает на удивление много случаев).

 

Получить эту штуку на ComputerCraft'овский комп можно вот так:

openp/github get D-side/luaCC/master/bind.lua bind

Такие дела. Развлекайтесь! Надеюсь, скоро принесу ещё каких-нибудь плюшек.

CC и OC компьютеры способны получать все данные с реактора

Это вы меня не поняли =)

Меня интересует конкретный способ получения данных компьютером. Функция в API, например. Формат данных. Устройство. Ссылка тоже сгодится, даже на английском.

Меня интересует технический состав проблемы. А решение - это уже второй этап.

реактор можно подключить прямо к компу или к опенкомпу через адаптер. Причем опенкомп умеет все сам делать вкл выкл итд.

Подключить можно хоть редстоуновым проводом, но какие данные это даст? Редстоун позволит в произвольный момент выключать реактор, например. В сочетании с софтиной, поддерживающей цикл вкл/выкл, это обеспечит более-менее стабильную работу, но потребует предварительных расчётов/оценок. Никаких данных с реактора таким способом не получить.

Я делал на СС выключатель для реактора, под энергохранилище - оно давало сигнал редстоуном при заполнении, реактор выключался на время, и не включался, пока хранилище не переставало давать сигнал или не истекала задержка.

Это всё круто, но с какой аппаратуры эти показатели получать? Измерительные приборы соответствующие есть?

Эм, привет.

Давай конкретнее - какое аппаратное обеспечение есть, под какой комп, за чем следить, что делать?