[weld-dev] Re: HierarchyDiscovery questions

Right, a "type closure" is a bad term here; it builds an internal representation of a set of types that you construct from a given Type parameter by scanning its hierarchy of superclasses and interfaces they implement. Furthermore, for a given type, it creates and memorizes a TypeResolver, as well as mapping of type variables to types, which can be used to resolve type parameters (which is used in obs/event setup). A PR is definitely welcome! On Wed, Aug 21, 2024 at 6:02 PM Laird Nelson <ljnelson(a)gmail.com&gt; wrote: > 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&gt; 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&gt; >> 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&gt; >>> 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&gt; >>>> 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&gt; >>>>> 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... >>> >>