11 a.m.
Or, to put it slightly differently:
- given an individual bean type and an injection point type, there are
rules in the specification about whether they are compatible. (That's nice
but has no bearing here.)
- There are rules in the specification that talk about the unrestricted
set of bean types of a managed bean. That's nice, but the methods here do
not consider whether they are being invoked to work with managed beans or
other kinds of beans, so that can't be what is implemented here.
- There are other rules that talk about the unrestricted set of bean
types of a producer method. Same thing: these methods don't consider
whether they're being invoked to work with producer methods.
- There are still others that talk about the bean types of a producer
field. Ditto.
So the HierarchyDiscovery#discoverTypes method cannot *by itself* represent
the set of types discussed by each set of rules. So it does something else
(useful), which is not in the specification (as far as I can tell, but
which is useful for people trying to implement the specification). It would
be nice to tell exactly what it does without having to read through unit
tests, other methods' documentation, etc. etc. etc.
I will see if I can put together a PR that at least says what the various
methods actually do, whether or not it is what they are supposed to do (or
intended to do).
On Wed, Aug 21, 2024 at 9:05 AM Laird Nelson <ljnelson(a)gmail.com> wrote:
Could you tell me where “type closure” is defined in the CDI
specification, if that’s what this method is vaguely supposed to represent?
It would be nice to add the spec link to this class’ documentation. (A
search for “closure” yields five hits, all of which are method names.)
On Wed, Aug 21, 2024 at 8:22 AM Matej Novotny <manovotn(a)redhat.com> wrote:
> I agree that POSIWID is what holds true here.
> I'd say the main purpose is to identify type closure as per CDI
> specification which will have some differences from the JLS definition for
> sure.
> Note that there is also a subclass of this class
> (SessionBeanHierarchyDiscovery) which further deviates from the description
> to satisfy CDI-EJB integration rules.
> Apart from these EJB-specific rules, I can think of the generics that I
> mentioned earlier and the type normalization which is the static method
> that has quite some javadoc already.
>
>
> On Tue, Aug 20, 2024 at 4:32 PM Laird Nelson <ljnelson(a)gmail.com> wrote:
>
>> Not particularly. I was interested in what this method does, what its
>> legal inputs are, what its error conditions are, etc. (its contract). It
>> implies one thing but does something else or at least does so for certain
>> inputs (which inputs?). I’d like to either change the vague description of
>> what it does, or change the implementation to somehow match the description
>> (I doubt this is desired or possible). It sounds like this method’s
>> contract is what it does (POSIWID;
>> https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does
>> ) so maybe its contract could be updated.
>>
>> On Tue, Aug 20, 2024 at 4:52 AM Matej Novotny <manovotn(a)redhat.com>
>> wrote:
>>
>>> Hello
>>>
>>> I cannot offer you better definition than what's there plus going
>>> through the code/tests that make some assertions.
>>> I suppose you have a specific case/test in mind that doesn't match
>>> expectations? That would be a good starting point for a discussion.
>>> One contested point I can recall from the top of my head was around
>>> indirect supertypes of a raw type[1][2] but I am not sure that's what
>>> you're aiming for.
>>>
>>> Matej
>>> ___________________________________________________________
>>> [1] WARNING: Very long read :)
>>> https://github.com/jakartaee/cdi-tck/issues/429
>>> [2] https://bugs.openjdk.org/browse/JDK-8044366
>>>
>>> On Fri, Aug 16, 2024 at 12:58 AM Laird Nelson <ljnelson(a)gmail.com>
>>> wrote:
>>>
>>>> org.jboss.weld.util.reflection.HierarchyDiscovery's documentation
>>>> reads, in part:
>>>>
>>>> "Utility class that discovers [the] transitive type closure of a
given
>>>>> type."
>>>>
>>>>
>>>> This public class is underspecified. I'd like to pin down exactly
how
>>>> it is underspecified and hopefully help its specification match its
actual
>>>> behavior, or *vice versa*.
>>>>
>>>> My main question is: what is the definition of a "transitive type
>>>> closure" (according to this class)?
>>>>
>>>> (Based on the observed behavior of the class, it is *not* the
>>>> "reflexive and transitive closure over the direct supertype
relation" (JLS
>>>> 4.10).)
>>>>
>>>> Best,
>>>> Laird
>>>>
>>> _______________________________________________
>>>> weld-dev mailing list -- weld-dev(a)lists.jboss.org
>>>> To unsubscribe send an email to weld-dev-leave(a)lists.jboss.org
>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
>>>> List Archives:
>>>>
https://lists.jboss.org/archives/list/weld-dev@lists.jboss.org/message/PP...
>>>>
>>> _______________________________________________
>>> weld-dev mailing list -- weld-dev(a)lists.jboss.org
>>> To unsubscribe send an email to weld-dev-leave(a)lists.jboss.org
>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
>>> List Archives:
>>>
https://lists.jboss.org/archives/list/weld-dev@lists.jboss.org/message/4T...
>>>
>> _______________________________________________
> weld-dev mailing list -- weld-dev(a)lists.jboss.org
> To unsubscribe send an email to weld-dev-leave(a)lists.jboss.org
> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
> List Archives:
>
https://lists.jboss.org/archives/list/weld-dev@lists.jboss.org/message/5L...
>