Hi Harbs 2018-05-10 15:55 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> Carlos, > > It’s impossible to move the entire Basic (non-components) into Core. > Besides the fact that there’s no reason to inflate Core that much, there’s > many pieces (in beads, renderers, etc.) which rely on things which are > *not* Core. > > Core has 0 dependencies on other projects (except Language — I think). > Many pieces of Basic have dependencies on other pieces such as Collections, > Binding, Network, etc. > > Ideally, the library swcs should be as small as possible. You are > proposing making Core bigger. I oppose that idea. Basic is quite large. I > would support an idea of breaking Basic into smaller pieces although I have > higher priority things on my list personally. > I really prefer to stick like its now and simple fix the JSOnly build. I think is the fastest thing we can do. I was talking about this since you propose to break basic in two. and maybe is not needed at least at this time. If I continue to work on Jewel and find more things that I need from Basic (and that should be basic we can talk about that) > > When Alex and others have been saying that Basic is just another component > set, I believe that was just referring to the components in Basic. The > building blocks in Basic are another story altogether. The vast majority of > Basic is the building blocks and not the components. If folks like the idea > of moving the Basic components into their own swc, that’s something I’d > support. Moving building blocks into Core to prevent dependencies is *not* > something I support. Your refactor is by no means comprehensive and I don’t > want to go down the path of making it so. > but not doing so will left the Jewel project again with the same problems, just because you have a philosophical point of view. Since in this concrete point, mine is technical in its totality. > > You also changed package names and that deserves a separate discussion. If > changing the package names makes things clearer, I’d support that. I’m not > sure that it does. Besides moving things from html to core, you removed > beads from package names. Many pieces still have the html path and there’s > currently no consistency that I can see. > package names can be reverted, I think that's not completely needed. I did to avoid the actual mess of "core" and "html" packages around Basic and Core. My opinion is that Core should have only "core" package and Basic should have only "basic" (and not "core" nor "html") But this is not critical for me, and I can live with it, but this rise one clear thing, that if the build works, you only need to change you Application in a few places where the package changed. And that should be possible so Royale has a better organization of packages. > > My $0.02, > Harbs > > On May 10, 2018, at 4:33 PM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > 2018-05-10 14:30 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com>>: > > > >> 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. > >> > > > > Until now the concept was that Basic was an UI set, and for that reason > > HTML was separated, since was the set of html tags like span, h1-h6, div. > > So Core and Basic words in your understanding wants to refer to the same > > and if what you want to left in Basic is not UI components, then that > seems > > to be Core classes that in fact other sets like Jewel could need, so as I > > said, I think is better to have one single Core library for all that is > > core or basic (in the means of core) > > > > > >> > >> 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. > >> > > > > notice that "basic functionality" can be easily think about it as "core > > functionality", I think we are talking about the same. > > > > > > > >> > >>>> #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 agree that If I link Basic that should not make a difference. > > But the point is that not only makes a difference linking things I don't > > want, but that I'm obligated to link that library, and I shouldn't since > > right now Basic is more than a Core library is a library that has core+ui > > components+css, so that is completely wrong by design. > > > > > >> > >>>> 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. > >> > > > > I found in my refactor that many examples have Basic dependency missing > ( I > > think that can be mainly the problem with JSONLY build failing), that was > > due to HTML pulling Basic. That means that the build was a wrong > > configuration and as HTML left away its Basic dependency projects that > > really need Basic was failing, so I added it specifically. So here > there's > > nothing philosophical, but a problem about structure and organizations. > > > > > >> > >>>> > >>>> 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? > >> > > > > As I said in my explanation to Yishay, before the refactor I was using > the > > "building blocks" in Basic, and that was pulling all dependencies, so as > I > > break Jewel dependency, and remove the dependency from Basic components > and > > building blocks so don't know if there's a compiler problem or not, but > > what I know for sure is that this kind of linkage of unused or not needed > > libraries with the time makes people mix inheritance chains since the > > classes are avaialble and then that caused that kind of dependencies. So > > for me one thing to do to prevent this kind of problems is simply not > link > > the libraries that should not be used > > > > Thanks > > > > Carlos > > > > > > > >> > >> Thanks, > >> Harbs > >> > >>> On May 10, 2018, at 3:02 PM, Carlos Rovira <carlosrov...@apache.org > <mailto:carlosrov...@apache.org>> > >> wrote: > >>> > >>> 2018-05-10 13:41 GMT+02:00 Harbs <harbs.li...@gmail.com <mailto: > harbs.li...@gmail.com> <mailto: > >> 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 > <mailto: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 <mailto: > 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 <mailto: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 <http://about.me/carlosrovira> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Carlos Rovira > >>> http://about.me/carlosrovira <http://about.me/carlosrovira> < > http://about.me/carlosrovira <http://about.me/carlosrovira>> > >> > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira <http://about.me/carlosrovira> > -- Carlos Rovira http://about.me/carlosrovira
