6:12 p.m.
I get that and I agree that the syntax is more concise. However I don't
like that it doesn't integrate with the syntax parsing of expressions
themselves (this can lead to unexpected interactions), and I also don't
like that it is different from the way that expressions normally function
with respect to the fact that property expressions generally resolve based
on locally-available information. The syntax really makes one think that
it's something happening at the property expression parsing level. I'd
expect something like `${foo.bar?}` to have a behavior based only
on aspects of the `foo.bar` expression itself; to have it default to some
non-local value based on the *context* of the expression is really pretty
unexpected in my opinion. Especially strange would be if I had an
expression like "${foo.bar?}baz" and the default value for the property
gets put in; at least if I have "${foo.bar:${default}}baz" or even
"${default}baz", I can understand what's happening a little more clearly
(i.e. that it's a concatenation and nothing more, not some kind of operator
or something).
Having a reserved property name for the default value not only integrates
cleanly with the expression parser, but it's also something that we could
potentially carry over to Quarkus, SmallRye Config, or other tools which
use expressions for configuration.
On Fri, Sep 10, 2021 at 11:00 AM Michal Petrov <mpetrov(a)redhat.com> wrote:
Well I guess we can either have a custom syntax for the optional
expression or a custom syntax (reserved string) for the default value, I
went with an option that is more concise.
On Thu, Sep 9, 2021 at 2:50 PM David Lloyd <david.lloyd(a)redhat.com> wrote:
> Yes that would be a problem. Mainly I'm trying to think of an
> alternative solution that doesn't involve a custom syntax though. Maybe a
> special variable called "default" could be used e.g.
> `${foo.bar:${default}}`? Is that too convoluted?
>
> On Thu, Sep 9, 2021 at 6:23 AM Michal Petrov <mpetrov(a)redhat.com> wrote:
>
>> It's not, the attribute definition method would still have to be
>> changed. But it would no longer be possible to set the attribute value to
>> an empty string using this expression, isn't that a problem?
>>
>> On Tue, Sep 7, 2021 at 6:55 PM David Lloyd <david.lloyd(a)redhat.com>
>> wrote:
>>
>>> I think the proposed functionality should already mostly be present, as
>>> you can supply an empty default value. For example "${foo.bar:}"
will not
>>> throw an exception if `foo.bar` is missing but rather return an empty
>>> string. Is an empty string sufficient to yield the default value of an
>>> attribute?
>>>
>>> On Tue, Sep 7, 2021 at 11:32 AM Michal Petrov <mpetrov(a)redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm looking for feedback on my issue -
>>>> https://issues.redhat.com/browse/WFCORE-5339, analysis document at
>>>> https://github.com/wildfly/wildfly-proposals/pull/423
>>>>
>>>> Thanks,
>>>> Michal
>>>> _______________________________________________
>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
>>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>>
>>>
>>> --
>>> - DML • he/him
>>>
>>
>
> --
> - DML • he/him
>
--
- DML • he/him