royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: [Discussion] Package change names (was Re: 0.9.3 Release)
Date Wed, 30 May 2018 03:53:19 GMT
FWIW, I think there is still a disconnect here.  After looking at Carlos's diagram with a Foundation
layer, maybe the confusion is around how to think about Composition-based instead of Inheritance-based
components.  There should be no desire to make every component set use only things from a
single "foundation" layer.  That's why I wanted to close on the discussion about using Express
beads in Jewel.  So maybe we should put this thread on pause and finish up that discussion.

Couple of other thoughts:

-There should be beads of varying complexity, from small, simple (Basic), to more powerful
or type-agnostic (Express).  This latter category of beads don't belong in a "foundation"
layer as they are a layer above the Basic ones.  Yet Component Sets are welcome and even encouraged
to leverage these more complex beads.  Our users have asked for that.

- As Harbs is saying, and I said earlier, Core is intended to be implementation-agnostic and
identify the parts/roles in the framework.  Basic beads, especially the Container beads, are
a specific implementation, knowing that SWF and JS are the outputs.  Who knows what will be
required in the implementation of component sets for other outputs.

My 2 cents,

On 5/29/18, 11:02 AM, " on behalf of Carlos Rovira" <
on behalf of> wrote:

    2018-05-29 17:44 GMT+02:00 Harbs <>:.
    > 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:
    > >
    > Here is what the dependencies are currently:
    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
      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
    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
    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, 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
    Carlos Rovira

View raw message