Another
powerful thing is the MADynamicObject class, that
allows to define descriptions where you don't know the
possible properties in advance. Try something like:
B class>>optionsToBeUsed
^MADynamicObject on: [ 1 to: 100 atRandom ].
Sorry, I don't understand how this is then dependent on the instance,
because this is still on the class side, no?
Okay, in your case there is no ready made solution. Though, it is a
very interesting problem to investigate.
Just to explain where this problem is coming from: Basically I decided
to have no blocks in the descriptions to get an certain uniformity in
the interface. Of course it would be possible to have an option-block,
but then maybe later on I also want to have a dynamic nil-label-block,
and a default-block, ... and nobody knows where that should stop. What
is more, blocks are generally a bad thing to serialize, in most of the
cases they are not serialize-able at all, and I don't want to spoil
ability to serialize description objects.
Load the latest version of Magritte (Magritte-All-lr.10) and then there
are two different solutions to your problem:
1. Do you descriptions on the instance side of your class exactly as
you did on the class side but using the current state of the object.
Then override the message #description with the following snipped of
code:
MyModel>>description
^MABuilder default build: self.
2. Load the latest version of Magritte (Magritte-All-lr.9) and use
MAModelObject, it is similar to MADynamicObject but tries to pass into
the block the instance of the model. I suggest not to use it, unless
you really know what you do. Two more warnings: (1) Debugging code
using this dynamic object can be very nasty. (2) Don't have a look at
the code if you are easily scared.
A class >> descriptionElements
^(MAOptionsDescription selector: #foo)
options: (MAModelObject on: [ :model | model zork ];
yourself.
The first solution I presented seems to work in all cases and to be
much more clean. Try to use this one, if you don't have a reason not to
do so! However the second solution is something that main-stream
languages can't do and therefor it is cool :-)
Does anybody has a third solution?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
