Лидеры

Для тех, кому лень читать длинный текст: Проблема: Код, записанный в EEPROM и на загрузочных дисках, может быть запущен на процессоре неподходящей архитектуры. Решение: Описанный в статье стандарт. Автор предлагает добавлять в код EEPROM комментарий с указанием требуемой архитектуры, а также модифицировать OpenComputers, чтобы тот распознавал архитектуру, указанную в EEPROM. Есть похожее предложение по маркировке дисков, но я уже не стал вникать. По-моему, проблема высосана из пальца и не требует решения. Обычно этим занимается установщик. Он прошивает EEPROM, записывает файлы на диски, устанавливает нужную архитектуру и перезагружает компьютер, полностью настроенный и готовый к работе.

Это не привязывает параметр localX к object.x. Если можно вместо localX использовать x, то прибиндить можно так: local object = {x = -20} object.raw = object object.x = 15 print(object.x,object.raw.x) -- 15 15 object.x = 0 print(object.x,object.raw.x) -- 0 0 object.raw.x = 20 print(object.x,object.raw.x) -- 20 20 Если разные имена нужны, придётся пользоваться метатаблицами. local raw = {localX = -20} local object = setmetatable({raw = raw}, { __index = function(self, k) assert(k == 'x') return raw.localX end, __newindex = function(self, k, v) assert(k == 'x') raw.localX = v end }) object.x = 15 print(object.x,object.raw.localX) -- 15 15 object.x = 0 print(object.x,object.raw.localX) -- 0 0 object.raw.localX = 20 print(object.x,object.raw.localX) -- 20 20 Но вообще, стоило бы лучше продумать архитектуру кода.