[contestms-dev] Re: Separate users and tasks from contests
- From: William Di Luigi <williamdiluigi@xxxxxxxxx>
- To: contestms-dev@xxxxxxxxxxxxx
- Date: Tue, 12 Aug 2014 15:31:50 +0200
On Tue, Aug 12, 2014 at 12:14 PM, Giovanni Mascellani <
mascellani@xxxxxxxxxxxxxxxxxxxx> wrote:
> This is, as I already mentioned in my previous email, the same reason to
> say that we probably don't want to do the same with tasks: the same
> "task" in two different contests actually are two different tasks, not
> the same task referred twice. When you modify one of that, you expect
> the other not to change (except exceptional cases, but this is trivial).
>
I personally think that it's not always necessary to exactly represent
reality, I mean, if you want to clone a task (for example, because you have
a version where N <= 1000 and another version where N <= 1000000 where you
have to implement a better strategy) you can simply create two different
tasks (mytask, mytask2), but we should not *enforce* this. That is: even if
it's apparently not realistic, we have no reason to avoid having an
identical task referred twice (the point is: I think that reality is not a
good reason).
This i probably unrelated but consider what Misko Hevery has to say about
the Singleton design (anti-)pattern:
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
tl;dr «There is nothing wrong with having a single instance of a class,
lots of reasons why you may want to do that», the problem arises when you
*enforce* a class to have a single instance.
Also, consider this *real* use-case (actually happened before): during a
training week there was a selection, but there were some experienced
contestants and some new contestants, so they participated at the same time
in two different contests. These two contests had three tasks each,
respectively: *contest_1* had task_A, task_B, task_C, and *contest_2* had
task_B, task_C, task_D. These 4 tasks had the same statement.pdf, the same
limits, the same inputs, and so on. In this case, having the tasks-contests
separation would have come handy.
(Actually, when this happened, I remember that there was a single contest
with 4 tasks and they said what tasks we had to do... And it was so
confusing that I managed to waste almost 1 hour on the only task that I
didn't have to do :P)
> * cmsReimporter disappears
> > o Why reimport an entire contest when you can reimport exactly
> > what you changed? (well, actually */italy_yaml/* checks if a
> > task has been changed before importing it... this check would
> > still be handy, to "warn" contest admins trying to reimport an
> > unchanged task, but would become unnecessary). Also, in "my"
> > use-case, even checking if tasks have been changed it's still
> > quite annoying (we have about a hundred tasks).
>
> Well, to me the point of a reimported is just that of being lazy and
> asking the reimported to mind about the merging details.
>
But cmsReimporter is very hack-ish, because of this merging details (see
https://github.com/cms-dev/cms/blob/v1.1/cmscontrib/Reimporter.py#L261),
correct me if I'm wrong.
--
William.
Other related posts:
