Hi 2018-05-29 17:44 GMT+02:00 Harbs <harbs.li...@gmail.com>:. > > > OK. I define Core a bit differently. Core defines the *architecture* or > “scaffolding” of a Royale application. I don’t believe a Royale application > can be compiled from Core alone. > > Core is assumed to be a prerequisite for almost all other Royale libs > (except Testing and Language). It should not have dependencies on other > libraries or particular implementation details. > > Right, I was not taking into account Language and Testing since for me is even more "platform" or event more "atomic", but in essence we are talking the same here.
>> 4. What are the advantages and disadvantages of making Basic a dependency > >> for other component sets? > >> > > > > I think this is mostly explained here, and a image use to be better than > > thousand words, but the image mix graphs and explanations: > > https://snag.gy/DbH4iG.jpg <https://snag.gy/DbH4iG.jpg> > > Here is what the dependencies are currently: > https://www.dropbox.com/s/8n3dxgv45qus3jp/royale.png?dl=0 > > good to see how you see it. > I don’t understand the point of changing the dependencies around. > > To me the advantages of making Basic a dependency is: > > 1. A clearer (to me), flatter dependency tree. > your's a mine seems to be equally flatter for me. > 2. A “base” component set to use (or partially use) for composition. > Take into account that Jewel does not subclass any component in Basic. MDL should not do it, since extend a control from basic really does not bring it nothing. I did in that way since at that time I was young in creating UI sets, but I never was completely happy of that way. But, again, both models make possible to extend a set and create a new one from that point, but yours make that mandatory, so for me less flexible. > 3. A logical place to put shared beads. > This is resolved with "Foundation" library. Finaly we'll be doing the same, using a common library that reuse beads. > > What is gained by removing that dependency? > Well, while both versions brings the same benefits, as I tried to respond in the responses to that 3 points, I think separate beads and coming code in Foundation makes Royale more flexible. I talk about this several times, and I think advantages are clearly shown in the schema image, but I'll try to summarize it again: What improvements we get? (I'm supposing we have Foundation library with beads and common code previously in Basic, and some now in Core, and think that Basic ui set for me is only the controls and components and the css, not the beads and code that will be in Foundation) 1.- Without Basic, or any mandatory UI sets, we remove the processing of the CSS beads file that is part of every UI set. This is critical, since far beyond compiler bugs, we don't want our app to process a file that wire a lots of beads, since the right bead file to process is only the UI Set the user wants to use. 1.a-If you want to use Jewel, but declare first Jewel and then Basic, Basic setup wins over Jewel, and this shows clearly that this is nothing good. 1.b- This introduces, unwanted content, increase size, and is a hole of possible problems that we are creating for free. This one solely is huge one. 2.- We as well remove the processing of CSS html rules, that are equally a generator of free problems. 3.- Something that comes clearly as you think more in it... why make Jewel dependent of Basic if Jewel don't extend any Basic component? 3.a- If we continue thinking in that, why we are separating in libraries if we finaly link all? If we link all, then we should join Core, Basic, Jewel, Binding, Network, and so on... 4.- Separation is good since this make framework developers try to use the logical pieces they have. In the current way, we'll tend to mess things since we have lots of pieces available and can take the easy way. 5.- The new dependencies is more flexible: we can use Jewel, and at a time, use Basic if we want, is up to the user to choose it, and that's more powerful that make them link a Basic UI Set that maybe he doesn't want use never 6.- Why make an UI Set principal over the others? what have Basic over Jewel, or the opposite? Those are the same, but we have more than one since are designed with different goals in mind, so there's no point on make one link another (and again more over when the new one doesn't use any single class from the parent). That's for me clearly useless. 7.- Future major versions: Some time in the future we'll want to create v2.0. As happen with many other projects (think for example in Flex with v1.0, 2.0, 3.0, 4.0) each major release implies dramatic changes. If you change from Java 5 to 6, 7, 8, 9...or Spring framework from 2.0, 3.0, 4.0...you know what I'm talking about. So for Royale this dependency design makes us more flexible and capable to make a 2.0, 3.0, and so on without affect 1.0 in a hard way, so our users will be less affected and will be able to upgrade in a more easy way. 8.-Because as I said before, we have the same benefits than before, but now we have many more. While in the other way we are less flexible, more rigid and that's worse for Royale. I think this is the major point of discussion we have, and hope that all points exposed will be sufficient to show the benefits and advantages of the dependencies. For me the major point is that we should not have any library in the tree of dependencies that has a CSS wiring beads, and that library is mandatory in all Royale applications. I think that's the main point of problems and we should fix it. that should be a rule "Mandatory libraries in a royale application can't have a CSS that wire code (beads)", for that reason, that part of Basic (controls, components and CSS should be in their own library Basic.swc, and the reusable code be in a common library that the rest can use (i.e: Foundation.swc) Hope this brings more clarity, but I think I'm repeating myself in many many emails Thanks -- Carlos Rovira http://about.me/carlosrovira
