But for primitive types and wildcards, it does nothing, as an example. And for array types the set does not include, say, Cloneable, so even your description isn’t quite right. And all of this is fine, I guess, but it sure would be nice to get its contract right. Often I find that doing that work properly leads to further questions, like OK, why *does* it work this way? Should it work this way? Would this method be better and even more useful in more general situations if it actually implemented the JLS transitive and reflexive direct supertype relation? And so on. I’ll see what I can do.

On Wed, Aug 21, 2024 at 10:31 AM Matej Novotny <manovotn@redhat.com> wrote:
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@gmail.com> 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@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@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@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; ) so maybe its contract could be updated.

On Tue, Aug 20, 2024 at 4:52 AM Matej Novotny <manovotn@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
___________________________________________________________

On Fri, Aug 16, 2024 at 12:58 AM Laird Nelson <ljnelson@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@lists.jboss.org
To unsubscribe send an email to weld-dev-leave@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/PP2NMVQS6NIZCFMLH7DLGB34GNRQONM3/
_______________________________________________
weld-dev mailing list -- weld-dev@lists.jboss.org
To unsubscribe send an email to weld-dev-leave@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/4TGIZV5TIX5GNCSE5PMRB3S7JPDUCJ5L/
_______________________________________________
weld-dev mailing list -- weld-dev@lists.jboss.org
To unsubscribe send an email to weld-dev-leave@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/5L7Q6FOC4LLGFF4REBVJT6HRRB4JIEDD/