lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Naming RFC: Properties, property sets, presets


From: Fr. Samuel Springuel
Subject: Re: Naming RFC: Properties, property sets, presets
Date: Mon, 13 Jul 2020 11:31:40 -0400

Reply received off-list.  Copying to list for record:

> On 13 Jul, 2020, at 10:58 AM, Urs Liska <lists@openlilylib.org> wrote:
> 
> Hi Samuel,
> 
> Am Montag, den 13.07.2020, 10:00 -0400 schrieb Fr. Samuel Springuel:
>> So, if I've taken in the whole conversation, then the situation you
>> have is as follows:
> 
> I'd say about 95% (and nothing of the 5% is essential).
> 
>> 
>> 1) property sets define a list of properties and give them default
>> values (so that you never have a valid property without a current
>> value)
> 
> Correct, plus a type predicate.
> 
>> 
>> 2) a “preset” can change the values of properties in a property set,
>> but *cannot create new properties*.  In this case the “preset” is a
>> reusable local definition for the values of the properties in the
>> property set.
> 
> Correct. More specifically: a subset ranging from zero to all
> properties.
> 
>> 
>> 
>> Further your inheritance rules look something like this (where you go
>> down the list until you find a value for the property in question):
>> 
>> 1) local property setting (done in a \with block)
>> 2) value of the property from the named “preset”
>> 3) if the named “preset” has a parent, then the value of the property
>> from the parent
>> 4) recurse #3 on the parent until you run out of parents
>> 5) the default value given to the property when the property set was
>> created
> 
> Correct, except tha in 5) it is the current value of the property,
> either from when the property set was created or to what it has been
> changed with \setProperty.
> 
>> 
>> If you get to the end of the list without finding a value for the
>> property, then you necessarily have an invalid property (i.e. one
>> which has not been defined).
>> 
> 
> That's sort-of true but not what actually happens.
> 
> When \myFunction is called the first thing it does (this is part of the
> with-property-set macro, neither the function's programmer nor the
> function's user see that) is populating an alist with all properties
> from the property set, using the rules you outlined above.
> 
> When code in the function wants to access a property value it calls the
> implicitly created function (property '<property-name>), which looks up
> this flat alist, and raises a warning if the function programmer
> mistakenly asked for an invalid property (so to determine invalid
> properties you don't have that "lookup ladder").
> 
> When a user passes a property in a \with block that is not defined in
> the property set this value is ignored and a warning issued. So here
> also no recursive lookup is done.
> 
> However, from the POV of what we're discussing here you got it
> completely right.
> 
>>> On 13 Jul, 2020, at 1:38 AM, Urs Liska <lists@openlilylib.org>
>>> wrote:
>>> 
>>> My favourites so far are "configuration" and "flavor".
>> 
>> Given the above, I would go with “configuration.”  I also would
>> suggest that “default” be a restricted name which refers exclusively
>> to the set of values given to the properties when the property set is
>> created.  I.e. it should not be possible for the user to define a
>> configuration named “default” because it already exists (it’s defined
>> by \definePropertySet).  Changing the default configuration is only
>> possible using the \setProperty function.  This is syntactically
>> cumbersome, but it serves to emphasize what the values given at the
>> time of a property set’s creation actually are.
> 
> I don't think this is too cumbersome. In fact I had already settled
> with not requesting "presets" as part of a \with block but as an
> optional symbol? argument, and this lends itself pretty good to
> "default" being the default value for that argument.
> 
> This could mean something like this:
> 
> \definePropertyConfiguration \with {
>  color = #(rgb-color 1 .4 .2)
> }  analysis.frames style-one 
> 
> or (actually simpler)
> 
> \definePropertyConfiguration analysis.frames.style-one 
> `#((color .
> ,darkgreen)
>   (thickness . 2))
> 
> and uses like
> 
> % use a property configuration plus local overrides
> \frame style-one \with { y-upper = 12 } c'
> 
> or 
> 
> % use implicit "default" configuration plus local overrides
> \frame style-one \with { y-upper = 12 } c'
> 
> or
> 
> % just use tha current default (original values or modifications)
> \frame { c' d' e' }
> 
> Maybe I'll go with this. In any case: this will be the first time when
> this stuff gets properly documented, at least for now from end-user
> perspective.
> 
> Best
> Urs
> 
>> 
>> ✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝
>> Fr. Samuel, OSB
>> (R. Padraic Springuel)
>> St. Anselm’s Abbey
>> 4501 South Dakota Ave, NE
>> Washington, DC, 20017
>> 202-269-2300
>> (c) 202-853-7036
>> 
>> PAX ☧ ΧΡΙΣΤΟΣ


✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝✝
Fr. Samuel, OSB
(R. Padraic Springuel)
St. Anselm’s Abbey
4501 South Dakota Ave, NE
Washington, DC, 20017
202-269-2300
(c) 202-853-7036

PAX ☧ ΧΡΙΣΤΟΣ




reply via email to

[Prev in Thread] Current Thread [Next in Thread]