royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: [Discussion] Package change names (was Re: 0.9.3 Release)
Date Thu, 31 May 2018 06:02:26 GMT
Hi Alex,

2018-05-30 23:14 GMT+02:00 Alex Harui <>:

> Hi Carlos,
> I'm replying to all posts on this thread since my last post.
> I see a claim that there is a problem because of the compiler parsing a
> CSS file from a SWC where that CSS will not be used.  Is there proof that
> it is a significant performance problem?  Such a claim should be backed by
> data from an experiment by making the Basic defaults.css one blank line and
> see if compile time of a Jewel-only example speeds up in a significant
> way.  Also, we already have an -exclude-defaults-css-files option.  It
> currently does not prevent parsing of the CSS file, but we could make it
> so.

I don't say it was a performance issue, I said that is no point in process
a CSS that will never be use.
As well if exclude option continues parsing the CSS, seems a bit incomplete

> As of last week or so, I believe the royale-compiler develop branch
> contains all fixes that caused unused selectors from themes ending up in
> the final app.

That's great! thanks for working on this :)
That's part of the way to solve things.

> I believe we still need a volunteer to change the royale-asjs code to
> eliminate use of class selectors in its defaults.css files.

I think this should be done by someone like Peter that is more aware of the
implications on that part.

> In a composition-based component framework, a dependency graph that looks
> like it is hierarchical should not be a goal.

Totally agree

>   We want these beads, even high level beads, to be re-usable in multiple
> components sets.

Key word here is *optional* not *mandatory*. Take this in mind, since while
I have the option to use it or not, I even should have the option to link
it or not, since there's no obligation or requeriment to use.

> There may be a SuperJewel someday or variants on Jewel with completely
> different names that borrow beads from Jewel under the principle of
> re-using code.

That will requiere that SuperJewel links Jewel to use it, as well Express
need to link Basic. CreateJS does need to link Jewel, that will be

> The Emulation set will probably use Jewel views.

Hope so, so MXRoyale will link Jewel since it needs, while Basic not since
it never will use it.

> Our users have asked for our component sets to require little
> configuration, so Jewel should re-use Express beads.

Can give an example of a reusable Express bead in Jewel. FWIK Express is an
aggregation of Basic UI Set, so it makes less need of configuration in
final code, so a Button can integrate Disabled bead. Don't have in mind a
reusable case of Express in Jewel, since Jewel doesn't use Basic at all.

> The beads should be collected into SWCs that organize what they do, much
> like Apache Commons.


>   I don’t think Java projects try to only use one Apache Commons JAR
> because of a cleaner dependency graph.

Right before any other framework out there doesn't try to link all possible
and existing SWCs. In fact we don't do as well with Binding, Network, and
more, why we should do with a library with an UI Set (I mean with the TLCs
and CSS of a UI Set not with the reusable part that I call Foundation)

> I think you are making the argument for doubling the number of SWCs so
> that beads go in a SWC and TLCs that use those beads go in a separate SWC.

Doubling no, jut one: Foundation - Basic. The rest is up to discussion, but
since are not required right now (are already not linked or mandatory) like
MDL, CreateJS, and more, I'm fine with it. I recommend in the future
refactor as well, but that should be made by volunteers if they want

>   If that's what folks want to do, that's fine, but I don't think that
> will be the right decision.

That's exactly why I need and want, since don't see other way for continue
evolving Jewel that we have a so called reusable SWC without TLCs and CSS
that could bring bugs or not, and could bring unwanted code or not, or
could bring behaviors difficult to find or not. I simple want the most
simple and straight forward path. Since I'll never use basic TLCs and CSS,
I don't want the obligation to link those.

>   It will mean you have to list two things in each pom.xml instead of
> one.  It will take longer for component developers to go back and fix
> something in the bead project and then in the TLC project.  Third-parties
> have to deploy two SWCs.  Folks can't just grab a SWC and use it, they have
> to grab two.
I think the benefits overcome by far introduce about 5 lines in a pom. If
that was a problem, I said before, we'll better create one monolithic SWC.
But I the other part, split into two, make us, framework developers speed
compilation of the SWC we are changing since is about half size

> Again think about the analogy of Apache Commons.  It is not one giant
> library, but a set of libraries.  And for sure, if you only use one method
> out of seven different Commons libraries the compiler spent time reading
> the entirety of those 7 libraries, but you don't want to make the libraries
> too fine-grained either.  Libraries are organized by common traits to help
> users figure out which ones to use, not an attempt to save compile time.

