Hi Harbs, ok, I'll try to make a brief list of some of the classes involved so you and others can have a better understanding of how things can be restructured so we get best of both worlds. Hope to make this today.
thanks Carlos 2018-06-02 21:36 GMT+02:00 Harbs <harbs.li...@gmail.com>: > Hi Carlos, > > I think our wires are still crossed. Rather than me trying to address your > points below, I think we still need to work on definitions. Let me try like > this: > > A Jewel dependency on “Foundation” is OK for you, but a dependency on > “Basic” is not. Right? > > In your view, which files in the Basic project make it “Basic” rather than > “Foundation”? Put another way: Which files can we remove from Basic to make > it “Foundation”? > > If we can narrow this down to a list of files which you believe make a > dependency “bad”, I think that focuses the issue a lot better. We don’t > need a full list of files at the moment, but a sampling of the files that > you view as “bad dependencies” would make it much clearer for me (and > others). If you prefer, I could compose a list of files myself, but I’d > like to hear from you what you think. > > Thanks, > Harbs > > > On Jun 1, 2018, at 5:55 PM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > Hi Harbs, > > > > 2018-06-01 13:07 GMT+02:00 Harbs <harbs.li...@gmail.com>: > > > >> > >> We both agree that Jewel should have a dependency on “Foundation” or > >> “Basic”. The only question is TLCs. What practical difference does this > >> point have? > >> > >> > > All thoughts about why not make TLCs and CSS was exposed several times. I > > think you already know what I think about it. Don't think write about it > > one more time have sense. > > I think you don't expose opposite arguments. Maybe this part is in a > field > > dominated by a mixture of technical issues and how each of us likes to > > codify things and for this reason is hard to reach consensus. I believe > > that your vision may be correct, but I personally see more benefits in > > which I am defending. If I must to choose only on arguments or > evidences, I > > think the way I'm proposing should be the way to go. > > > > > > > >>> > >>>> > >>>> I’d like to propose the following way forward. > >>>> > >>>> 1. Both Basic (Foundation) pieces and Basic TLCs should have the same > >>>> package paths and namespaces. > >>>> > >>> > >>> Don't think so. If you want to promote reusable pieces, the refactor of > >>> names should make them go to a different package other than Basic. It's > >>> like to propose to put on a jewel package would be a bad decision. In > the > >>> refactor I was for "core", since the common pieces was in Core. So I > >> think > >>> it will depend on the name of the library to choose. For me Basic is a > >> good > >>> name for Basic UI Set since clearly states what all the code there do. > I > >>> still think Foundation is a good name, but if you don't like, I think > you > >>> should propose other one that seems more appropriate. > >> > >> I really don’t care very much what the project name is. “Base” “Basic” > and > >> “Foundation” are all good. To me they all mean the same thing. > > > > > > I really see a tangible difference between "foundation" pieces to use all > > over other royale parts and "basic" pieces that are the most basic or > base > > representation while express or jewel are more complex and pursue > different > > complex scenarios (so is basic vs complex). > > > > > >> I’d prefer to stick with Basic because I don’t see a gain in renaming > it. > >> Foundation is a “long” name. I don’t see a reason to make the name > longer. > >> I feel very strongly that the TLCs should have the same paths and > >> namespaces as the rest of Basic. > > > > I consider Basic TLCs a part of the Basic concept. Even if Jewel doesn’t > >> end up using it, other component sets likely will. Creating a new > package > >> path and namespace serves no function and makes things more difficult. > Why > >> go there? > >> > > > > ok, for this is not crucial, is only something that the other name like > me > > more and fit for me more, but in this part I'm ok if finaly we need to go > > with "basic". In every negotiation we can't get *all* > > > > > > > >> > >>> > >>>> 2. By doing this, it will be very painless to pull Basic TLCs out of > >> Basic > >>>> into a separate project or merge it back in. (i.e. BasicComponents) > >> (Either > >>>> now, or in the future.) > >>>> > >>> > >>> I think we must be doing it moving little by little and ensuring after > a > >>> little refactor all continues working. > >> > >> Moving what? I don’t think moving the entire list of TLCs (i.e. what is > >> used in the Basic CSS) is more than a few hours of work. > >> > > > > In fact the initial refactor took me 2 days of about 10-12 work hours to > > complete. This will take a time to do it, but it can be done without > > problem with patience and perseverance. > > > >> > >> Basic *is* that shared library. To prevent linking to Basic (TLCs), we > can > >> move the Basic TLCs out of Basic *at any time*. I don’t see why we need > to > >> *do anything* right now (except get everything working for a release). > >> Jewel apps might be slightly larger for a month or two until we get this > >> sorted out, but what’s the rush? > >> > > > > Harbs, I completely disagree with that path. Is to come back to insert > > entropy and bad practices again, or go to backwards. For me this point is > > crucial. Again, we must see what points are very important and for me > this > > is not important, is crucial. Think that if you don't like my path, you > > always can have again Core - Basic, and I should have Core - Foundation - > > Jewel. We will have duplicated code, and will have 2 valid options > living > > together, but I don't see other way. > > > > > >> > >> Just consider Basic “Foundation” and ignore all the TLCs for the time > >> being. If it’s the right thing to move the TLCs out, we can do that > later. > >> > >> > > I think the best path to make us all happy is to set up a new > "foundation" > > or (whatever the name you want) and be moving things there. > > This way, I don't have to link Basic and live 1-2-3 months with the > > problem,and we all can move things little by little without problem. This > > paths makes the same that you want, but without introducing the problem > > again. Can you consider that path? > > > > > >> Because I don’t think that removing the dependency is the right thing to > >> do. Again, whether I’m right or wrong will become clearer as Jewel gets > >> completed. If I’m wrong, I’ll be happy to pull out the Basic TLCs > myself. > >> > > > > But Harbs, I think that we actually can see the benefits. The benefits > are > > exposed now!, you don't have to try anything more to see that is a good > > way. You only need to examine final code in JewelExample, or any other > > example code that uses Jewel and not uses Basic (all blog examples, or > > remote object example), and you'll see that is the proof that the way > works > > better. You didn't see nothing about things like less definitions or > other > > points that I put on the table. And you stick with a way of thinking > that I > > still don't see arguments that make me think that I should use link > Basic, > > and If you want me to link Basic, I understand that you want me to extend > > things in Basic or if is not the case, why you want me to link Basic in > > Jewel ? > > > > > >> > >>> > >>>> 6. If we can’t make all the pieces of Basic truly optional, I’ll help > >> you > >>>> pull the Basic TLCs and CSS out into a separate project. > >>>> > >>>> > >>> Ok, my only concern here is how to do this plan, since I see many > >> problems > >>> that only can be making just what I can avoid. > >> > >> What problems do you envision that are stopping the 0.9.3 release? Can > we > >> get things working for the release and then take it from there? > >> > > > > I think we are stopping the release because of this discussion, since all > > is working right. The only problem is the change of classes to other > > packages that will make users to take that into account. But 0.9.3 can be > > made some weeks ago as jsonly was fixed right? > > > > > >> > >> I’m working on getting rid of all the class selectors which are bringing > >> Basic pieces into Jewel. Please give me a chance to finish this work. > >> > >> > > I think this can be done independent of the discussion about link Basic > or > > not. We should not mix things and keep the problems clearly > differentiated > > > > Harbs, > > > > I want to propose a way that respect both ways. You can do your work on > > refactoring class selectors while I continue my work on Jewel. But to do > > this I need to create an intermediate library. I can do that with > temporal > > name "Foundation" and then put there the beads I'll need (as I needed). > As > > well I can return things from Core to Foundation and Basic (the same > > temporal copy on both sides). This will make you and me try to proof our > > concepts, and not only proof yours is the only one that is right. What do > > you think? > > > > Thanks > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
