[Rivet] New projection method names without "projection"

[Leif Lönnblad]

"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