we talked a little bit with An & Alexis yesterday about how to change
the structure and the behaviour of a GAMA species instance (a class in
more general meaning) at runtime.
This is the kind of behaviour that could be done very easily with the
superpowers of Smalltalk ;-)
For example, "how to change the class of an instance" :
http://www.iam.unibe.ch/~akuhn/blog/2010/pharo-superpower-change-of-class/
Yet another superpower : "Build anonymous classes at runtime"
http://www.iam.unibe.ch/~akuhn/blog/2009/pharo-superpower-create-anonymosus-class/
This kind of modifications are usually done with "not so well
documented" tricks in other languages.
But as Smalltalk provide a reflective API, this is very convenient to
do that even for the "normal" programmer.
Regards,
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/
http://www.iam.unibe.ch/~akuhn/blog/2009/pharo-superpower-create-anonymous-class/
Actually, the discussion took place while we were looking for ways of implementing "delegation" between macro- and micro-agents (i.e. whenever a micro-agent is absorbed by a macro-agent, how to best describe the fact that some of the behaviours/attributes of the micro-agent are "taken in charge by" (or "delegated to") the macro-agent ?).
One way of seeing things is to describe the delegation in the macro-agent and let the micro-agents, at runtime, examine whether or not, when they are asked for something, this should be delegated to the macro-agent. This raises, obviously, performance concerns, as each access to an attribute/action needs to be checked at runtime.
Another way of seeing things is to let the macro-agent describe a local species (sub-species of the species of the micro-agent), which redefines only the attributes and behaviors to be delegated (and possesses a link to the macro-agent). Whenever a micro-agent is captured, instead of having it checking for delegation at runtime, we can make it an instance of one of these dynamic species: it does not know (and does not need to know) it has been "transplanted", but all the calls now flow through this species rather than its original one.
Since, in GAMA, we control all the instantiation process and have access to all the structures (species, agents, controls, etc.), it is quite easy to implement this "superpower". There are no other performance penalties than the ones involved, when a macro-agent is created, in the creation of its dynamic "delegation species". If there are none, its costs nothing.
There are several conceptual (and implementation) problems to solve before having this solution operational, and this will be the work of Vo Duc An in the next weeks. But this will provide for a very elegant way of handling "delegation", which can afterwards be extended to the whole system (the "world" being the default "macro-agent" of all species).
Cheers
Alexis
> --
> Groupe de discussions sur GAMA / Discussion group on GAMA
> to send a message: gama-p...@googlegroups.com
> to quit: gama-platfor...@googlegroups.com
> group address: http://groups.google.fr/group/gama-platform?hl=fr
--
[email] alexis....@gmail.com
[web] http://www1.ifi.auf.org/mediawiki/index.php/Alexis_Drogoul
[mobile] +84915088155
[affiliation] IRD (Institut de Recherche pour le DeŽveloppement), UMI UMMISCO 209 (IRD/UPMC)
[address] IFI/MSI, ngo 42 Ta Quang Buu, Hai Ba Trung, Ha Noi, Viet Nam
[calendar] http://ical.mac.com/drogoul/Calendar
[skype] drogoul [gizmo/yahoo] adrogoul [ichat/msn] dro...@mac.com
"Prediction is very difficult, especially about the future." Niels Bohr
Yes, as GAMA is a kind of instance of the AOM (Adaptive Object Model)
pattern (more here: http://adaptiveobjectmodel.com/), i guess you
could add a reflective layer to mimic some of the runtime
modifications you could found usually on a Smalltalk system.
The problem is that when you use these kind of functionalities, you
have performance penalties (especially when you use runtime behavior
modifications). Smalltalk implement transparently (i.e the user is not
aware of that) some of these functionalities at the VM level
(implemented in C), so the performance are not that bad.
But as the Java does not implement dynamic features at VM level and
also because GAMA is a kind of interpreter on top of Java (TBC by
Alexis ?), you might expect some big performance loss.
BTW, if you want to have millions of agents, maybe you don't need
reflective features or only at design time. We have done something
similar with a colleague from Brest in order to do a simulation of
sensors networks & mobile agents. At design time, we could do a
simulation in Smalltalk and after that if we want to have some boost,
we generate from the Smalltalk code a GPU (Graphics Processing Unit)
C++ program. More information are available here:
http://wsn.univ-brest.fr/main/?page_id=121
Hi Gamaers,
> Actually, the discussion took place while we were looking for ways of implementing "delegation" between macro- and micro-agents (i.e. whenever a micro-agent is absorbed by a macro-agent, how to best describe the fact that some of the behaviours/attributes of the micro-agent are "taken in charge by" (or "delegated to") the macro-agent ?).
>
> One way of seeing things is to describe the delegation in the macro-agent and let the micro-agents, at runtime, examine whether or not, when they are asked for something, this should be delegated to the macro-agent. This raises, obviously, performance concerns, as each access to an attribute/action needs to be checked at runtime.
>
> Another way of seeing things is to let the macro-agent describe a local species (sub-species of the species of the micro-agent), which redefines only the attributes and behaviors to be delegated (and possesses a link to the macro-agent). Whenever a micro-agent is captured, instead of having it checking for delegation at runtime, we can make it an instance of one of these dynamic species: it does not know (and does not need to know) it has been "transplanted", but all the calls now flow through this species rather than its original one.
>
> Since, in GAMA, we control all the instantiation process and have access to all the structures (species, agents, controls, etc.), it is quite easy to implement this "superpower". There are no other performance penalties than the ones involved, when a macro-agent is created, in the creation of its dynamic "delegation species". If there are none, its costs nothing.
>
> There are several conceptual (and implementation) problems to solve before having this solution operational, and this will be the work of Vo Duc An in the next weeks. But this will provide for a very elegant way of handling "delegation", which can afterwards be extended to the whole system (the "world" being the default "macro-agent" of all species).
There is a quite old paper "Dynamic Instance-Class Link" on the
possibility to move instances from class to class from Fred Rivard
here:
http://fredrivard.ifrance.com/fredrivard/pub/dicl/dicl.ps
This paper deals with more complex instance migration schema than the
one you could do usually with the primitiveChangeClassTo: method that
need to have format-identical classes (i.e same structure). You could
found also in Smalltalk a become: method to replace an instance with
an other.
I know that some guys in the Smalltalk community are working on more
advanced version of instances migration.