On 01/12/2012 11:09 AM, osimons wrote:
...
Yes, something like that looks like it should work. But if done like
that, I still don't understand why you wouldn't just pass the tickets
to your scheduler? Your code comments say you pass a copy so that
schedulers can "mess" with the ticket data, but any Trac and plugin
code should really be trusted to do the right thing with objects they
get passed. I don't see the reason for building structures to hide and
protect data when all is available anyway. It is Python after all...
But, your code - you decide :-)
It's not hiding details from the scheduler but giving the scheduler the
freedom to update values as needed for scheduling (whatever the
algorithm may need) and keeping the contract with the caller of
computeSchedule() that the only difference is that calc_start and
calc_finish have been added to each ticket.
I could have each scheduler cache values it may stop on and put them
back before returning (though I can't get copy to work there, either).
Or I could have each scheduler make a scratch copy of any ticket
attributes it needs to change and only work with that copy (though that
seems less elegant in many ways).
Perhaps one way to think of it is that the scheduler operates on "tasks"
and a "task" is a dictionary that holds the same values as a ticket. To
the extent that ticket['fieldname'] works, duck typing says that a
ticket is a task but because I can't deep copy a ticket to preserve its
attributes, that breaks down.
Chris
--
Christopher Nelson, Software Engineering Manager
SIXNET - Solutions for Your Industrial Networking Challenges
331 Ushers Road, Ballston Lake, NY 12019
Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
