Agent ID - What is it used for?

[JeremyWildsmith]

I feel like agent id is unnecessary? Its basically just an indirect reference to agent; is there an reason to keep it?

[DigitalSmile]

As far as I can see, it is used to get the right agent from the list... We need to store the reference to object itself or id. I will think about it more deeply...

[JeremyWildsmith]

Yeah, hmm. I can see if being useful if we have Offers from an agent created in the market, and then before the offers are resolved the agent is removed. Then when we go to resolve the offers, we can identify the agent is no longer in the market and ignore the offer.

Of course, we can do that with a reference too (ie, see if the agent is referenced in the list of agents registered in the market?)

Final note: The current approach to generating IDs could generate collisions. If we do keep agentId we should use an incrementing counter.

[DigitalSmile]

Technically UUID is incremental and hash from this should be unique. Collisions are possible in theory but very very unlikely. Anyway, I guess we can create a separate low priority issue and focus now on more important things :)

Then when we go to resolve the offers, we can identify the agent is no longer in the market and ignore the offer.

Not sure this is a good idea to ignore offers... We need to clean them up somewhere. Btw, I really do not like the current approach of setting offers -> resolving -> bankrupting. This leads to many things, like removed agents and left offers or bankrupted agents on the stage of resolving...

[JeremyWildsmith]

In terms of pros / cons of a Agent ID - I don't see how we gain from an id over a reference. If we want to, we could use a WeakReference. The only thing I see is that via an indirect reference (agent id) we aren't holding the Agent in memory if it is no longer being used (ie gc cannot collect it.) If that is an issue, we can just use a WeakReference. But yeah, I'll give it more thought.

Not sure this is a good idea to ignore offers... We need to clean them up somewhere. Btw, I really do not like the current approach of setting offers -> resolving -> bankrupting. This leads to many things, like removed agents and left offers or bankrupted agents on the stage of resolving...

I agree, I think this needs some more thought. Also we need to think about how agent logic factors into this - right now it is basically executing prior to offers.

Technically UUID is incremental and hash from this should be unique. Collisions are possible in theory but very very unlikely. Anyway, I guess we can create a separate low priority issue and focus now on more important things :)

Although unlikely, it is against design practice to rely on the uniqueness of a hash. That said, I agree - I will put this in a separate issue for now.

[JeremyWildsmith]

Agent ID was factored out.

[DigitalSmile]

Let me put those changes in refactory branch