ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <>
Subject Re: Ivy 2.5 and generics
Date Sun, 09 Jul 2017 11:27:42 GMT
Hi, I hope you're doing well and not (yet) on vacation :-) I just opened
PR-52, which should conclude large-scale code changes and prepare the field
for more focused discussion regarding the API.


2017-06-20 14:06 GMT+02:00 Gintautas Grigelionis <>:

> I left out the generification of Filter, because NoFilter is a singleton.
> I'll be leaving out attribute Maps (global or local), because their values
> can be Strings or Matchers (this is where the story with IvyDE started, I
> was not sure what to expect from one such Map).
> Anything else that is pretty unambiguous can be generified just to clear
> out the room. Once that is done, the remaining cases must be thoroughly
> discussed. I added binary compatibility checks to stress the point that
> generification does not break binary compatibility as long as erasures stay
> the same.
> Gintas
> 2017-06-20 13:35 GMT+02:00 Jaikiran Pai <>:
>> Gintas, can you list the exact nature of changes for some specific
>> classes that you think this effort might involve? I know you already sent
>> me some samples, but it would be good if the rest know what kind of changes
>> are involved.
>> Personally, my opinion on this is - if it’s internal implementation
>> details that this change involves (like private fields or methods of
>> certain classes), it’s fine to do that in the upcoming release. But if it’s
>> more than that, then IMO, we should hold on to that for a bit and evaluate
>> it in some subsequent release so that we don’t do too many changes without
>> evaluating the kind of impact it has on the external libraries that use Ivy.
>> Ultimately, I believe this will come down to a case-by-case basis.
>> -Jaikiran
>> On 19-Jun-2017, at 10:12 AM, Gintautas Grigelionis <
>>> wrote:
>> During a discussion about goals for Ivy 2.5, I mentioned generics [1].
>> I was looking into the matter because I was investigating how IvyDE hooks
>> into Ivy and I didn't quite like what I saw.
>> I'd like to generify Ivy as much as possible for 2.5 (staying binary
>> compatible, of course) so that decisions for the next release could be
>> more
>> informed.
>> Should you agree, I'd finish the work with two more commits (one for core
>> and one for plugins package) -- I pushed two commits already that ended up
>> in PR #45.
>> Now, I'll digress, but I believe it's worth mentioning. Apart from
>> generics, there's one last thing I'd like to have in Ivy 2.5, and that's
>> SVG in Ivy reports. I only heard one opinion (which was positive) about
>> the
>> non-limbless ant in vectorised Ivy logo, and no protests, so I take it as
>> a
>> silent approval :-) BTW I hope asciidoc can inline SVG in HTML, although
>> some repeating icons would better be placed in CSS (as mentioned in
>> comments to PR #39).
>> [1]
>> /%3CCALVNWHXiZPVJmKimTB9Qxo9u6%2BNX%2Br7Kpmk3uvZvqtUxLQpekQ%
>> Gintas
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message