> On May 13, 2022, at 9:22 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> Le ven. 13 mai 2022 à 16:57, David Blevins <david.blev...@gmail.com> a
> écrit :
> 
>>> On May 12, 2022, at 11:17 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>> 
>>> Hi David,
>>> 
>>> Just had a look and it seems it is mainly about ensuring we'll move
>> master
>>> to 1.3.0-SNAPSHOT (can need a thread at least for visibility)
>> 
>> Good idea.  Created a thread on 1.3 with the motivations so that is
>> documented on list and we can get feedback if any.
>> 
>>> and cleaning
>>> up ExceptionMessages (simpleName impl) then we can move forward I think.
>> 
>> Is there any chance for some flexibility on that method?
>> 
>> My big concern is that if I push back we'll find ourselves in a debate on
>> calling class.getSimpleName() vs using string manipulation and that will
>> come at the expense of time we could spend collaborating on more
>> fun/impactful things.  We're likely another 3 or 4 PRs before we could get
>> the items in the reports addressed and 1.3 out the door.
>> 
> 
> Im fine with current code if there is some enforcement (tests) we dont
> support any other Type cases - thinking it is harder than simplifying the
> impl i proposed it but while we have something simple to grok for all
> supported types i m actually fine.

I really appreciate that.  Class names can get quite strange, hence my 
reticence with any string manipulation approach.

I've updated the PR to handle WildcardType and GenericArrayType and added more 
explicit tests.  As before there is a fallback of calling getTypeName() in case 
we see something unknown.

Let me know if there's a common Type derivative I should add.


-David

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to