Ciao. Il 12/08/2014 18:02, William Di Luigi ha scritto: > On Tue, Aug 12, 2014 at 5:12 PM, Giovanni Mascellani > <mascellani@xxxxxxxxxxxxxxxxxxxx > <mailto:mascellani@xxxxxxxxxxxxxxxxxxxx>> wrote: > > I'm not sure I understand: two objects with two different properties > (like the maximum value of N above) necessarily are two different > objects. The point is whether we want to allow two objects with the same > properties to actually be the same object. > > What I wanted to say is that there's no reason to disallow it. It's > clear that it can lead to bad things, but this is not a good reason to > disallow it IMHO. My main reason is that you have to add another layer of logic in the persistence logic and in everything else that uses tasks and contests. I see no real reason to introduce this new complexity, as it hardly describes anything that is really worthy keep tracking of. > Ok and if, for a particular reason, the user is ok with the first > semantics, then (s)he should be able to have that. If (s)he would want > the second semantics, then (s)he would create two different tasks. Of course we have to take decisions, which means that we decide to permit something and disallow something else. In this case I think that the overall balance of motivations suggests to not implement this feature. > Yeah, as I said, it's not the same thing. Although I see it as a (sort > of) "example" of how bad things can happen when an unnecessary behavior > is /enforced/. There can be good reasons to have a single instance of a > class, but it can be bad to /enforce/ a class to have a single instance. > There can be good reasons to have a task "tied" to a single contest, but > it can be bad to /enforce/ a task to be "tied" to a single contest. Enforcing behaviors makes it easier to have easier schemas and procedures. This is a good reason (although not the only one, but in this case the winning one) to do things. Again, by itself this is just my opinion. But I have to say that I'm inclined to think that other core developers share it. > I admit this can be a borderline case. In my opinion, the correct way to > handle this kind of contests is to actually make a contests with all > tasks and all contestants, tweak ScoreTypes in order not to give points > to contestants solving wrong tasks and modifying a bit CWS interface in > order to avoid mistakes as yours. > > > That would work, although maybe overcomplicating CWS (it might be better > to let CWS do its thing and do it good). I consider CWS' task to correctly present tasks to the contestant. Thus I find it proper to let it filter out tasks that a certain contestant is not supposed to solve. Moreover, I stress that the one you mention is TTBOMK the only case ever happened that had this strange needs. Giovanni. -- Giovanni Mascellani <giovanni.mascellani@xxxxxx> PhD Student - Scuola Normale Superiore, Pisa, Italy http://poisson.phc.unipi.it/~mascellani
Attachment:
signature.asc
Description: OpenPGP digital signature