So in the same way if we have Foundation and Basic, people will clearly
knows what is reusable and what is basic UI Set, without having all mixed
and messed....I think that's a good point to split into two right? We keep
improving into organization and make thing even more clear for our users
and framework developers.

> The key is that things not needed don't end up in the output.

right, and even in the SWC used, not all should goes in the output. If I'll
don't plan to use Jewel Datagrid when exists, I don't want all that code
goes to the output.
At that point, we still need to be care of the bugs you already fixed to
ensure it is working right.

> There isn't an Apache Commons analogy for that since JARs are dynamically
> linked.  But in statically-linked libraries like C/C++ on Windows, the
> compiler does visit entire libraries and only links in what is needed.

But links all existing available libraries? when you program in C++ you
link what you need. So in Royale there's no point to link a Basic UI Set
(TLCs and CSS) if I'm going to not use it, but use another one.

> I did notice a good point about code hinting in the IDEs.  IMO, the new
> IDEs will need to have smarter filtering of the options.

Thanks, I thought I was the only one in notice that one :)

>   We need to think big, where lots of people are putting lots of SWCs on
> the various library-paths.

Agreed. Very important, and up to us.

> Those of us who are currently committers are likely to only write a small
> fraction of the SWCs in the world in Royale is successful.  Unlike Flex,
> where we tried to get everyone to use MX or Spark, folks should have many
> more choices.

Right, in flex people use to have normally 2-4 libraries additional to flex

>  Flash Builder already has the option of disabling SWCs in a library-path.

I expect to have things in IDE configured like in IntelliJ via maven so the
IDE read the pom and only link what is there. An IDE maven driven will be
needed for big IT applications, since those people will not want other
option. In fact, although I use VSCode myself, I need to put IntelliJ to
work at some point to make it valid for an entire team. Is a requisite to
use Royale for that team.

>   I would encourage the IDE vendors to do the same.  And also realize that
> the MXML manifests allow mapping of a bead from one SWC into another MXML
> namespace, so I think folks should be encouraged to filter by typing the
> prefix of their active MXML namespaces first and then "Button".

That would be a good solution if users want to link more than one UI Set on
if they want. Good.

> Core used to contain UIBase, ListBase, GroupBase and some other base
> implementations of interfaces.  Then they moved to Basic during the wrapped
> Sprite experiment and never moved back.  So, I didn't have any problem with
> them moving back just now.  The reason they were in Core was to serve as a
> starting point for TLCs in other component sets.  Again, the key principle
> is code reuse.  If someone wants to do something very different and
> unrelated to the Flex-like nature of our main component sets, they can use
> those base classes.  But if more folks want to keep them in Basic I'm fine
> with that.

If we end doing Foundation, I think Harbs stated to make Core more about
interfaces, and so UIBase will go to Foundation, the same for ListBase or

> One closing comment:  The reason I think we are picky about the code in
> Jewel is because we want it to be the flagship component set for Royale
> (and I think we all thank you for getting the visuals to look so good) and
> thus it "must" display our recommended practices.

Thanks for your words Alex. I want it too, and I hope so, but even if at
some point, you and others are not satisfied with Jewel standards, you will
be able to make a new Library that use the parts you need and put it
working in other form. And even I could switch to that If I think is a
better way of doing things. the old way makes us no having election, the
new one is more flexible and less restricting and make us all have the
choice to do one thing or the other, so finaly the best option available
will be what the users will choose mainly.

As well, I appreciate a lot your thoughts and comments. You invest huge
amount of time, and is normal that we as we are so passionate with what we
are doing will defend the way we are doing things. If we where
occasionally, maybe we didn't care too much. But I trust in the way many
brains can get things set up and even in my company I like to completely
delegate on others what they have to do without too much control on it,
only reporting in points and looking to the results. I think people need
some room to develop and a adjusted intervention. We just need to calibrate
the efforts since maybe this time we are putting our focus in so much
discussion and we are loosing power in the rest of points (coding, website,
social networks, and more...).

>   MDL and CreateJS will not receive the same scrutiny.  Anyone is welcome
> to create some other component set that isn't PAYG at all.  But the ones we
> are promoting as examples (Basic, Express, Jewel) should reflect our best
> practices.

Hope Jewel reflect those practices, and I try to go with it since I'm a
huge advocate of PAYG.



