10:26 a.m.
Once again, please post questions like these to weld-dev mailing list.
To answer you, I think both of the predicates would be illegal bean types.
It doesn't matter if you actually "hide" the wildcard inside another
parameter type.
Whole type is checked in the end and if you stumble on a wildcard, it should become
illegal bean type.
Matej
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Sent: Tuesday, May 26, 2020 6:16:04 PM
Subject: Legal bean type question
Hello; I had a legal bean type question.
Section 2.2.1 says
<https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#legal_bean_ty...
:
"A parameterized type that *contains* a wildcard type parameter is not a
legal bean type."
I understand that therefore this is not a legal bean type:
Predicate<? super String> // oops, Predicate is parameterized with a
wildcard
Does "contains" also mean that *this* is not a legal bean type:
Predicate<List<? extends String>> // hmm; does Predicate "contain"
?
extends String
…? Note that the parameterized type's type parameter is not itself a
wildcard.
Best,
Laird
2:57 p.m.
New subject: Legal bean type question
On Wed, May 27, 2020 at 1:27 AM Matej Novotny <manovotn(a)redhat.com> wrote:
Once again, please post questions like these to weld-dev mailing
list.
Fair. Thanks for answering.
To answer you, I think both of the predicates would be illegal bean
types.
It doesn't matter if you actually "hide" the wildcard inside another
parameter type.
OK, so "contains" truly means "contains": as the type is navigated,
any
occurrence of a wildcard encountered is illegal, no matter how "deep".
And this is because why, exactly? I'm sure there's a reason; my slow brain
is just not seeing it this morning.
Best,
Laird
4:08 p.m.
New subject: Legal bean type question
Well, I wasn't there when it was written in stone, but if I were to guess, it's
because of bean assignability.
You could get some unexpected results with wildcard, and the current assignability rules
surely wouldn't be able to cover that.
For instance, I am not sure you could reliably identify the types of your bean with
wildcard in it.
And then there is matching against injection point which also has a wildcard, you could
have a bean Foo<?> and an injection point that states @Inject
Foo<List<?>>
Would those two actually match? Technically, the wildcard can become List<?>, but it
also seems risky because the bean might in fact (the impl you get) be Foo<Integer>
and then it explodes.
I might be blabbering but at first look, I'd say something along those lines might be
the reason. Feel free to disagree :)
Matej
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "weld-dev" <weld-dev(a)lists.jboss.org>
Sent: Wednesday, May 27, 2020 2:57:25 PM
Subject: Re: [weld-dev] Legal bean type question
On Wed, May 27, 2020 at 1:27 AM Matej Novotny < manovotn(a)redhat.com > wrote:
Once again, please post questions like these to weld-dev mailing list.
Fair. Thanks for answering.
To answer you, I think both of the predicates would be illegal bean types.
It doesn't matter if you actually "hide" the wildcard inside another
parameter type.
OK, so "contains" truly means "contains": as the type is navigated,
any
occurrence of a wildcard encountered is illegal, no matter how "deep".
And this is because why, exactly? I'm sure there's a reason; my slow brain is
just not seeing it this morning.
Best,
Laird
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
4:58 p.m.
New subject: Legal bean type question
On Wed, May 27, 2020 at 7:08 AM Matej Novotny <manovotn(a)redhat.com> wrote:
Well, I wasn't there when it was written in stone, but if I were
to guess,
it's because of bean assignability.
Right. I'm less concerned with a bean whose type is, say, List<?>: that
seems problematic immediately.
The part I'm having trouble seeing—and it is definitely my problem, I'm
sure, not the spec's—is something like List<Comparable<?>>. Which
assignment scenario is made difficult or impossible if this were
permitted? I'm sure there is a reason this is being prohibited; I am just
slow. If it's the same case as List<?> then I'm missing why.
Best,
Laird
11:23 a.m.
New subject: Legal bean type question
Hmm, I don't know honestly. Might be interesting to bring this up in some CDI list
discussion.
Maybe if you imagine any such type with wildcard hidden "deeper inside" as a
collection.
So, take something like `List<List<?>>` - you still have no idea what the
inner list actually holds.
With this you still don't know if it is a valid bean for IP of type
`List<List<Integer>>` or `List<List<String>>`?
Regards
Matej
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Cc: "weld-dev" <weld-dev(a)lists.jboss.org>
Sent: Wednesday, May 27, 2020 4:58:13 PM
Subject: Re: [weld-dev] Legal bean type question
On Wed, May 27, 2020 at 7:08 AM Matej Novotny <manovotn(a)redhat.com> wrote:
> Well, I wasn't there when it was written in stone, but if I were to guess,
> it's because of bean assignability.
>
Right. I'm less concerned with a bean whose type is, say, List<?>: that
seems problematic immediately.
The part I'm having trouble seeing—and it is definitely my problem, I'm
sure, not the spec's—is something like List<Comparable<?>>. Which
assignment scenario is made difficult or impossible if this were
permitted? I'm sure there is a reason this is being prohibited; I am just
slow. If it's the same case as List<?> then I'm missing why.
Best,
Laird
1683
days inactive
1684
days old
4 comments
2 participants
participants (2)
-
Laird Nelson -
Matej Novotny