[Freeciv-Dev] Re: (PR#6340) gtk2.0 / 1.14.1beta: item being produced should be first on queue

["Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>]

On Thu, 2 Oct 2003, jjc@xxxxxxxxxxxxxxxxxx wrote:

> On Thu, Oct 02, 2003 at 02:45:26PM -0700, Vasco Alexandre da Silva Costa 
> wrote:
> >
> > On Thu, 2 Oct 2003, Mike Kaufman wrote:
> >
> > > On Thu, Oct 02, 2003 at 06:04:39AM -0700, Vasco Alexandre da Silva Costa 
> > > wrote:
> > > > This is temporary until worklists code changes so such hacks cease being
> > > > necessary. That may be post 1.14.1.
> > >
> > > i assume that you're talking about pcity->currently_building. That is a
> > > load of crap. Vasc, I think you need to take half an hour and explore 
> > > this.
> > > I think you will find that the cure is worse than the disease.
> > The worklist API is braindead, simple as that. The model of the API is not
> > the same as the model people expect a worklist to behave like in the
> > client. You want to kludge around the API to make it so. An API we control.
> > That should tell you something.
> What are you refering to?  If you are refering to pcity->currently_building
> as I said in regards to PR#4426:
>
> Question 2.
> Is the method for doing current production braindead?
>
> The current method is to have a seperate worklist and current production
> status.  The worklist is stored in city.worklist and the current production
> is held in city.is_building_unit, city.currently_building and 
> city.shield_stock
> When a city finishes building a unit, the first item from the worklist
> is popped off the worklist and put into currently building.
>
> It would seem to make sense to eliminate the redundant city.is_building_unit
> and city.currently_building from the city struct and just add another slot
> to the worklist and make the first item in the worklist the current item.
>
> However, the a seperate current production does make a bit of sense,
> since the current production is unique.  The current production is
> usually partially done.  If you made the first item on the worklist
> the current production, it would complicate the code to do something
> like say swap the first and the second items, since the code would
> have to remember to change the number of shields stored (if say you
> switched from settlers to temple).  Since there are these special
> cases when dealing with the current production, I am not certain that
> making the first element in the current production will actually
> significantly simplify code.  I am on the other hand certain that
> making this change will be a fair amount of work.
>
> In short, the worklist is the list of items waiting to be produced,
> and the current production is currently being produced, and changing
> the current production is different from changing a item on a queue,
> so this is not necessarily braindead to have seperate variables.  I
> believe that more justification needs to be made for such a
> fundemental change.
>
>
> Please explain your logic for it being braindead and explain what you think
> is braindead, or refer to somewhere where you have discussed this in detail.

For me the major problem is that there isn't an API in common/ or client/
for doing what we want to do, rather than the way the data is organized
inside the structures.

From what I understand, people want the worklist in the client to have the
current production at the top of the worklist. They want to be able to
add items to the head of this worklist, changing the current
production, pushing the old production for later on. They also want to
be able to skip the currently being produced item to the next item in the
worklist.

This is not the way the worklist API presents itself. The worklists are
totally disconnected with the current production. But that is not what
people want the city worklists to do. If this means making yet another API
on top of the worklist API which does this, or reworking the worklist API to
account for these operations... I still have not decided which way is best.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa