[Rivet] New projection method names without "projection"

[Andy Buckley]

I didn't think of that, but a bit too much potential for confusion, I 
think, since that's sort-of synonymous with "read from file" in several 
contexts -- most notably the #includes a few lines above.

Otherwise it makes me think "include in what?" -- although doubtless a 
similar argument can be made against "declare" ;-)

I've implemented "declare" in the default branch, targetted for the 
2.5.0 release, but it's still open to modification if someone comes up 
with an obvious improvement.

Thanks,
Andy


On 14/06/16 17:26, Leif Lönnblad wrote:
> "declare" is fine. Did anyone consider "include"?
>
> /Leif
>
> On 2016-06-13 14:23, David Grellscheid wrote:
>> I'm not vetoing declare, it's fine for me, too.
>>
>>    David
>>
>>
>> On 13/06/2016 11:51, Frank Siegert wrote:
>>> 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
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org
>> https://www.hepforge.org/lists/listinfo/rivet
>
> _______________________________________________
> Rivet mailing list
> 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