[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 ☧ ΧΡΙΣΤΟΣ
- Re: Naming RFC: Properties, property sets, presets, (continued)
- Re: Naming RFC: Properties, property sets, presets, Andrew Bernard, 2020/07/12
- Re: Naming RFC: Properties, property sets, presets, Urs Liska, 2020/07/13
- Re: Naming RFC: Properties, property sets, presets, Andrew Bernard, 2020/07/13
- Re: Naming RFC: Properties, property sets, presets, Fr. Samuel Springuel, 2020/07/13
- Message not available
- Re: Naming RFC: Properties, property sets, presets,
Fr. Samuel Springuel <=
Re: Naming RFC: Properties, property sets, presets, Flaming Hakama by Elaine, 2020/07/13
- Re: Naming RFC: Properties, property sets, presets, Urs Liska, 2020/07/13
- Re: Naming RFC: Properties, property sets, presets, Flaming Hakama by Elaine, 2020/07/13
- Re: Naming RFC: Properties, property sets, presets, Urs Liska, 2020/07/14
- Re: Naming RFC: Properties, property sets, presets, Flaming Hakama by Elaine, 2020/07/14
- Re: Naming RFC: Properties, property sets, presets, Flaming Hakama by Elaine, 2020/07/16