Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- geopro:pedro:tmedisc [2010/05/19 13:09] – created pedro
+++ geopro:pedro:tmedisc [2010/06/29 21:10] (atual) – pedro
@@ Linha 1: / Linha 1: @@
-====Operador # para CS, Neighborhood====
+====Observer====
+observer(cell) que não recebe um atributo, e sim uma função que retorna o valor a ser usado.
-toda metatable pode ter um operador "__len", que implementaria o operador #. O problema é que,
+====Save====
-para tabelas, ele [[http://www.lua.org/manual/5.1/manual.html#2.8|não tem como ser chamado]]:
+  * Ver a questão temporal abaixo.
+  * Ao invés de receber um atributo como parâmetro, o save poderia também receber um function(cell) para calcular o valor dinamicamente. Desta forma, um valor que representasse a estratégia do agente dono da célula não precisaria de um forEachCell adicional para atribuir este valor à célula e ainda economizaria memória.
+====Questões temporais====
+  * Quando tiver o current simulation time como valor global, verificar os save para que time tenha como valor default o tempo atual.
+  * Para leitura de espaços celulares e de vizinhanças, verificar as tabelas temporais e colocar no timer eventos para atualizar os dados com os novos valores temporais. Estas alterações devem ter prioridade sobre todas as outras ações.
+  * A função config para um Event que está executando nao afeta o desenvolvimento deste mesmo evento no futuro.
+====Operador # para CellularSpace, Neighborhood====
+Fonte: http://www.lua.org/manual/5.1/manual.html#2.8
+toda metatable pode ter um operador "len", que implementaria o operador #. O problema é que,
+para tabelas, ele não tem como ser chamado:
      function len_event (op)
@@ Linha 20: / Linha 33: @@
        end
      end
+De acordo com listas de e-mails, será possível fazer isto com [[http://www.lua.org/versions.html|Lua 5.2]].
+====__index and __newindex metamethods to Observing====
+Fonte: http://julien.danjou.info/blog/index.php/post/2008/12/30/Rants-about-Lua
+Lua defines two useful metamethods, which are _index and _newindex. Both can be set on a table or any other object. _index will be called upon each read access to an undefined key on an object, and _newindex upon each write access.
+Example
+  a = {}
+  setmetatable(a, { __index = myindexfunction, __newindex = mynewindexfunction }) -- function are not defined, this is just an example
+  a[1] = "hello" -- This will call __newindex metamethod
+  return a[2] -- This will call __index metamethods
+  return a[1] -- This will NOT call __index
+The last line does not call index meta-method because a[1] does exists. This is a problem when you want to use table as object, because sometimes you want to monitor access to the table elements.
+This can be easily worked around using a proxy system: you don't store things in the table you manipulate, but in another table.
+  a = {}
+  realtable = {}
+  setmetatable(a, { __index = myindexfunction, __newindex = mynewindexfunction }) -- function are not defined, this is just an example
+Where meta-methods are something like:
+  function myindexfunction(table, key)
+    return realtable[key]
+  end
+  function mynewindexfunction(table, key, value)
+    realtable[key] = value
+  end
+This way, our a table will always be empty, and realtable will have the data. At every read or write access to a, the meta-methods will be called. This is very convenient and widely used hack.