Hi Carlos, Thank you for summarizing your reasons. I appreciate it.
Please allow me to categorize your reasons. Please let me know if I’m not categorizing them correctly. When I mentioned reason #1, I think it includes: #3, #5 and #7 #2 AFAICT includes #4. As I mentioned the fact that there can be conflicting typenames is a problem. Removing Basic as a dependency will not solve that problem because clients can (and likely will) bring in Basic as part of their application. I really don’t understand your point with #6. Why do application developers need to think about dependencies? Is it because of Maven dependencies? If so, that seems to be a Maven problem which should be fixed there. Please explain why you think $8 is true. What about the refactoring will reduce the size of applications? As I mentioned earlier, Basic is not simply a component set. It’s also a set of building-blocks which can and should be used in other component sets. Devision between Core and Basic is not as clear-cut as you seem to be asserting that it is. After your refactor the building blocks seem to be split between Core and Basic. Thanks, Harbs > On May 10, 2018, at 2:13 PM, Carlos Rovira <carlosrov...@apache.org> wrote: > > Hi Harbs > > after 75 emails on this thread, understand that I don't want to again write > it, since this is making me waste lots of time in this discussion. > > 3) Having the need to link a library that should not be used, is that > something is wrong, so it's not about 1) it's about things are not setting > correctly, and this refactor tries to fix that at least to put a point in > wich we can make things better. > 4) aside 2, some classes are linked via CSS as well (Application, Group, > Container, Button, Slider, and many more > 5) Having Basic to be a core dependency, makes it Core in itself, so why > the separation Core- Basic if I'm obligated to link it? > 6) Making Basic not present in libraries that doesn't need it, makes people > obligated by design to avoid extend Basic classes making the effect but > time that things mess between libraries, and obligates SDK developers to > think about the using of classes, since if we need some, maybe that will be > Core and not Basic > 7) Basic is only another UI set at the same level or sibling like Jewel, > MDL, CreateJS, Flat, and more we want to do, until now was very needed, but > if we want to make Royale to serve general purpose, making it to be present > always is not the right way to go. > 8) reduced size in final jewel applications. > > I think for sure I put more things on the plate, but can't invest now the > time to go all 75 emails to retrieve it > > > > 2018-05-10 12:48 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >> The only reasons I seem to have seen are: >> 1. A philosophical opposition to having Basic as a dependency. >> 2. Not wanting Basic CSS included in a Jewel project. >> >> Unless I’m missing something, #1 I simply disagree with. >> #2 sounds like a valid argument, but it seems to me more like something >> which needs to be fixed in the compiler. CSS not used by an app should not >> be included and I think we need a way of avoiding typename conflicts >> between component sets. >> >> Are there other arguments which I missed? >> >> Since Carlos does not seem to want to explain himself again, I’m asking >> others on the list: >> >> Do others understand why Carlos feels the refactor is important? >> >> Thanks, >> Harbs >> >>> On May 10, 2018, at 1:32 PM, Carlos Rovira <carlosrov...@apache.org> >> wrote: >>> >>>> Can we please keep this discussion about the technical reasons for a >>>> refactor and whether or not it’s the right thing to do? If you have >> strong >>>> technical reasons why Basic should not be a dependency please explain >> them. >>>> >>> >>> Harbs, I'll explained lots of time, and you keep ask the same. What did >> you >>> not understand of the things I expressed so many time? >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
