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
