Hi Harbs, 2018-05-13 10:40 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> I specifically waited to respond to this until some of the heat cooled > off. I have no question that there is a bit of a language barrier here and > both sides are not making themselves completely understood. > I could in the previous hours get some information that's important, but I prefer to not mix things here, so hope to share as I can, so avoiding to introduce more noise. > > I’m a bit disappointed that we’re moving towards a vote before I believe > we’ve gotten to the bottom of the technical motivations. I was hoping we > could get to the point where we understand each other and make a vote > unnecessary. > > I said about to make a vote thread, since I was not hearing many things in favor of my work, but reading your email, Om, and other feedback, I think we are moving to a really different scenario. This is more a community discussion, with a really different tone, so if you (and others) finally doesn't want to vote, for me will be ok. I was only doing since seems what all of you demand at that point. > Let me try and summarize the technical reasons as I see them for and > against a refactor: > > Reasons for the refactor: > 1. As it stands, referencing Basic brings in all of the Basic CSS. This > causes a number of issues: > a. Another component set (i.e. Jewel) needs to override any CSS > specified in the Basic CSS. > b. The CSS which is compiled from the Basic CSS adds unnecessary bulk > to the final application if Basic components are not being used. > c. Although this point was not clear (to me) from the previous > discussion, all classes referenced in Basic CSS are actually imported into > the final application. For example: DateControlsExample does not use > ButtonBar, but ButtonBar and all related classes are included in the final > application. By not relying on Basic, these classes are not imported. > > 2. Basic and Jewel are separate component sets, and as such should not > rely on each other. Any part of Basic which Jewel needs is not “basic”, but > “core” and should be moved to the Core project. Doing so has the following > benefits: > a. There’s a clear separation of dependencies. > b. Someone working on Jewel does not need to be concerned with the > architecture of Basic. > > I’m not aware of any other arguments which are not variations on the > above. Please correct me if there are more reasons. > I think is mostly the technical reasons. I exposed many of the collateral damages of all of this, but I think is basically the problem. Great to see finaly I could make it understand :) > > Reasons against the refactor: > 1. Royale favors composition. As such, it was designed so functionality > can be pieced together. Much of this functionality was created in the Basic > project and as such, it’s natural for component sets to borrow pieces from > each other. This reduces code duplication. > Right. But IMHO, this should be chosen for user users. If he wants functionality, he can "optionally" take it, and not "obligated" to. In the other hand think about functionality that is not exactly the same. If I have a bead that in Jewel put a className and in Basic the implementation puts an attribute on the tag. The user will find both with CTRL+SPACE (code hintting feature), or using a Button will find obligatory more than a Button, that will comes to confussion. What is the right Bead? the right control?...If he optionally wants to add functionality, is up to him to use one or another. > 2. Moving pieces of Basic to Core does not scale. We need to define what > Core is, and claiming that something is required by a component set makes > it Core is not a good definition. For example, Collections is not Core, but > it is required by component sets. As it stands, Core defines the core > architecture of a Royale application, but says very little about > implementation details. That’s why there are lots of interfaces, but not so > many implementation classes. It’s possible that little bits of Basic might > make sense to be in Core instead (and vice versa), but I think the general > difference between Core and Basic is well defined (although possibly not > well understood). > I must say that don't see why moving pieces to Core will not scale. The pieces are the same, the extensions are the same. There's a change of location for some classes to get a better decoupling. One thing to notice is that we are dealing with *final implementations* or *leaf implementations*: this means the same like when we mark a method in java like final...this seems we expect a final use. A button, for example, can be aggregate in a "ButtonWithDisableBead", but this works more like a "macro" than an extension. So AFAICT, subclass other's UI Set controls or beads, seems to be not desirable in a huge percentage of cases, at least in my experience with MDL and Jewel (and I think that's a huge experience). MDL was done subclassing, but I found many problems going in that path. Jewel started equally but I then did this refactor and now I'm very happy since I see all more well crafted. I'd like that the theory you expose will be real, but the practice tell me the opposite. Or said in another way, I was aligned with you but as I followed the path, I end embracing this other path as to be better, more flexible, with less errors, and problems... and the price is really no one, since all things we want in a Royale Appication are still there. > 3. Not every class in Basic *can* be moved to Core. For example, > DataItemRendererFactoryForArrayList has a dependency on Collections. Core > was designed to have no dependencies on any other projects other than > Language, so that class cannot belong to Core. I would imagine that other > component sets other than Basic might need ItemRendererFactories. > > This is where from the beginning I ask for help. I did one way. Is like a Zero day. We can get it much better moving other things and I think you, Alex, Peter, knows perfectly and maybe better than me how to reorganize things you think. For example instead to move a class to Core extract code to be implemented in Basic and Jewel. Or like the example I already exposed that was problematic, extract Group states and mxml nesting and add it to Group and HTML's NodeElementBase... I think there's lots of things to do here. We only must to take into account to left Basic - Jewel separated, but options are lots. > > Possibly the strongest argument against the refactor is that I believe the > refactor doesn’t actually solve the problems it’s meant to solve. Please > allow me to explain: > > 1b and 1c are actually bugs. I’m glad Carlos brought them to light, > because they need to be fixed. These problems have nothing to do with the > fact that one component set relies on another. Even if a single component > set is used, all the css and classes mentioned in the css file are > imported. That should not happen. If the compiler does a better job of only > using the css and classes where are *actually* used, these two issue go > away. > I think there's a problem, that's right, but the problem should not mask the flexibility that we now with the current separation. Remember, what's the point if we have the problem fixed and we link again Basic to Jewel, if Jewel will never use Basic? > > I think the refactor really masks 1a and does not solve that one either. > There’s actually a fourth problem related to CSS. What happens if a single > app uses a Basic Button, an MDL Button and a Jewel Button? (As to why that > might happen — components can be used within other components and not all > component sets might be as complete as others.) What will each of the > buttons look like? As it stands the typenames will conflict with each other > and the CSS will step on each other. I’m not even sure which CSS will win. > It seems to me that typenames really should be qualified to prevent > namespace conflicts. I’m not sure how to best solve this, but I think it > deserves discussion. > Namespaces already solve this so a js|Button is separated from j|Button and from mdl|Button, if no namespace was declared last wins, so at that level I think things are ok, but what is happening is since an mdl|Button is extending a js|Button, then you get all CSS from both of them, mdl wins and must override things in Basic. IMHO, that's not good from an architecture design point of view and more... for an override, since those are *final* or *leaf* controls, and more...we can get other classes in the inheritance chain that we never want to use, so extra space is added. Then there's the pure CSS styles, but that's the nightmare I (as the UI set developer) use to fight each day when design a new control for MDL or Jewel, and If I do my work ok, you should not see any conflicts, but at the cost of override *all* predefined styles (extra space again in place). I think that the need to override styles before the refactor in Jewel is not PAYG nor DRY. Or said in another way: If Jewel doesn't use a control or component in some part of the defined style, and maybe doesn't need to use a Bead, but it still needs to override it?. I think that's not scalable. And the best solution I can propose is to disconnect final/leaf implementations one from another. > > As far as 2a and 2b go: Here’s my thoughts: I don’t see 2a as a goal for > Royale. I think functionality sharing across component sets is an advantage > to Royale and not an architectural problem. I think so, but always for not final/leaf implementations, and the key always, optionally and not obligation imposed by the framework that makes it more powerful and flexible. That's great for some functionality that you need to implement in various UI sets, beads that are very/really generalist. Not at all for beads that are very near on concrete needs in implementation UI Set, since you'll never be able to use it. > Regarding 2b: complete separation from Basic seems to me like it only > helps splinter the community and puts everyone into their own little > isolated corner. As difficult as it might be to deal with others’ opinions > and it causes things to drag on longer than it otherwise might, I think > it’s ultimately the better path. I really do recognize the frustration of > trying to do something and have the brakes put on you by others. I don’t > know how to put that empathy into an email. It’s a poor medium for that. > Ultimately, the more we rely on each other, the better the quality of the > end product will be — even if it takes us longer to get there… ;-) > Well, as I said to Yishay, I think separation brings flexibility and makes the whole framework even more prepared to future aggressive changes (a v2.0 and next versions) since from the beginning you didn't make it depend on Basic, so you can start another effort in parallel as a sibling. I think that concept is very powerful don't you think? Jewel borns from the work in Basic, it could not be at all without Basic. But Basic has a purpose to be very well decided, so it will always collide with Jewel that has very difference purpose. And I think we always talked about people coming and creating new UI sets as needed, but those coming will find the same problems that I found if they are obligated to deal with other final UI set like Basic. In the other hand, we need to grow to have more people interested in different parts, and wanting to get involved in those parts, so we can act more as a community. I must to say that I don't mind to discuss more, but I think I always think in the value of what others have to say. When Alex, Peter, you and other use to expose things I use to engage with the solutions and if I have something to say use to be to propose ways to improve an already good solution by default. When I expose changes, I use to want people that comes to improve it, making it better than only with my solely participation. I think that's what we need to get here. Since people here are very good by default, I suppose nearly 100% of proposals should be good, and debate/discussion should go in tone of "And what if you incorpore this?", "I think doing this could be event better", and so... that would make a good difference. And I think is something to comment a part since this community deserver this kind of good health. > > I hope this makes my position clearer and I look forward to other thoughts. > Really, I think this is completely different way of managing things and I appreciate really. It's more constructive, friendly and at last we are talking about real things than asking us things lots of times in an infinite loop. I think is a real community discussion. Thanks for take the time and your efforts reviewing this :) Carlos > > Thanks, > Harbs > > > On May 12, 2018, at 11:09 AM, Carlos Rovira <carlosrov...@apache.org> > wrote: > > > > Hi, > > > > I'm trying here to explain with more tools the problems we had until now > > and the solution I did he past Friday. > > > > Disclaimer: This solution doesn't intend to end in the current state, and > > we can evolve to get other shape more convenient for others in this > > project. I'm sure Alex or Harbs can add up to enhance what I did greatly > as > > always do. > > > > So let's go: > > > > Until now we had this kind of relation between libraries : > > > > https://snag.gy/JqO2ZI.jpg > > > > In this schema. Basic is needed always to construct an Application. That > > causes that all applications will end aggregating the used styles of the > > CSS in basic and all the classes that are linked in that way plus the > tree > > of dependent classes. > > > > Until now that wasn't a problem, since we didn't care of it. That extra > > size all applications incorporated was not in out target since we only > had > > Basic to construct applications. A side case was MDL but as is a > "wrapper" > > around an external library, again we didn't care too much about this. > > > > Now with the new Jewel UI set, we have another UI set that although is > > based in the work in Basic is a first citizen, so for example, a Button > in > > Jewel extends UIBase and not basic Button like before. So changes in > Button > > or in other Basic infrastructure classes not affect Jewel at all. So > > final/leaf components are dependent of UIBase (in Core) and not anything > we > > have in Basic. The same happens with Jewel TextInput, Jewel Slider, and > > more. > > For example Jewel Slider is based on input range, while Basic Slider is > > build with two buttons. So even ISlider interfaces are different in Basic > > than in Jewel. > > So key point here: final implementations should not depend one from > another > > since any changes in the code of the parent will affect the children. > > > > As you can see in the schema, we have various libraries that are top > level, > > some of them are optional, and for this reason are separated in library > > units (Network, Binding, Collections, and more), but Core is not > optional, > > must be in all Royale Applications. > > > > Basic until now although it was a concrete final implementation of an UI > > set, was in fact needed in all Royale Applications, and that cause that > > always its CSS and its classes was baked into the final App. Only if you > > don't use visual elements you'll get rid of basic need, but that in a > front > > end app is very strange right? > > > > This design caused from the begging lots of problems that started to rise > > when I first started MDL library. We have styles and behaviours that was > > not required due to the presence of unwanted CSS and classes from Basic. > > > > So for this reason a key point is that we need to bake into final app the > > resources we really need to avoid unwanted content that is not required > and > > only increases size and the presence of potential bugs and not wanted > > behaviors. > > > > With the refactor we get to the following graph > > > > <https://snag.gy/JqO2ZI.jpg>https://snag.gy/KW36yn.jpg > > > > Now in the final picture, we don't have the presence of all the things > that > > comes with Basic when we create a Jewel application, the final developer > > don't need to be worried of any unwanted behavior that comes from Basic > > since Jewel no more requies it. > > > > But this is completely compatible with the older scenarios. People using > > Basic, will use it I the same way and get exactly the same. So this > > refactor doesn't break existing applications. > > > > Since I moved classes from Basic to Core to be as DRY as possible, but I > > changed from package (from "html" to "core") to improve organization, > that > > change can make final applications need to update those namespace, like I > > had to do in all the examples we have. This is something that should not > > make a huge task more than a few minutes, but something normal when a > > refactor is done. There's few refactors that does not implies changes in > > final applications. This change of packages really is not needed, but I > > think is convenient to get a better organization. Now we have still core > > packages in Basic and html packages in Core, what makes things a bit > messy > > and shows that still we need some API changes and cleaning. Normal since > we > > are on 0.9.3 version. > > > > A special case is HTML, where is the only real code change I introduced > > (99% was only move code from Basic to Core to allow get rid of Basic). > > I changed NodeElementBase to extend UIBase, due to Harbs proposal. Then > > Yishay saw that it wasn't allowing nesting, so I changed again to extend > > Group. And to get this Group needs to be in Core. In other way HTML will > > depend on Basic and anytime we'll create a Jewel application that uses > > HTML, this library will bring Basic with all known problems (CSS and > > Classes not wanted). > > > > All this changes, make the build broke and show some deficiencies . Some > > HTML was linking Basic, Basic was a inherited dependency that was not > > declared in many examples pom. So now we have all poms fixed with the > real > > dependencies, if the example uses Basic, it will have Basic, if not, it > > will be not present at all. > > > > Some others classes were copied "temporaly" to Jewel. For example > > MultilineLabel, was copied from Basic to Jewel. The final step is to > remove > > that component since in Jewel I don't want a MultilineLabel, but a bead > > that makes Jewel Label to be multiline. So this that is not DRY in some > > days it will be since I'll be removing that temporal control. I only > copied > > there to allow all examples build right. As many refactors things doesn't > > end at the beginning it then requires more steps to be done. The > important > > thing was to left all the code building ok at that time, then start to > use > > things in this new way for Jewel, since Basic is all the same > > > > Finaly all this changes, not only make the app developer not worried > about > > how to not collide with Basic styles and functions, but makes Jewel > Royale > > Applications 40% less sized than before. > > > > I think I cover all points, If I remember something I didn't tell you > here, > > I'll be adding more email. > > > > At this point, you can see that technically is very important due to > avoid > > unwanted code in final apps, unwanted behavior, reduce size, and avoid > > final developers to be confused by other similar structures present that > > they don't need (CTRL+SPACE will only throw one kind of Button now > instead > > different implementations). > > > > As well the current refactor still makes posible to mix libraries if the > > developer wants to do it. He can add Basic dependency to a Jewel > > Application if the still needs something and want to pay all the extra > size > > and behaviors of the basic linked code. > > > > Things that we can do to improve more this scenario: > > > > 1.- extract GroupBase functionality to Core so Group (in Basic) and > > NodeElementBase (in HTML) can compose t > > (this will improve DRY) > > > > 2.- I think we have a good organization regarding libraries now (Core - > > Network - Binding, and then UI Sets, Basic, MDL, Jewel,...) > > But maybe folks would be feel better with other organization. > > For me the only thing I need is that whatever solution we want doesn't > > force people to link Basic as if it was a Core library since it's not, is > > only a final implementation of controls and components) > > > > 3.- I think if we find more Core functionality in Basic we could pass it > to > > Core, I think we still have Core things in Basic. As is normal since I > > suppose people made things to make it work, but maybe is time now to > "clean > > the house" a bit after all this time and see where things should go. The > > fact that we have core package in Basic and html package in Core is a > clue > > that things are not still in right positions. > > > > > > We must separate *needed* things from *architectural* things. For me > > *needed* is : > > > > 1) not need Basic dependency since Jewel really doesn't need it!, and > don't > > want users to link things that only generate problems linking styles and > > classes that make final developers to fight with fonts, or colors, that > > they don't know how are appearing and why. And don't want extra classes > > linked that could bring errors very difficult to find and solve. And > > finaly, don't want extra size in apps since that extra size comes with > only > > undesirable effects in the final application. > > > > just that > > > > Some of the points I expose are not needed, but would enhance the quality > > of the code and people trying to use it. Now we have still a bit messy > set > > of packages. We can move things so all people here would have things set > up > > as they want. > > > > Some of you can propose other ways to get to the same, but I'm afraid > that > > in essence it will be mostly the same. But I'm totally open to bring more > > ideas and to change things, since I'm sure my solution is not 100% > > infallible, and there's many ways to do things. > > > > My proposal is that since I solved many structural things in how projects > > and examples build, fixing poms that where not having Basic declared and > > more things that were arising during the refactor, I think is better to > > make the refactors other will propose from the actual point. And that > would > > be more easy to follow. > > > > Hope that now all is more clear thanks to new explanation and graphs and > > that you consider that we really have real problems to solve and that now > > are solved, although maybe not in the best way but in a valid way and > that > > I'm open to change things while taking into account that we at least > > maintain the same improvements I get with this changes. > > > > Thanks in advance. > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > -- Carlos Rovira http://about.me/carlosrovira
