LibsBuilder design

[AllanWang]

After migrating to post 7.0.0, I have a lot of questions on the design.

Functions like extracting libs from fields seem to be internal now, and wrapped in LibsBuilder.

While there is a major rewrite, lots of functions within LibsBuilder look like legacy code. Is there a reason to add the with functions when most of the configs are already public and mutable?

Getting the items also seems to be done with adapter(Context), which returns a fast adapter. Why not return the list of models instead? People may already have fast adapter, or may want to attach other items around the adapter. This function adds unnecessary coupling to the root adapter.

[mikepenz]

yeah those with functions are mainly legacy code and face as backwards compatbility tools for java users.

You can also use directly the Libs class to get the data so that cas eis covered

[AllanWang]

I'll take a look again, but I think something was missing that prevented me from updating. I needed a function that takes in the r class and returned the lib models.

[AllanWang]

I guess the question was why it was kept here, whereas in FastAdapter things were fully refactored. As for the data models, Libs does fulfill my needs. For the sake of compatibility I guess there's no need to change it, but I believe returning fast adapter item lists would be better in the future than returning a new fast adapter.