[Rivet] New projection method names without "projection"

[Frank Siegert]

Hi Andy,

since you are asking for more voices, I'll add mine in favour of add
or declare. The former would be the conservative change, while declare
sounds logical to me in the sense of making it available as something
that can be accessed later on (just like a variable).

Cheers,
Frank


On 13 June 2016 at 12:44, Andy Buckley <andy.buckley at cern.ch> wrote:
> 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
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet