Hi Harbs, 2018-05-10 20:44 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> Hi Carlos, > > I’d like to be clear about one thing: > > I have had my app break *many* times while we’ve been developing Royale > and changing things. That’s OK. That’s part of the cost of working on the > bleeding edge. I’m fine adjusting things to invest in improving our > framework. > > I only have trouble if the changes are not warranted. I’m not convinced > that these changes were warranted. We also agreed about a half a year ago > that all breaking changes should be done in a feature branch. That’s > something we’ve been pretty good at in general lately. We all agree that it > was a mistake to make these changes on the develop branch, but mistakes > happen and and let’s work with that. > If you see the I really did a feature branch...only that it was only one commit and then merged. then I did one commit more for a thing I forget, and then I was fixing things you and others say. > > Instead of pointing fingers, let’s try to focus on the technical reasons > for refactoring and figuring out how and where refactoring should be done > (if at all). If a refactor breaks my app(s), I’ll deal with it. But, let’s > please first come to an agreement on what is best to do on technical merit. > > but I expressed largely about the technical merit, for 90 emails in this thread. You talk about this philosophic and I pointed you many tangible technical reasons, and in opposite, you only give me philosophical reason on your part... > I’m making an effort to be quiet now to get input from others. I think > I’ve already said pretty much what I’ve had to say. > I spent all the they with this, and I'm really upset on how my work is saw... > > If you want my response on specific points, please let me know and I’ll > respond to them. > > Thanks, > Harbs > > > On May 10, 2018, at 9:01 PM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > Hi Alex, > > > > 2018-05-10 18:50 GMT+02:00 Alex Harui <aha...@adobe.com.invalid <mailto: > aha...@adobe.com.invalid>>: > > > >> Wow! Good thing I slept through this... > >> > >> Let's try to calm things down a bit. I think we have agreement that > this > >> work should have been handled differently, but I really think this > >> disagreement, like many disagreements is being escalated by poor > >> communication. Sometimes it is hard to realize that you haven't really > >> explained yourself well. You know the problem so well, and are probably > >> trying to write a shorter email and/or have limited time to write, but > it > >> makes things worse instead of better. > >> > > > > I don't really think communication was bad. I'm in this project and > FlexJS > > form its beginning and I think I follow it always and I think my thinking > > about what is basic was right. My opinion about this refactor, is that > > maybe I did huge commit and for such commit I should be done some > > emailing, but other time we all commit without asking, so while it would > be > > better, really I didn't do nothing bad, but maybe wanting to make this > > project advance as fast as possible. > > > > Then as a refactor like this suppose changes in applications that use the > > framework, Harbs instead of think in the positive thing of remove > > dependencies between libraries, was worried about his application not > > compiling. And here we are 86 emails asserting that we are not > > understanding right the essence of Core and Basic. And what I think is > that > > team mates here instead of work for continue moving things to make this > > project progress are trying to divert the attention talking about > > philosophical point of view, and I think the refactor gets technical > things > > done clearly (separation and less size), while the philosophical seems > more > > to me in stay in what we had and not wanting to move due to applications > > breaking. I'll understand that position with a framework more finished, > but > > in a 0.9.3 version, I think we have room, and we discussed a lot of this > in > > the past weeks, but I think many of the people not agreeing was the same > > that didn't follow that discussion and now they think all this is wrong, > > again due to personal interests. > > > > As I did the refactor I was very close to the email to see if something > was > > broken, since although maven was ok in all aspect, I though something > more > > could be happen, and as you all see I was hard working to fix things as > > people let me know. But what I think is a bad practice in a project is > > talking about revert unilaterally a huge work that had many hours behind, > > since I'll never dare to propose something like this. Moreover when we > all > > can have all the things we want at the same time. Or I don't see any > > overlapping interest here. > > > > > > > >> > >> So, couple of things to consider (actually more than a couple of > things): > >> > >> -I still think we are missing a clear, detailed, technical analysis of > the > >> claim of less code linked in by not having a dependency on Basic. For > >> sure, if you subclass a Basic component, you will get many more things > >> linked in, but I hope that using a bead from Basic does not result in > lots > >> of additional unused classes. If it does, that is probably worth > fixing. > >> Carlos, since this is your claim, please provide the data. Include a > bead > >> from Basic and tell us what additional classes were added. > >> > > > > Alex, I didn't say that a bead from Basic will link additional classes, > > what I say is that linking Basic was inserting 40% of more size, while > apps > > work the same. Let me first ask about what's the point on doing this? I > > have clear that Jewel doesn't need to depend on Basic since cover the > same > > things, since for me both are UI sets, only that Basic was the library > more > > developed since until now was the focus. For me what Harbs call "building > > blocks" are what a UI Set needs to have. > > > > > >> > >> -With composition, a tree/hierarchy of classes becomes much less > >> important. You should be able to mix and match beads from different > SWCs > >> if they conform to expected interface contracts. Those > >> contracts/interfaces, and a few base implementations of those contracts > are > >> what is supposed to go in Core (and in the ".core." package. But the > beads > >> can go where it organizationally makes sense and it does not make a bead > >> "Core" by having some other SWC us it. Basic beads are supposedly the > >> simplest versions that work cross-platform. > >> > > > > for example in Basic a concrete bead can add an attribute to a Basic > > Component. In Jewel the same bead can solve the problem adding a class to > > the positioner. For that reason, normaly Jewel needs its own ecosystem. I > > already worked many weeks (and before many months when creating MDL) and > > have the experience that others doesn't have here to know the problems I > > found, and remember that we discussed some weeks ago about if Jewel will > be > > better subclassing UIBase instead its counter part control or component > in > > Basic, and then my conclusion in that thread was that it was better to > > subclass UIBase. > > > > Antoher thing is that I don't want a future change in a control in Basic > > could introduce a bad behavior in Jewel. For this reason I think the > basic > > building block or Core is UIBase. > > > > > > > >> > >> -If you need to extend a bead, subclassing or utility functions are > >> preferred in order to reduce maintenance overhead of having copies of > code. > >> > > > > I subías core things (like GroupView that before was in Basic) or > > implemente core interfaces (IBeadView), I think that's core, but I don't > > believe in subclass final functionality (control, component, bead or > > whatever) since as final implementations, can change over time and break > > Jewel functionality. For me that's not a good practice. > > > > > >> > >> -I still think we are missing a clear, detailed, example of a Jewel bead > >> that is a different implementation of a Basic bead that required copying > >> code from the Basic bead. > >> > >> > > As UI Sets are siblings and they are not related anymore, If I start > > copying a code from Basic to start, I think is the good way to go > although > > finaly the class remains with the same code. Think that Jewel would never > > link Basic, so there's no other way to have that functionality than > create > > is own. > > > > > >> -A good teammate tries to maximize his/her positive impact on the rest > of > >> the team, and minimize the negative impact, and cares less about > personal > >> goals. > >> > > > > That was my code of conduct until I saw people in this team with the > > opinion that they can dictate the things to do and revert a complete > work. > > Or talk about that I should move from the project and fork it. Just when > I > > think this year I'm donating all my time to this project while the people > > proposing that are only appearing from time to time. I never saw that in > > any other project and I think we are repeating things of the past we > other > > now gone mates. So maybe we should think about why people abandone this > > project or we want ro remove them. If I'm a bit upset I think I have > > complete valid reasons. > > So in the first emails of this thread, I was working hard to understand > > problems arise, and working hard to solve them. But what I see is people > > not only not helping to fix builds or fix the points that could be having > > problems, but discussing if my way of thinking about the new Jewel UI Set > > is right or wrong, while I only want to isolate from other libraries. > Those > > people should not opposite that and only left Royale can do that since is > > beneficial to the project and since from now on, we will see less > problems > > with shared resources (another thing is if shared resources makes people > > discuss many times, maybe should not be shared ) > > > > > >> > >> So, let's get some real data, and see if we can reach agreement on the > >> semantics of what Core is. Then we can discuss how we'd reorganize the > >> SWCs. > >> > > > > Alex, IMHO, I think we should: > > > > 1.- Fix JSONLY, I don't know why is falling, don't know how I can build > > that localy with maven. If you give some clues on this I can work on fix > > that. > > 2.- With all fixed, we can think more about what goes in Core and what in > > Basic. My only point is that Jewel doesn't have to depend on Basic. > > > > I think we need 1. fixed ASAP, since I think Harbs App maybe depends on > > that (don't know if he is using maven build or what, but for what I see > he > > can not build or maybe is ANT failing, I think we need to catch those > > deficiencies in the build since are more important that change classes > from > > a library to another) ...and then 2. can be do it in a more relaxed way > > since all people will have the current build fixed (JSONLY, since the > > normal works) > > > > Thanks > > > > > >> > >> Thanks, > >> -Alex > >> > >> > >> On 5/10/18, 7:09 AM, "carlos.rov...@gmail.com on behalf of Carlos > >> Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > >> wrote: > >> > >> 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 > >>>>>>>> https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. > >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% > >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Carlos Rovira > >>>>>> https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. > >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% > >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0> < > >>> https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. > >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% > >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0>> > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Carlos Rovira > >>>> https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0 <https://na01.safelinks. > >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% > >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0> > >>> > >> > >> > >> > >> -- > >> Carlos Rovira > >> https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636615581733737384&sdata=%2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ > >> xBeR27Le1U3toE%3D&reserved=0 > >> > >> > >> > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira <http://about.me/carlosrovira> > -- Carlos Rovira http://about.me/carlosrovira
