On 3/16/06, momerath michael@guildsoftware.com wrote:
Hi,
I'm thinking the cargo problem isn't as well-suited to Cells as some of the other things on my todo list. I picked it because it was simple, but I think I now grasp the direction that it would go; my basic disconnect was how a hash-table could be used as an input or intermediate cell. It looks to me now that I wouldn't gain much over my existing procedural/rule-based version by re-implementing it with Cells (at least short of implementing ZigZag first).
I am having a hard time following you, but my rough guess is that Cells would be fine for this application. I am not sure why you think otherwise. The hash-table thing is irrelevant; it is nothing but an optimization, and there is no need to give up the optimization to do Cells, you just have to make sure you expose state change to the Cells engine. Mutating any data structure bypasses the Cells watchdog, so you have to implement with the hash table behind the scenes, in a non-Cell slot, maintained by observers on Cells slots that do actually change and trigger Cells change management.
Actually, I think you just lost interest in shipping. :)
Your big mistake is deciding what Cells is good for when you still do not know what Cells is. Zigzag or no. Or how Cells refactors an application. One thing you miss in your search for the Holy Grail is that even in modest roles, Cells still makes things significantly nicer in many small ways. A good example is simply being able to have an initform that can compute of arbitrary state as if in initialize-instance. Another is something as prosaic as managing a group of radio buttons. Any idiot can do that, but it is still nicer with Cells.
On the other hand, the next big feature I'm going to implement is a dynamic economy simulation, which, I think, is exactly the type of system Cells would be good for modelling. So here is a description of a somewhat simplified system in english- (psuedo)code coming soon:
-- The primary actors are Stations (space-stations). Stations have an inventory of Items. Items are either fundamental (ore) or produced from other Items (produced and fundamental). The required ingredients for each Item are static. Each Station has a set of Items which it produces, and by implication of the production requirements, a set of Items to stock.
Initially, an arbitrary desired quantity of each item will determine when and how the Station takes steps to bring the quantity closer to the norm. The steps a station can take are: adjusting prices, producing a desired item from more plentiful ingredients, negotiating a shipment from another Station, and posting a mining mission (for ores).
In shipping negotiation, the providing station determines its capability (items in stock?) and overhead (payment of player/npc traders and escorts (number determined by route danger)), and makes an offer to the receiving station (a procedural way of describing something that could be done in a more "push" or Cells-ish way). The receiving station accumulates offers for all stations that it does business with (whole other ball of wax), and then picks the cheapest. Shipments encounter danger and rarely make it through completely intact. At least initially, the payment is for goods received and the providing stations don't notice trends in route danger, so no risk/benefit analysis need be done.
I think that covers the basics. In the future, some of the decisions would be put in the hands of planning agents (how much to stock, which stations to deal with, determining supply and demand curves, etc). --
While you think about that (if you get a chance), I'll try to implement it, and I'll post again when I get stuck or I've got something to critique.
I'll be happy to help. It sounds like you are coming up to speed nicely on Cells, so I will wait for you to come back with specific problems/requirements. Don't be shy. Even if you are Cells cannot do something, that is usually how Cells get extended / enhanced / fixed.
ken