On 08/09/11 12:03, Pete Muir wrote:
> On 9 Aug 2011, at 18:02, Kin-man Chung wrote:
>
>
>> I recall that it is a CDI requirement that bean names can have namespaces, such as "org.goofy.configs". Pete, is this still the case?
>>
> Yes. This is in the CDI spec, so can't be removed right away, we need to support this for at least the next revision.
>
>
I am curious about how it got in the CDI spec in the first place? It is
just a little strange that CDI can write into its spec about some
functionalities in another spec that is currently not supported, to say
the least.
>> Are there any other things that EL needs to do, other than the ability to parse and evaluates it?
>>
> No.
>
>
>> Since names that contains a "." creates ambiguities are parse time, we'll need to resolve it. I propose that we introduce another syntax notation for it, like what we did for static fields. For instance, we can write
>>
>> #{N(org.goofy.configs).memSize}.
>>
>> to denote the bean org.goofy.configs with the property memSize. What do you think?
>>
> This wouldn't work for CDI due to backwards compatibility.
>
>
What backwards compatibility? It is not working currently! Did you
really got it to work with EL 2.2? How?
What I like about the N() notation is that it is easy on the parser as
well as on the user. It provides a visual indication about what the
expression does. In general, it is just not a good language design to
contain ambiguities that cannot be easily resolved.
> Instead (or as well?), could we offer a registerNamespace() method (similar to how we are handling imports)? Then EL will have a static list of namespaces that an (optional?) namespace resolver could resolve against before other resolvers are used. CDI knows namespaces at startup so could register all it needs.
>
> WDYT?
If we have to support it without any syntax aid, we'll need to have
something like registerNamespace(). I am not sure how and when the
information can be best used. Ideally, we'd like to be able to
recognize the namespaces early, at parse time, so that we don't need to
change how it works at evaluation, so ELResolvers may not be the right
solution. Even at the parse time, it'll require either a deep
look-ahead or backtracking. Also, a simple typo can produce errors that
are hard to track down.
Can CDI deprecate the current namespace support in favor of the N()
notation? Can CDI implementation provides a tools to turn
#{org.goofy.configs.memSize} into #{N(org.goofy.configs).memSize}?
Kin-man