Top posting to make it easier on the eyes: > For me 3,5,7 are not something about "philosophy", are pure technical > structuration of code. If you want to left as is, is because you're talking > from an Application ser not from an archictecture point of view or with the > team member hat.
Maybe philosophical was not the best word, but my point remains. Your arguments are centered around the fact that you believe Basic to be a component set similar to Jewel. Others have been disagreeing with this point of view. I have been working on the assumption that Core is really bare-bones functionality which is not directly related to any specific way of implementing anything. Basic is “core” in the same way that DataBinding, Network Collection, etc. is “core”. The assumption is that almost all applications - no matter which component set is being used will require Basic. To me, Basic means “basic functionality” and not “basic components”. Maybe it was a mistake to have Basic include Components at all because that’s what seems to be causing the disconnect here. I don’t think it’s practical or desirable to move all the “core” pieces of Basic to Core. >> #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. >> > > There's much difference in obligation to link a library and decision to > make part of your solution. We as Royale PMCs should make the best for not > obligate, the user is how could want then to use Jewel, MDL and Basic all > together. Is up to them. I’m not sure what you are trying to say here. My point is that an application bringing in Basic should not cause Jewel components to break. I assume you’d agree with me on that. >> 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. >> > > Not App developers, We are how need to be careful on this. In the same way > we are pushing hard on PAYG, to avoid mistake of the past like 15k lines > UIComponent class, We need to always be careful and don't make unneeded > relations. And Basic -Jewel is totally unneeded. Well, Basic *was* needed before you made your changes and the assumption is that it usually *will* be needed because it’s the basic building blocks of applications. Moving things to Core as component sets need them seems like a bad thing to do. Why do we need to be careful about including Basic? This seems more like a philosophical argument than a technical one. >> >> Please explain why you think $8 is true. What about the refactoring will >> reduce the size of applications? >> > > I explained just in a Yshay response. copying the entire email response > here. But rather to make me repeat or copy I though you read all this > thread carefully: OK. So this goes back to the CSS. I thought you were talking about code. I already agreed with you that unnecessary copying of CSS is bad. I just think it’s something which should be solved in the compiler. Can you think of a reason why it can’t/shouldn’t be a compiler problem? Thanks, Harbs > On May 10, 2018, at 3:02 PM, Carlos Rovira <carlosrov...@apache.org> wrote: > > 2018-05-10 13:41 GMT+02:00 Harbs <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>>: > >> 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 >> > > For me 3,5,7 are not something about "philosophy", are pure technical > structuration of code. If you want to left as is, is because you're talking > from an Application ser not from an archictecture point of view or with the > team member hat. > > >> >> #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. >> > > There's much difference in obligation to link a library and decision to > make part of your solution. We as Royale PMCs should make the best for not > obligate, the user is how could want then to use Jewel, MDL and Basic all > together. Is up to them. > > >> >> 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. >> > > Not App developers, We are how need to be careful on this. In the same way > we are pushing hard on PAYG, to avoid mistake of the past like 15k lines > UIComponent class, We need to always be careful and don't make unneeded > relations. And Basic -Jewel is totally unneeded. > > >> >> Please explain why you think $8 is true. What about the refactoring will >> reduce the size of applications? >> > > I explained just in a Yshay response. copying the entire email response > here. But rather to make me repeat or copy I though you read all this > thread carefully: > > "I think the problem is that Basic UI set links things through CSS, so If I > have Application, Group, View, Button all this components and more has CSS > that links beads (ViewBeads, ModelBeads, ControllerBeads, and more) > > In Jewel until the refactor the components where sublcassing Basic ones, > and this made all this classes go in the Jewel Application, and that not > only introduced more size but makes the behaviour unexpected since I find > css styles and linked classes modifying the Jewel Behavior. > > Now that Jewel is not depending on Basic anymore, since it should be, all > works perfect. > > I think this is key, in a tree graph we should envision, Core as the root > of the tree, and when coming to UI sets that in royale we coincide in > having many of them, one should not depend from the other. And by design > that's important, and will prevent people in the future to come back to > make relations between them. In fact Alex, said many times the errors > coming from 15k lines of code in UIComponent in Flex. If we left UI sets > depend at library level, people can start to make that kind of extension, > and that should not be doable by design." > > > >> >> 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. >> > > That's not what I talked in the past in this mailing list. Alex said that > people would want to use Basic for things very basic and more complex UI > sets for other things. In fact Jewel born to be more visual attractive, so > for Jewel, all building block regarding UI should be from itself, and > prevent to mix with things in Basic that will (or could) evolve in other > way. > > My refactor was searching a goal, separation. But as many things can not be > final. After it, we can think a bit more on how things are settle now, and > continue to improve it, to make Core real core, and Basic a UI set that > could be has it's own essence without make it to mix in other libraries > that should not need it. > I think we should continue improving this instead of wanting again to have > a mess between all this libraries and packages mixed in libraries like core > and html. > > But for this to happen, we must focus in why the JSONLY build is different > from the main one, and if ANT fails, that shouldn't, that I'm still don't > know if we have a problem there > > thanks > > > >> >> 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 >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira>
