Re: Naming RFC: Properties, property sets, presets

[Urs Liska]

Hi all,

thank you for the great discussion so far. The most important takeaway
is that it was good to have raised the issue, and to have done it now.

I won't quote every reply but I'll comment on the suggestions and maybe
clarify the concepts where necessary.

Am Sonntag, den 12.07.2020, 20:06 -0400 schrieb Fr. Samuel Springuel:
> To me this looks like a property set with inheritance
> rules.  Frankly, I would suggest implementing a unified notation and
> not have two separate concepts that need naming.  Unless there’s some
> fundamental reason why a “preset” without a parent is different from
> a “property set” that I’m missing.
> 

I *think* you are missing something here.
A "property set" is the totality of available properties for a given
entity, which might be a package or a function. This is comparable to
the available properties of a LilyPond grob
What I labeled "preset" is a set of values for a subset of these
availalbe properties. You can have a "preset" and also inherited
"presets", but the "property set" is still and independently present in
the background.

But what this triggered as an idea is to pull out the "preset" out to
be an optional symbol parameter. So in order to call a function with a
"preset" but no extra overrides it is not necessary to write a \with
block but simply
  \myFunction style-two c'
and still
  \myFunction style-two \with { label = "Foo" } c'
or simply
  \myFunction c' % as was already possible


Am Montag, den 13.07.2020, 12:16 +1000 schrieb Andrew Bernard:
> I have an issue with 'preset'. If you look at software
> synths, for example, 

I think the analogy is pretty good

> they can store and load 'presets' but these are
> _all_ the parameters for a patch. I don't ever think the word preset
> means a subset of a set of settings or properties.

Maybe, maybe not. A synthesizer might also implement its storage so
that only parameters are actually stored that differ from the factory
values of the parameter.
>From the perspective of the *result* it's also the same: With my
function *all* properties are available, some with the default values,
some with values from a "preset" and some with values from the local
invocation.

What is of course different from how synthesizers behave is that the
resulting set is not completely defined by the preset but also by the
current state of the property set.

> 
> As Fr. Samuel has said, the concept here is similar to the cascade in
> CSS, a simple inheritance hierarchy.

But the inheritance part is IMO distinctly handled at a later stage.
Whatever I'll end up calling it, the "presets" are the entity that is
inherited, not the property set.


Am Montag, den 13.07.2020, 02:21 +0000 schrieb Carl Sorensen:
> How about "profile"?

I think this is something to consider. It is conceptually similar to
the "context" and "environment" that has originally been suggested to
me, but without the burden of being already in use.


Am Montag, den 13.07.2020, 12:46 +1000 schrieb Andrew Bernard:
> Dare I say it, they are almost like overrides. Similar to modifying
> alists also.

Of course it is very similar to overrides. If you think of all the
properties of a NoteHead as a property set then

styleOne = {
  \once \override NoteHead.color = #red
  \once \override NoteHead.font-size = 4
}

is exactly my \definePreset. You could even implement inheritance here.
But ...


Am Sonntag, den 12.07.2020, 21:39 -0600 schrieb Carl Sorensen:
> Override would be a good word, but we already use override in
> lilypond.  I don't think we want to have two different meanings for
> the word override.  

I fully agree with that.


Am Sonntag, den 12.07.2020, 21:39 -0600 schrieb Carl Sorensen:
> On Sun, Jul 12, 2020 at 8:40 PM Andrew Bernard <
> andrew.bernard@gmail.com> wrote:
> > I think a profile is a complete list of settings/properties.
> 
> Maybe it's a "configuration", then.
> 
> Or a "setting" (instead of a preset).
> 
> One can think of taking the default profile, and changing it by
> applying a setting, or a configuration.  This would imply, of course,
> that a setting can affect multiple properties, which is a little bit
> strange.  But I don't think there is an issue with a configuration
> affecting multiple properties.

That looks promising. I think property set plus configuration would
also work? I don't think I would want to replace "property set" with
"profile" because the former really tells it like it is. There's no
need to clarify the meaning.

And if I implement the selection as an optional symbol? argument the
*user* of such a function doesn't have to write "configuration".

> It would be nice to use "style", to be consistent with CSS.  But that
> breaks down because we have a style property for lines and
> noteheads.  And this seems like a little bit too narrow a concept to
> use the word "stylesheet".

Indeed. Anything relating to "style" is too narrowly hinting at visual
appearance, which is not necessarily the case.

