The question isn’t can it be. The question is, should it be. At this point I don’t see why it should. It is necessary in 3.0 to accomplish some of the things we want to do there. But at this point I don’t think we should be doing major things to 2.x.
Ralph > On Apr 16, 2022, at 11:31 PM, Matt Sicker <boa...@gmail.com> wrote: > > Features only available in DI have been asked about in a couple different > situations already in 2.x development. I don’t plan on porting _all_ the > changes I made in 3.x (such as the various startup optimizations, removal of > deprecated code, and making all the existing system property based classes > injectable), though I was hoping to at least enable some of the DI > functionality for 2.18.0 as it should also make it a little easier to > continue maintaining 2.x once we start making 3.x releases. > > I’ll open a PR with the general core of what I can port over without the > deeper refactoring that was done in 3.x. Most of the relevant code here can > be copied directly from master into this branch along with some updates to > AbstractConfiguration. > — > Matt Sicker > >> On Apr 16, 2022, at 15:20, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> A) Why? >> B) I am not really a fan of this. I’d prefer to leave this major of a change >> for 3.0 unless there is a very compelling reason to do it sooner. I’d prefer >> to focus on getting 3.0 out sooner. >> >> Ralph >> >>> On Apr 16, 2022, at 7:14 PM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> Hey all, I’m considering porting the new DI system back to 2.x (but put all >>> in core as there’s no plugins module there) as there seems to be interest >>> in using this earlier than in 3.0. While I’d be willing to do this, I >>> wanted to see what anyone else thinks about the idea. I’d likely begin on a >>> branch or fork, so it’d be nice to get another 2.17.x release out before I >>> merged anything about this. >>> >>> Only real disadvantage of doing this is that the packages move around a >>> little in 3.x, so I’ll have to add more duplicate annotations in 3.x >>> afterwards to maintain compatibility. Although maybe I can start using the >>> plugins package inside core in 2.x so it’s the same package name as in 3.x. >>> >>> — >>> Matt Sicker >> >
