[Rivet] New projection method names without "projection"

[Andy Buckley]

This'll go round in circles, but when I see "schedule" I think "when"? 
And there's no answer to that.

Tl;dr: "declare" is still my preference. In more excruciating detail:

"Declare" describes what's actually being done -- we are telling the 
system about the existence of the projection and giving it a name with 
which to access it. I'm not sure what's particularly "computer sciencey" 
about that word, but if you mean that it;s an analogy with declaring a 
variable (which I'd not consciously acknowledged) note that this will 
only be seen/written by people who are writing analysis code, so 
hopefully most would not find it an unnatural phrase. And again, note 
that we already use it in DECLARE_RIVET_PLUGIN at the end of every 
analysis .cc file...

"bind" might have been an alternative, but a) it's even more 
computer-sciencey, and b) the confusion with the "new" std::bind is 
almost as bad as "register" -- arguably worse, since we might actually 
need to use std::bind someday!

More voices?
Andy



On 13/06/16 10:54, David Grellscheid wrote:
> I still prefer schedule over declare, exactly _because_ it has the
> implication that it is something that will be run. The caching and so on
> is an implementation detail users don't need to bother with.
>
> declare is too computer sciency for me. With that background you know
> what it means, but the generic meaning of declare is not really useful
> for us.
>
>    David
>
>
> On 12/06/2016 02:06, Christian Gutschow wrote:
>> Oh I like declare! I think that’s my favourite of all the suggestions.
>> Yes, let’s go for that one if there are no objections?
>>
>> Chris
>>
>> On 11 Jun 2016, at 22:24, Andy Buckley
>> <a.g.buckley at gmail.com<mailto:a.g.buckley at gmail.com>> wrote:
>>
>> I read appoint as annoint, which is even better ;-) Perhaps also
>> consecrate, sanctify, or bless?
>>
>> But more seriously, I thought of "declare" earlier today and am not
>> sure why it didn't come to mind sooner. For me it is at least as nice
>> as "register" -- in fact, we already use it in the macro that
>> registers/declares analysis plugins (and no, I don't think there's any
>> danger of confusion). And way more appropriate than "add", IMHO. What
>> do you think, can we use it?
>>
>> Andy
>>
>>
>> On 10/06/16 22:17, Christian Gutschow wrote:
>> Hi Andy, all,
>>
>> schedule seems alright to me. Here are some more alternatives for the
>> brainstorming: commission, employ, engage, enlist, appoint, establish.
>> ;-)
>>
>> Cheers,
>> Chris
>> On 10 Jun 2016, at 20:58, Andy Buckley
>> <andy.buckley at cern.ch<mailto:andy.buckley at cern.ch>
>> <mailto:andy.buckley at cern.ch>> wrote:
>>
>> Ha, we had the same response to "register" being forbidden!
>>
>> I certainly agree with dropping reg().
>>
>> schedule() is not bad -- I'd like to know what others think. The only
>> flaw is that to me it implies that that projection will be run at a
>> set time / order, while in practice it's lazy (and the result may
>> already be cached).
>>
>> enroll() / enrol() will probably suck others into that US/other
>> spelling trap ;-)
>>
>> record() is not quite right -- I feel like it specifies writing
>> something to disk immediately.
>>
>> And catalog()... I don't really know what that implies.
>>
>> Grr, words. Right, I'm going to try and have a weekend now, and let
>> this little word puzzle itch away in the background. Feel free to join
>> me in this bikeshedding: names are important ;-)
>>
>> Andy
>>
>>
>>
>> On 10/06/16 17:30, David Grellscheid wrote:
>> Hi Andy,
>>
>> Here's my preference (after some thesaurus googling):
>>
>> drop add() and reg()
>>
>> use schedule(), enroll(), record() or catalog() instead of register()
>>
>> We shouldn't multiply names for the same functionality. One deprecated
>> name and one replacement is enough.
>>
>> See you,
>>
>>   David
>>
>>
>>
>> On 10/06/2016 16:30, Andy Buckley wrote:
>> Ah, I see!
>>
>> Anyway, yes we have had feedback that people don't really understand how
>> the concept maps to the Rivet code so I think hiding by default is a
>> good thing. And if it allows us to have shorter function names without
>> losing clarity, that's no bad thing.
>>
>> I've implemented this on the 2.5 branch now. The one stumbling block was
>> with the idea of register(someproj, "SomeName"): 'register' is a C(++)
>> keyword, so I think we can't use it as a function name -- right? For now
>> I've created aliases for addProjection called both add(...) and
>> reg(...): any better ideas, or a preference to drop one? While I prefer
>> the name "register" to "add", given that addProjection is being retained
>> and that "reg" is not so obvious to remember or interpret, I'm inclined
>> to ditch it. Thoughts?
>>
>> Andy
>>
>>
>> On 24/05/16 14:17, Leif Lönnblad wrote:
>> On 2016-05-24 00:06, Andy Buckley wrote:
>> On 23/05/16 22:31, Frank Siegert wrote:
>>
>> I quite like the picture, but a) the algebraic mapping is not exact
>> because you can't actually do P(P(Event))
>>
>> In fact that was how the original design intended things to work,
>> but it
>> was lost along way. Don't quite remember why.
>>
>> Anyway, I don't mind hiding the word from the users, if they are
>> confused by it.
>>
>>
>> /Leif
>>
>>
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org>
>> <mailto:Rivet at projects.hepforge.org>
>> https://www.hepforge.org/lists/listinfo/rivet
>>
>>
>>
>>
>> --
>> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
>> Particle Physics Expt Group, University of Glasgow
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org<mailto:Rivet at projects.hepforge.org>
>> <mailto:Rivet at projects.hepforge.org>
>> https://www.hepforge.org/lists/listinfo/rivet
>>
>>
>>
>>
>>   —
>>
>>   Dr. Christian Gütschow
>>
>>   TU Dresden
>>   Institut für Kern- und Teilchenphysik
>>   Zellescher Weg 19
>>   01069 Dresden
>>
>>   > at CERN: 104-02-C02
>>   > at IKTP: E17, ASB
>>   > chris.g at cern.ch<mailto:chris.g at cern.ch> <mailto:chris.g at cern.ch>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
>> Particle Physics Expt Group, University of Glasgow
>>
>>
>>
>>
>>   —
>>
>>   Dr. Christian Gütschow
>>
>>   TU Dresden
>>   Institut für Kern- und Teilchenphysik
>>   Zellescher Weg 19
>>   01069 Dresden
>>
>>   > at CERN: 104-02-C02
>>   > at IKTP: E17, ASB
>>   > chris.g at cern.ch<mailto:chris.g at cern.ch>
>>
>>
>>
>>
>>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow