On Thu, Nov 14, 2013 at 4:49 PM, Oswald Buddenhagen <[email protected]> wrote: > On Thu, Nov 14, 2013 at 05:30:08AM -0600, Felipe Contreras wrote: >> On Tue, Nov 12, 2013 at 5:55 AM, Oswald Buddenhagen <[email protected]> wrote: >> > On Tue, Nov 12, 2013 at 05:06:08AM -0600, Felipe Contreras wrote: >> >> On Tue, Nov 12, 2013 at 4:40 AM, Oswald Buddenhagen <[email protected]> wrote: >> >> > On Mon, Nov 11, 2013 at 07:05:04AM -0600, Felipe Contreras wrote: >> >> >> Oswald Buddenhagen wrote: >> >> >> > this is now done in the maxmessages branch. >> >> >> > the option is called ExpireUnread yes/no >> >> > >> >> >> you start from the assumption that people would automatically assume >> >> >> unread messages are not included in this limit, and I think it would >> >> >> be the opposite for most people. >> >> >> >> >> > well, there are two considerations: >> >> > - i didn't want to change the default behavior >> >> > - i wanted to default to the safe (don't miss messages) option. though >> >> > it can be argued that this default is unsafe as far as the size of the >> >> > initial fetch goes. so maybe i should just make it error out if >> >> > MaxMessages is exceeded by more than 50% and no explicit setting is >> >> > present. >> >> >> >> That is orthogonal; the default of ExemptUnread can be 'yes'. >> >> >> > huh? >> >> ExceptUnread = yes doesn't change the default behavior.. >> > yes ... so what exactly does the orthogonality refer to?
The default behavior is independent of the name of the variable. >> >> >> I think LimitExcemptUnread is much clearer because a) it explains what >> >> >> the >> >> >> option affects; limits (which could be MaxAge, MaxMessages, etc.), b) >> >> >> the word >> >> >> except makes it clear that the limit rule doesn't apply to this kind of >> >> >> messages. >> >> >> >> >> > you meant "exempt". ;) >> >> > while "limit" may associate better with the "max*" options, it's not >> >> > self-explanatory either. so given that one needs to look into the man >> >> > page anyway and the related options are right next to each other, i >> >> > don't think it's much of a consideration. >> >> > also, "LimitExemptUnread" is just awkward. it's bad grammar, and sounds >> >> > plain awful. >> >> >> >> ExemptUnread then. >> >> >> > the immediate question is then "from what?". >> >> By following the rules of rationality it must be a rule, and what kind >> of rule could affect unread messages? >> > as i said, you are assuming way too much. if you really draw such > conclusions from so short names, you are in for some really nasty > surprises. OK. If it's not related to a rule, what could Exempt mean? >> There's only one AFAIK; MaxMesages. >> > as i said, currently. > >> Plus if you don't think that's clear, it could be called LimitUnread. >> > it could be. i still think Expire is better, because it is more specific > (something first is, then ceases to be, as opposed to just being somehow > restricted). > >> In this case there's no mental jump required; the rule it affects is >> the MaxMessages limit. >> > latest when there is MaxAge, Expire will be an unbeatably obvious term. No. > and as explained before, it already makes sense today when looking from > the temporal perspective. It doesn't makes sense for today, much less for the future. >> > there is also another consideration here: if the choice is not >> > otherwise mandated, it's better to avoid negative option names to >> > avoid confusing double negation. >> >> I don't know what you mean. >> > ExemptSomething == do not do something with something. to enable doing > something, set the option to no == do not not do something with > something. bad idea. How does LimitUnread exhibit this problem? >> Besides, once you add the ExcessMessageMode: Keep option, it wouldn't >> really be "expiring" anything, would it? >> > it would still expire from the "working set". What does that even mean? http://www.merriam-webster.com/dictionary/expire : to end : to no longer be valid after a period of time : to die To die from the "working set"? To no longer be valid after a period of time from the "working set"? What the f*ck is that? > apart from that, this mode will make other related option names > inaccurate if one was pedantic, so i don't think this is a useful > consideration. First you argue Exempt could be inaccurate if *future* options are added, and now you say it's not important that Expire makes *current* options inaccurate. So we shouldn't be pedantic with your name, we should be strict with mine. Is that it? You want to have your cake and eat it. And at no point in time are you even touching LimitUnread. Presumably because it makes more sense and it's harder to argue against. It seems clear to me you are not looking for the right name, you made your mind and you are simply defending what you already decided and no argument is going to change your mind. I bet you wouldn't even agree to a vote. So go ahead with what you already decided, even though it's demonstrably wrong. There's no point in me trying to argue for a better name, if you are not looking for one. -- Felipe Contreras ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
