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
