[Rivet] New projection method names without "projection"

[David Grellscheid]

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