> Running through a thesaurus, I came across the word "trait".  
> I'm not sure I like it yet, but I think it's better than "style" or
> "override".  And probably better than "preset" .  But I'm not opposed
> to using "preset" if nothing else is proposed that jumps out at you.

I'll have to ponder over that a bit. It's just too unfamiliar (at least
for me). But OTOH that ensures it won't conflict with anything we
already have.

> "quality" is also a possibility.

I don't particularly like that - it's too general and doesn't hint in
the right direction. 

> With a nod to particle physics, we might want to consider the word
> "flavor", which is used to distinguish particles such as quarks as a
> collection of properties.  

That might be nice. I can imagine having different "flavors" of a
frame, for example.


Thanks again for all the input. I won't have time to actually *do*
anything about it today and tomorrow, so I'll let it sink in or digest
any additional suggestions that may come in.
My favourites so far are "configuration" and "flavor".

BestUrs


Am Sonntag, den 12.07.2020, 15:38 +0200 schrieb Urs Liska:
> Hi all,
> 
> I'm writing some documentation for the new openLilyLib feature set of
> properties, and I think this is the (last) moment to clarify some of
> the naming.
> 
> I have implemented the concept of a set of properties, which is a
> place
> to store typed variables. I'm pretty confident that the terms
> "property" and "property set" are appropriate. To demonstrate:
> 
> \definePropertySet my-function.appearance
> #`((thickness ,number? 1)
>    (color ,color? ,red)
>    (label ,markup? "")
>    (extra-width ,number-pair? (0 . 0))
>    (Y-position ,integer? 0))
> 
> This defines the set of properties applicable for my-function, along
> with type predicates and default values.
> 
> Property values can (if necessary) be retrieved with
>   \getProperty my-function.appearance.label
> and changed with
>   \setProperty my-function.appearance.color #green
>   \setProperty my-function.appearance.color "blue" % fails type check
> 
> The actual use of properties is from within functions:
> 
> myFunction =
> #(with-property-set define-music-function (mus)(ly:music?)
>   '(my-function appearance)
>   #{
>     \once \override NoteHead.color = #(property 'color)
>     #mus
>   #})
> 
> Within a function created with the with-property-set macro a function
> (property <key>) is available to produce the current value of the
> property (which can be the currently set global value or a value
> passed
> in the function
> 
> {
>   \myFunction c' % => (property 'color) => red
>   \setProperty my-function.appearance.color #blue
>   \myFunction c' % => (property 'color) => blue
>   \myFunction \with { color = #green } c' % => (property 'color) =>
> #green
> }
> 
> ###
> 
> So far I'm pretty sure property and property set is the right naming.
> However, there's one more step, and here I have been suggested to
> reconsider the naming.
> 
> Properties can not only be changed globally or per instance but also
> through something I so far call "presets". Alternative suggestions
> for
> that concept were "contexts" or "environment", but I'm really not
> convinced about them. So I'm looking for either common support for
> either name or a better suggestion.
> 
> A "preset" is a subset of a property set with individual property
> values. When invoking the function a preset can be requested while
> properties not included in the preset are left unchanged. Presets can
> inherit to create cascading structures.
> 
> \definePreset \with {
>   thickness = 3
>   Y-position = 2
> } my-function.appearance default
> 
> \definePreset \with {
>   parent = default
>   color = #green
> } my-function.appearance style-one
> 
> \definePreset \with {
>   parent = default
>   color = #magenta
> } my-function.appearance style-two
> 
> Using it the properties included in the preset are used while others
> keep the current global value. Additionally arbitrary properties can
> be
> overridden locally:
> 
> {
>   \myFunction \with {
>     preset = style-two
>     label = "Foo"
>     thickness = 2 % properties from presets can be overridden too
>   } c'
> }
> 
> ###
> 
> So, to cut a long story short: What do you think this "is", i.e this
> should be named: presets, contexts, environments, something else? If
> you should think about styles, this has been discussed before, but a
> property set isn't necessarily limited to matters of appearance, it
> could configure arbitrary things, e.g. export target, lyrics
> language,
> composition algorithm parameters, anything.
> 
> Actually I'd prefer one of two answers: A confirmation that I'm good
> to
> go with "preset", or a better suggestion that is so striking that I
> can
> immediately go with it.
> 
> Thanks
> Urs
> 
>