> My 2 cents,
> -Alex
> On 5/29/18, 10:52 PM, " on behalf of Carlos
> Rovira" < on behalf of>
> wrote:
>     Hi Alex,
>     2018-05-30 5:53 GMT+02:00 Alex Harui <>:
>     > FWIW, I think there is still a disconnect here.
>     Right, I think we are mostly on consensus about refactoring names and
>     packages and how to deal with CSS names, but the final point (maybe
> most
>     important) is about the dependency library that I think is very
> important.
>     > 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.
>     maybe this is the problem
>     >   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 that's exactly my concern here. As you said, we don't need every
>     component set to use a concrete layer, but in the old set up and for
> Harbs
>     diagram, we are forcing every single user to do that, and even worse,
> we
>     are putting a CSS configuration processing in the middle and making all
>     apps pas through it. And I write many points about the disadvantages of
>     doing that. So I think we are saying the same.
>     > So maybe we should put this thread on pause and finish up that
> discussion.
>     >
>     I think we are reaching to a close here, don't see the need to make a
>     pause. More over, we have many users out there that wants to try Jewel
> and
>     they are waiting for the 0.9.3 release to put blog examples in
> practice. I
>     think we are gaining some momentum out there, and that was hard work to
>     reach to that. We are pausing this efforts and if we don't feed the
>     external communication, that will end reverting that effort. So I
> think is
>     better to go forward and solve this problem. We are about a month stuck
>     here, and that's not good for the project IMHO.
>     >
>     > 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.
>     Again we are saying the same, the latter beads, the concrete
>     implementations of controls and components, and the CSS that wires all,
>     should go to its own optional library (i.e: Basic, Jewel,...) for the
> user
>     to choose the one to use without obligation for our part.
>     > Yet Component Sets are welcome and even encouraged to leverage these
> more
>     > complex beads.  Our users have asked for that.
>     >
>     Right.
>     >
>     > - 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.
>     >
>     I'm as well aligned with this. This is ok with the new dependency of
>     libraries
>     IMHO, we have consensus in all the things discussed in the other
> threads,
>     and regarding dependency of libraries, I see for this email that Alex
> and I
>     are saying the same and only need to know about Harbs.
>     Maybe since both ways do the same, the question you must to answer
> yourself
>     is: Do I want to have all the same benefits from old configuration,
> plus
>     new flexibility ones? hope the answer will be yes
>     thanks
>     >
>     > My 2 cents,
>     > -Alex
>     >
>     > On 5/29/18, 11:02 AM, " on behalf of Carlos
>     > Rovira" < on behalf of
>     > wrote:
>     >
>     >     Hi
>     >
>     >     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:
>     >     > >
>     >
> %
>     > 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
>     > cee1%7C0%7C0%7C636632137691163168&sdata=A1StIlX4vcrkQ%
>     > 2F8EF7o8SPoGD28pmyHp6amM%2BzYQqNI%3D&reserved=0 <
> https%3A%2F%2Fna01.safelinks&
> 7Ca0c7ac59b92743f83ac808d5c5f1821f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632563492435870&sdata=I4u9xUDRERMVsM1mZWfNKIfLfsE1KA
> UoClDJEj8BoW4%3D&reserved=0.
>     >
>     > 2FDbH4iG.jpg&
>     > 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
>     > cee1%7C0%7C0%7C636632137691173177&sdata=
> IKoHqY9iflgHix7NbSbw1mO9wptThn
>     > LbFv7tLFIE4DU%3D&reserved=0>
>     >     >
>     >     > Here is what the dependencies are currently:
>     >     >
>     >
>     > 2Froyale.png%3Fdl%3D0&
>     > 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
>     > cee1%7C0%7C0%7C636632137691173177&sdata=Umo%2F2xF%2FrfGZNybFfc%
>     > 2FwbtkOr8UnRvVwKhlF6wblr9o%3D&reserved=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,
>     > 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
>     >
>     >
>     > 7C42db7d68cb1f48b59d7208d5c58e630d%7Cfa7b1b5a7b34438794aed2c178de
>     > cee1%7C0%7C0%7C636632137691173177&sdata=
>     > dW05hbWW%2FeJuc%3D&reserved=0
>     >
>     >
>     >
>     --
>     Carlos Rovira
> 7Ca0c7ac59b92743f83ac808d5c5f1821f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636632563492435870&sdata=hJWNXAekVx6UlgDEmFDrBnU%
> 2FXbSaItFzTb4ESaxL5JI%3D&reserved=0

Carlos Rovira

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message