Hi Carlos,
I don't think folks are as highly concerned about moving the
ApplicationBase/ContainerBase/GroupBase classes into Core. I disagree that
GroupBase can go away, but that can be discussed later.
It is your "unique requisite" as you put it, that is the main issue. There is
no technical reason to change the patterns we've been using to try to ensure
that Jewel doesn't link in Basic. If every component set tries to be
independent of every other component set, then lots of beads will be copied,
and that does not scale.
If it turns out that the HTML components need 100% of what is in Group, then it
should be fine for HTML's NodeBaseElement ot extend Basic's Group, just like
Express components can extend Basic components.
So let's just focus on this one point. What is the technical reason that
component sets should not leverage other component sets? Why would we want
proliferation of copies of beads over time?
Thanks,
-Alex
On 5/10/18, 2:22 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
Hi Alex
I think you still doesn't understand what I did. I'll try to expone it
again with other examples. I was not moving beads, I was moving
implementations that seems to me core (i.e: ApplicationBase, ContainerBase,
DataContainerBase, GroupBase...). Since Application, Container,
DataContainer, Group,....seems to me final implementations, like we show
many times (think about Application in Flat, MDL, CreateJS, and so... )
More data: After stay in FlexJS and Royale each day, I have a clear sense
of what is Basic. And for me is the library that includes all componentes,
controls and its more basic way. But it a Button in Basic is not like let's
say GroupBase, or ArraySelectionModel that are in Core since are needed in
UI sets (Basic, Jewel, ...). So Basic, assembles the "basic building
blocks" that are not needed to be used (extending, composing, or other
things) in the library Jewel.
In the other hand the user can decide, on its own to link in a final
application, Jewel and Basic, for whatever reason. What I don't want, and
is my *unique* requisite in all this discussion, is that Jewel link Basic
in order to be able to be built. Since nothing in Jewel required nothing in
Basic. And this is by design in Jewel.
HTML shouldn't since as you saw, having NodeBaseElement extends Group and
Group being part of Basic, made directly that HTML library pull all the
contents of Basic (I sent the mvn dependecy:tree that probes that in other
thread), and that by default was making that all examples that depends from
HTML, was not linking in explicit way Basic, since HTML brings that, what
for me is a defect in a build clearly (and this is not philosophical, is
something clearly technical, that hopes people understand as is, and will
not make me repeat one hundred times again or explain the same since no
body read when I wrote this)
About beads: Some beads was moved as well, since Jewel needs them and seems
to me very Core i.e: LayoutChangeNotifier, or events like ItemAddedEvent.
ItemRemovedEvent,... for me those classes are clearly Core, since other UI
sets will need them.
I for example did some temporal thing i.e: Copied MultilineLabel in Jewel.
But I'll be removing classes like this since my plan is not to have a
control called MultilineLabel, don't like that concept in Jewel. My plan is
to make a bead for label to create multi line. So things like this are what
I say that are temporal, but first I needed to reach a state when all
builds correctly without the need of Basic (again this is the most
important concept to me), and other "temporal" things will be done if we
end this kind of large discussion.
I'm all for "trying to define the patterns that will scale with us forever"
, but it seems very complicated in this way, since each movement in this
way will make people update their code bases, and seems this is something
people here don't want to do.
2018-05-10 21:29 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
> Hi Carlos,
>
> I don't have a particular problem that you made a commit that broke
> things. That happens from time to time. I trust that if you knew up
> front it would break things you would have started it in a branch. What
is
> the problem is what happened afterward.
>
> I think there are at least 4 of us who still are not understanding you, or
> don't agree with your conclusions. This means that we are not
> communicating well. Either you are right, and you haven't found the words
> or data to convince us or vice versa. And the 86 prior emails contained
> very little data. Let's see if we can work from more concrete examples
and
> data to try to close out this discussion.
>
> We are trying to define the patterns that will scale with us forever.
> Moving beads from Basic to Core because you want to use them elsewhere is
> not a pattern that scales. I think you did not take into consideration
the
> differences between the old Flex model and this new composition-centric
> model in Royale. Separation of one project from another in a composition
> model should not be a high priority. What is more important is good
> organization of the choices for composition. Otherwise we will end up
with
> another problem similar to UIComponent in Flex.
Right, and if you read my interventions I stated this at least three times
though all this large thread. That I copied a class (bead, support class,
or whatever) to make possible compilation without Basic, and sometimes for
temporal reasons, doesn't mean the I want to make a 15k UIComponent class.
There's no point on that. I'm totally in favor on how UIBase is designed
and how beads and strands work. Copying a bead, to use instead another,
doesn't make Jewel to have a UIComponent monolith class, so I don't see the
point on this here. In contrast having a unused library (Basic) linked for
nothing makes a complete difference of 40% more in size what means classes,
css, and styles linked for nothing, and making the Application have
potentially unwanted behaviors. But I think express this at least 10 times
through all 90 emails here, but seems I need to keep repeating it myself
once and another time...)
> The Core library will contain thousands of classes that are similar just
> because someone wanted to re-use that code. Instead, we want Basic to
> contain beads that are simple, Express to contain "aggregations", and sets
> like Jewel and MDL can contain beads specific to those component sets.
>
Right, and for example you don't see Express be linked in Jewel or
MDL...why we are obligated to do so with Basic if I don't want to use any
bead from it?
Why examples like JewelExample, or RemoteObjectAMFExample, need to link
Basic if they don't need that library for nothing? Why we are forcing that?
What's the technical reason to force that?, I think there's no reason at
all, the only thing I can think is like Harbs said some "philosophical"
reason, and like him,
I don't think philosophical reason is a reason to force that. Instead, I
put on table lots of technical reason (less size, avoid unwanted styles,
not obligated to link a library with the same purpose,...and more!)
>
> A bead like a ToolTip bead can probably never go in Core. It has "an
> opinion" about how and when to generate and dismiss a tooltip. Look
around
> and you will see other ways that ToolTips are handled. The Basic Tooltip
> bead is a simple implementation that can be a sufficient default for a lot
> of component sets. But it isn't so universal that it should go in Core.
>
Right, I explained the same with a control, not a bead (MultilineLabel),
since this is not one only about beads, is about functionality that is
core, for example DataGroup is not a bead is a supportClasses (that extend
a class that extend UIBase and was in Basic), and was refactored to Core,
since was needed for Basic List and Jewel List....
>
> I think I will stop there and see if we can agree on this one point.
> Maybe we'll have to end up taking a vote, but this is the pattern I think
> is best for Royale and I hope to convince you of that.
>
Alex, I still don't know what you want to convince me. What I have clear is
what I want to convince you (I you already think that Jewel must depend on
Basic):
* Jewel must depend on classes that are on Core, clearly since is the
fundamental library in Royale
* Jewel can't depend on classes in Basic, since both libraries pursues the
same target and that was very discussed in at least two threads between
mostly you and I.
* I expect to go forward, fixing builds, and "trying to define the patterns
that will scale with us forever", and this will for sure continue breaking
Harbs app since is what happen with changes like this. And I expect that he
help to go forward instead of complain about his app not compiling. This
could mean to extract for example groupbase and group's states, mxml
nesting and more functionality to avoid repeat code and make it available
to Group and NodeElementBase. I think there's some more classes in Basic
that are Core, and you know is true. Maybe it first landed in Basic due to
the focus in make things work, but now that we are doing the Jewel effort
is a good time to think about the place it has now, since Jewel needs some
support classes and both doesn't want to copying code that are core, but
that doesn't mean that all the code must be reused, depending on the case a
code can be reused, other times, extended, other times copied (usually due
to leaf functionality), and more...
Thanks
Carlos
>
> Thanks,
> -Alex
>
> On 5/10/18, 11:01 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
> wrote:
>
> Hi Alex,
>
> 2018-05-10 18:50 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>:
>
> > Wow! Good thing I slept through this...
> >
> > Let's try to calm things down a bit. I think we have agreement that
> this
> > work should have been handled differently, but I really think this
> > disagreement, like many disagreements is being escalated by poor
> > communication. Sometimes it is hard to realize that you haven't
> really
> > explained yourself well. You know the problem so well, and are
> probably
> > trying to write a shorter email and/or have limited time to write,
> but it
> > makes things worse instead of better.
> >
>
> I don't really think communication was bad. I'm in this project and
> FlexJS
> form its beginning and I think I follow it always and I think my
> thinking
> about what is basic was right. My opinion about this refactor, is that
> maybe I did huge commit and for such commit I should be done some
> emailing, but other time we all commit without asking, so while it
> would be
> better, really I didn't do nothing bad, but maybe wanting to make this
> project advance as fast as possible.
>
> Then as a refactor like this suppose changes in applications that use
> the
> framework, Harbs instead of think in the positive thing of remove
> dependencies between libraries, was worried about his application not
> compiling. And here we are 86 emails asserting that we are not
> understanding right the essence of Core and Basic. And what I think is
> that
> team mates here instead of work for continue moving things to make
this
> project progress are trying to divert the attention talking about
> philosophical point of view, and I think the refactor gets technical
> things
> done clearly (separation and less size), while the philosophical seems
> more
> to me in stay in what we had and not wanting to move due to
> applications
> breaking. I'll understand that position with a framework more
> finished, but
> in a 0.9.3 version, I think we have room, and we discussed a lot of
> this in
> the past weeks, but I think many of the people not agreeing was the
> same
> that didn't follow that discussion and now they think all this is
> wrong,
> again due to personal interests.
>
> As I did the refactor I was very close to the email to see if
> something was
> broken, since although maven was ok in all aspect, I though something
> more
> could be happen, and as you all see I was hard working to fix things
as
> people let me know. But what I think is a bad practice in a project is
> talking about revert unilaterally a huge work that had many hours
> behind,
> since I'll never dare to propose something like this. Moreover when we
> all
> can have all the things we want at the same time. Or I don't see any
> overlapping interest here.
>
>
>
> >
> > So, couple of things to consider (actually more than a couple of
> things):
> >
> > -I still think we are missing a clear, detailed, technical analysis
> of the
> > claim of less code linked in by not having a dependency on Basic.
> For
> > sure, if you subclass a Basic component, you will get many more
> things
> > linked in, but I hope that using a bead from Basic does not result
> in lots
> > of additional unused classes. If it does, that is probably worth
> fixing.
> > Carlos, since this is your claim, please provide the data. Include
> a bead
> > from Basic and tell us what additional classes were added.
> >
>
> Alex, I didn't say that a bead from Basic will link additional
classes,
> what I say is that linking Basic was inserting 40% of more size, while
> apps
> work the same. Let me first ask about what's the point on doing this?
I
> have clear that Jewel doesn't need to depend on Basic since cover the
> same
> things, since for me both are UI sets, only that Basic was the library
> more
> developed since until now was the focus. For me what Harbs call
> "building
> blocks" are what a UI Set needs to have.
>
>
> >
> > -With composition, a tree/hierarchy of classes becomes much less
> > important. You should be able to mix and match beads from different
> SWCs
> > if they conform to expected interface contracts. Those
> > contracts/interfaces, and a few base implementations of those
> contracts are
> > what is supposed to go in Core (and in the ".core." package. But
> the beads
> > can go where it organizationally makes sense and it does not make a
> bead
> > "Core" by having some other SWC us it. Basic beads are supposedly
> the
> > simplest versions that work cross-platform.
> >
>
> for example in Basic a concrete bead can add an attribute to a Basic
> Component. In Jewel the same bead can solve the problem adding a class
> to
> the positioner. For that reason, normaly Jewel needs its own
> ecosystem. I
> already worked many weeks (and before many months when creating MDL)
> and
> have the experience that others doesn't have here to know the problems
> I
> found, and remember that we discussed some weeks ago about if Jewel
> will be
> better subclassing UIBase instead its counter part control or
> component in
> Basic, and then my conclusion in that thread was that it was better to
> subclass UIBase.
>
> Antoher thing is that I don't want a future change in a control in
> Basic
> could introduce a bad behavior in Jewel. For this reason I think the
> basic
> building block or Core is UIBase.
>
>
>
> >
> > -If you need to extend a bead, subclassing or utility functions are
> > preferred in order to reduce maintenance overhead of having copies
> of code.
> >
>
> I subías core things (like GroupView that before was in Basic) or
> implemente core interfaces (IBeadView), I think that's core, but I
> don't
> believe in subclass final functionality (control, component, bead or
> whatever) since as final implementations, can change over time and
> break
> Jewel functionality. For me that's not a good practice.
>
>
> >
> > -I still think we are missing a clear, detailed, example of a Jewel
> bead
> > that is a different implementation of a Basic bead that required
> copying
> > code from the Basic bead.
> >
> >
> As UI Sets are siblings and they are not related anymore, If I start
> copying a code from Basic to start, I think is the good way to go
> although
> finaly the class remains with the same code. Think that Jewel would
> never
> link Basic, so there's no other way to have that functionality than
> create
> is own.
>
>
> > -A good teammate tries to maximize his/her positive impact on the
> rest of
> > the team, and minimize the negative impact, and cares less about
> personal
> > goals.
> >
>
> That was my code of conduct until I saw people in this team with the
> opinion that they can dictate the things to do and revert a complete
> work.
> Or talk about that I should move from the project and fork it. Just
> when I
> think this year I'm donating all my time to this project while the
> people
> proposing that are only appearing from time to time. I never saw that
> in
> any other project and I think we are repeating things of the past we
> other
> now gone mates. So maybe we should think about why people abandone
this
> project or we want ro remove them. If I'm a bit upset I think I have
> complete valid reasons.
> So in the first emails of this thread, I was working hard to
understand
> problems arise, and working hard to solve them. But what I see is
> people
> not only not helping to fix builds or fix the points that could be
> having
> problems, but discussing if my way of thinking about the new Jewel UI
> Set
> is right or wrong, while I only want to isolate from other libraries.
> Those
> people should not opposite that and only left Royale can do that since
> is
> beneficial to the project and since from now on, we will see less
> problems
> with shared resources (another thing is if shared resources makes
> people
> discuss many times, maybe should not be shared )
>
>
> >
> > So, let's get some real data, and see if we can reach agreement on
> the
> > semantics of what Core is. Then we can discuss how we'd reorganize
> the
> > SWCs.
> >
>
> Alex, IMHO, I think we should:
>
> 1.- Fix JSONLY, I don't know why is falling, don't know how I can
build
> that localy with maven. If you give some clues on this I can work on
> fix
> that.
> 2.- With all fixed, we can think more about what goes in Core and what
> in
> Basic. My only point is that Jewel doesn't have to depend on Basic.
>
> I think we need 1. fixed ASAP, since I think Harbs App maybe depends
on
> that (don't know if he is using maven build or what, but for what I
> see he
> can not build or maybe is ANT failing, I think we need to catch those
> deficiencies in the build since are more important that change classes
> from
> a library to another) ...and then 2. can be do it in a more relaxed
way
> since all people will have the current build fixed (JSONLY, since the
> normal works)
>
> Thanks
>
>
> >
> > Thanks,
> > -Alex
> >
> >
> > On 5/10/18, 7:09 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira" <carlos.rov...@gmail.com on behalf of
> carlosrov...@apache.org>
> > wrote:
> >
> > Hi Harbs
> >
> > 2018-05-10 15:55 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> >
> > > Carlos,
> > >
> > > It’s impossible to move the entire Basic (non-components) into
> Core.
> > > Besides the fact that there’s no reason to inflate Core that
> much,
> > there’s
> > > many pieces (in beads, renderers, etc.) which rely on things
> which
> > are
> > > *not* Core.
> > >
> > > Core has 0 dependencies on other projects (except Language — I
> > think).
> > > Many pieces of Basic have dependencies on other pieces such as
> > Collections,
> > > Binding, Network, etc.
> > >
> > > Ideally, the library swcs should be as small as possible. You
> are
> > > proposing making Core bigger. I oppose that idea. Basic is
> quite
> > large. I
> > > would support an idea of breaking Basic into smaller pieces
> although
> > I have
> > > higher priority things on my list personally.
> > >
> >
> > I really prefer to stick like its now and simple fix the JSOnly
> build.
> > I
> > think is the fastest thing we can do. I was talking about this
> since
> > you
> > propose to break basic in two. and maybe is not needed at least
> at this
> > time. If I continue to work on Jewel and find more things that I
> need
> > from
> > Basic (and that should be basic we can talk about that)
> >
> >
> > >
> > > When Alex and others have been saying that Basic is just
> another
> > component
> > > set, I believe that was just referring to the components in
> Basic.
> > The
> > > building blocks in Basic are another story altogether. The
vast
> > majority of
> > > Basic is the building blocks and not the components. If folks
> like
> > the idea
> > > of moving the Basic components into their own swc, that’s
> something
> > I’d
> > > support. Moving building blocks into Core to prevent
> dependencies is
> > *not*
> > > something I support. Your refactor is by no means
> comprehensive and
> > I don’t
> > > want to go down the path of making it so.
> > >
> >
> > but not doing so will left the Jewel project again with the same
> > problems,
> > just because you have a philosophical point of view. Since in
> this
> > concrete
> > point, mine is technical in its totality.
> >
> >
> > >
> > > You also changed package names and that deserves a separate
> > discussion. If
> > > changing the package names makes things clearer, I’d support
> that.
> > I’m not
> > > sure that it does. Besides moving things from html to core,
you
> > removed
> > > beads from package names. Many pieces still have the html path
> and
> > there’s
> > > currently no consistency that I can see.
> > >
> >
> > package names can be reverted, I think that's not completely
> needed. I
> > did
> > to avoid the actual mess of "core" and "html" packages around
> Basic and
> > Core. My opinion is that Core should have only "core" package
> and Basic
> > should have only "basic" (and not "core" nor "html")
> > But this is not critical for me, and I can live with it, but
> this rise
> > one
> > clear thing, that if the build works, you only need to change
you
> > Application in a few places where the package changed. And that
> should
> > be
> > possible so Royale has a better organization of packages.
> >
> >
> >
> > >
> > > My $0.02,
> > > Harbs
> > > > On May 10, 2018, at 4:33 PM, Carlos Rovira <
> > carlosrov...@apache.org>
> > > wrote:
> > > >
> > > > 2018-05-10 14:30 GMT+02:00 Harbs <harbs.li...@gmail.com
> <mailto:
> > > harbs.li...@gmail.com>>:
> > > >
> > > >> Top posting to make it easier on the eyes:
> > > >>
> > > >>> For me 3,5,7 are not something about "philosophy", are
pure
> > technical
> > > >>> structuration of code. If you want to left as is, is
> because
> > you're
> > > >> talking
> > > >>> from an Application ser not from an archictecture point of
> view
> > or with
> > > >> the
> > > >>> team member hat.
> > > >>
> > > >> Maybe philosophical was not the best word, but my point
> remains.
> > Your
> > > >> arguments are centered around the fact that you believe
> Basic to
> > be a
> > > >> component set similar to Jewel. Others have been
> disagreeing with
> > this
> > > >> point of view.
> > > >>
> > > >> I have been working on the assumption that Core is really
> > bare-bones
> > > >> functionality which is not directly related to any specific
> way of
> > > >> implementing anything.
> > > >>
> > > >
> > > > Until now the concept was that Basic was an UI set, and for
> that
> > reason
> > > > HTML was separated, since was the set of html tags like
span,
> > h1-h6, div.
> > > > So Core and Basic words in your understanding wants to refer
> to
> > the same
> > > > and if what you want to left in Basic is not UI components,
> then
> > that
> > > seems
> > > > to be Core classes that in fact other sets like Jewel could
> need,
> > so as I
> > > > said, I think is better to have one single Core library for
> all
> > that is
> > > > core or basic (in the means of core)
> > > >
> > > >
> > > >>
> > > >> Basic is “core” in the same way that DataBinding, Network
> > Collection,
> > > etc.
> > > >> is “core”. The assumption is that almost all applications -
> no
> > matter
> > > which
> > > >> component set is being used will require Basic. To me,
> Basic means
> > > “basic
> > > >> functionality” and not “basic components”. Maybe it was a
> mistake
> > to
> > > have
> > > >> Basic include Components at all because that’s what seems
> to be
> > causing
> > > the
> > > >> disconnect here. I don’t think it’s practical or desirable
> to
> > move all
> > > the
> > > >> “core” pieces of Basic to Core.
> > > >>
> > > >
> > > > notice that "basic functionality" can be easily think about
> it as
> > "core
> > > > functionality", I think we are talking about the same.
> > > >
> > > >
> > > >
> > > >>
> > > >>>> #2 AFAICT includes #4. As I mentioned the fact that there
> can be
> > > >>>> conflicting typenames is a problem. Removing Basic as a
> > dependency
> > > will
> > > >> not
> > > >>>> solve that problem because clients can (and likely will)
> bring
> > in
> > > Basic
> > > >> as
> > > >>>> part of their application.
> > > >>>>
> > > >>>
> > > >>> There's much difference in obligation to link a library
and
> > decision to
> > > >>> make part of your solution. We as Royale PMCs should make
> the
> > best for
> > > >> not
> > > >>> obligate, the user is how could want then to use Jewel,
> MDL and
> > Basic
> > > all
> > > >>> together. Is up to them.
> > > >>
> > > >> I’m not sure what you are trying to say here. My point is
> that an
> > > >> application bringing in Basic should not cause Jewel
> components to
> > > break. I
> > > >> assume you’d agree with me on that.
> > > >>
> > > >
> > > > I agree that If I link Basic that should not make a
> difference.
> > > > But the point is that not only makes a difference linking
> things I
> > don't
> > > > want, but that I'm obligated to link that library, and I
> shouldn't
> > since
> > > > right now Basic is more than a Core library is a library
> that has
> > core+ui
> > > > components+css, so that is completely wrong by design.
> > > >
> > > >
> > > >>
> > > >>>> I really don’t understand your point with #6. Why do
> application
> > > >>>> developers need to think about dependencies? Is it
> because of
> > Maven
> > > >>>> dependencies? If so, that seems to be a Maven problem
> which
> > should be
> > > >> fixed
> > > >>>> there.
> > > >>>>
> > > >>>
> > > >>> Not App developers, We are how need to be careful on this.
> In
> > the same
> > > >> way
> > > >>> we are pushing hard on PAYG, to avoid mistake of the past
> like
> > 15k
> > > lines
> > > >>> UIComponent class, We need to always be careful and don't
> make
> > unneeded
> > > >>> relations. And Basic -Jewel is totally unneeded.
> > > >>
> > > >> Well, Basic *was* needed before you made your changes and
> the
> > assumption
> > > >> is that it usually *will* be needed because it’s the basic
> > building
> > > blocks
> > > >> of applications. Moving things to Core as component sets
> need
> > them seems
> > > >> like a bad thing to do. Why do we need to be careful about
> > including
> > > Basic?
> > > >> This seems more like a philosophical argument than a
> technical
> > one.
> > > >>
> > > >
> > > > I found in my refactor that many examples have Basic
> dependency
> > missing
> > > ( I
> > > > think that can be mainly the problem with JSONLY build
> failing),
> > that was
> > > > due to HTML pulling Basic. That means that the build was a
> wrong
> > > > configuration and as HTML left away its Basic dependency
> projects
> > that
> > > > really need Basic was failing, so I added it specifically.
> So here
> > > there's
> > > > nothing philosophical, but a problem about structure and
> > organizations.
> > > >
> > > >
> > > >>
> > > >>>>
> > > >>>> Please explain why you think $8 is true. What about the
> > refactoring
> > > will
> > > >>>> reduce the size of applications?
> > > >>>>
> > > >>>
> > > >>> I explained just in a Yshay response. copying the entire
> email
> > response
> > > >>> here. But rather to make me repeat or copy I though you
> read all
> > this
> > > >>> thread carefully:
> > > >>
> > > >> OK. So this goes back to the CSS. I thought you were
talking
> > about code.
> > > >>
> > > >> I already agreed with you that unnecessary copying of CSS
> is bad.
> > I just
> > > >> think it’s something which should be solved in the
> compiler. Can
> > you
> > > think
> > > >> of a reason why it can’t/shouldn’t be a compiler problem?
> > > >>
> > > >
> > > > As I said in my explanation to Yishay, before the refactor I
> was
> > using
> > > the
> > > > "building blocks" in Basic, and that was pulling all
> dependencies,
> > so as
> > > I
> > > > break Jewel dependency, and remove the dependency from Basic
> > components
> > > and
> > > > building blocks so don't know if there's a compiler problem
> or
> > not, but
> > > > what I know for sure is that this kind of linkage of unused
> or not
> > needed
> > > > libraries with the time makes people mix inheritance chains
> since
> > the
> > > > classes are avaialble and then that caused that kind of
> > dependencies. So
> > > > for me one thing to do to prevent this kind of problems is
> simply
> > not
> > > link
> > > > the libraries that should not be used
> > > >
> > > > Thanks
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > >>
> > > >> Thanks,
> > > >> Harbs
> > > >>
> > > >>> On May 10, 2018, at 3:02 PM, Carlos Rovira <
> > carlosrov...@apache.org
> > > <mailto:carlosrov...@apache.org>>
> > > >> wrote:
> > > >>>
> > > >>> 2018-05-10 13:41 GMT+02:00 Harbs <harbs.li...@gmail.com
> <mailto:
> > > harbs.li...@gmail.com> <mailto:
> > > >> harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>>:
> > > >>>
> > > >>>> Hi Carlos,
> > > >>>>
> > > >>>> Thank you for summarizing your reasons. I appreciate it.
> > > >>>>
> > > >>>> Please allow me to categorize your reasons. Please let me
> know
> > if I’m
> > > >> not
> > > >>>> categorizing them correctly.
> > > >>>>
> > > >>>> When I mentioned reason #1, I think it includes:
> > > >>>> #3, #5 and #7
> > > >>>>
> > > >>>
> > > >>> For me 3,5,7 are not something about "philosophy", are
pure
> > technical
> > > >>> structuration of code. If you want to left as is, is
> because
> > you're
> > > >> talking
> > > >>> from an Application ser not from an archictecture point of
> view
> > or with
> > > >> the
> > > >>> team member hat.
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> #2 AFAICT includes #4. As I mentioned the fact that there
> can be
> > > >>>> conflicting typenames is a problem. Removing Basic as a
> > dependency
> > > will
> > > >> not
> > > >>>> solve that problem because clients can (and likely will)
> bring
> > in
> > > Basic
> > > >> as
> > > >>>> part of their application.
> > > >>>>
> > > >>>
> > > >>> There's much difference in obligation to link a library
and
> > decision to
> > > >>> make part of your solution. We as Royale PMCs should make
> the
> > best for
> > > >> not
> > > >>> obligate, the user is how could want then to use Jewel,
> MDL and
> > Basic
> > > all
> > > >>> together. Is up to them.
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> I really don’t understand your point with #6. Why do
> application
> > > >>>> developers need to think about dependencies? Is it
> because of
> > Maven
> > > >>>> dependencies? If so, that seems to be a Maven problem
> which
> > should be
> > > >> fixed
> > > >>>> there.
> > > >>>>
> > > >>>
> > > >>> Not App developers, We are how need to be careful on this.
> In
> > the same
> > > >> way
> > > >>> we are pushing hard on PAYG, to avoid mistake of the past
> like
> > 15k
> > > lines
> > > >>> UIComponent class, We need to always be careful and don't
> make
> > unneeded
> > > >>> relations. And Basic -Jewel is totally unneeded.
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> Please explain why you think $8 is true. What about the
> > refactoring
> > > will
> > > >>>> reduce the size of applications?
> > > >>>>
> > > >>>
> > > >>> I explained just in a Yshay response. copying the entire
> email
> > response
> > > >>> here. But rather to make me repeat or copy I though you
> read all
> > this
> > > >>> thread carefully:
> > > >>>
> > > >>> "I think the problem is that Basic UI set links things
> through
> > CSS, so
> > > >> If I
> > > >>> have Application, Group, View, Button all this components
> and
> > more has
> > > >> CSS
> > > >>> that links beads (ViewBeads, ModelBeads, ControllerBeads,
> and
> > more)
> > > >>>
> > > >>> In Jewel until the refactor the components where
> sublcassing
> > Basic
> > > ones,
> > > >>> and this made all this classes go in the Jewel
> Application, and
> > that
> > > not
> > > >>> only introduced more size but makes the behaviour
> unexpected
> > since I
> > > find
> > > >>> css styles and linked classes modifying the Jewel
Behavior.
> > > >>>
> > > >>> Now that Jewel is not depending on Basic anymore, since it
> > should be,
> > > all
> > > >>> works perfect.
> > > >>>
> > > >>> I think this is key, in a tree graph we should envision,
> Core as
> > the
> > > root
> > > >>> of the tree, and when coming to UI sets that in royale we
> > coincide in
> > > >>> having many of them, one should not depend from the other.
> And by
> > > design
> > > >>> that's important, and will prevent people in the future to
> come
> > back to
> > > >>> make relations between them. In fact Alex, said many times
> the
> > errors
> > > >>> coming from 15k lines of code in UIComponent in Flex. If
> we left
> > UI
> > > sets
> > > >>> depend at library level, people can start to make that
> kind of
> > > extension,
> > > >>> and that should not be doable by design."
> > > >>>
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> As I mentioned earlier, Basic is not simply a component
> set.
> > It’s
> > > also a
> > > >>>> set of building-blocks which can and should be used in
> other
> > component
> > > >>>> sets. Devision between Core and Basic is not as clear-cut
> as
> > you seem
> > > >> to be
> > > >>>> asserting that it is. After your refactor the building
> blocks
> > seem to
> > > be
> > > >>>> split between Core and Basic.
> > > >>>>
> > > >>>
> > > >>> That's not what I talked in the past in this mailing list.
> Alex
> > said
> > > that
> > > >>> people would want to use Basic for things very basic and
> more
> > complex
> > > UI
> > > >>> sets for other things. In fact Jewel born to be more
visual
> > attractive,
> > > >> so
> > > >>> for Jewel, all building block regarding UI should be from
> > itself, and
> > > >>> prevent to mix with things in Basic that will (or could)
> evolve
> > in
> > > other
> > > >>> way.
> > > >>>
> > > >>> My refactor was searching a goal, separation. But as many
> things
> > can
> > > not
> > > >> be
> > > >>> final. After it, we can think a bit more on how things are
> > settle now,
> > > >> and
> > > >>> continue to improve it, to make Core real core, and Basic
> a UI
> > set that
> > > >>> could be has it's own essence without make it to mix in
> other
> > libraries
> > > >>> that should not need it.
> > > >>> I think we should continue improving this instead of
> wanting
> > again to
> > > >> have
> > > >>> a mess between all this libraries and packages mixed in
> > libraries like
> > > >> core
> > > >>> and html.
> > > >>>
> > > >>> But for this to happen, we must focus in why the JSONLY
> build is
> > > >> different
> > > >>> from the main one, and if ANT fails, that shouldn't, that
> I'm
> > still
> > > don't
> > > >>> know if we have a problem there
> > > >>>
> > > >>> thanks
> > > >>>
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> Thanks,
> > > >>>> Harbs
> > > >>>>
> > > >>>>> On May 10, 2018, at 2:13 PM, Carlos Rovira <
> > carlosrov...@apache.org
> > > <mailto:carlosrov...@apache.org>>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> Hi Harbs
> > > >>>>>
> > > >>>>> after 75 emails on this thread, understand that I don't
> want
> > to again
> > > >>>> write
> > > >>>>> it, since this is making me waste lots of time in this
> > discussion.
> > > >>>>>
> > > >>>>> 3) Having the need to link a library that should not be
> used,
> > is that
> > > >>>>> something is wrong, so it's not about 1) it's about
> things are
> > not
> > > >>>> setting
> > > >>>>> correctly, and this refactor tries to fix that at least
> to put
> > a
> > > point
> > > >> in
> > > >>>>> wich we can make things better.
> > > >>>>> 4) aside 2, some classes are linked via CSS as well
> > (Application,
> > > >> Group,
> > > >>>>> Container, Button, Slider, and many more
> > > >>>>> 5) Having Basic to be a core dependency, makes it Core
in
> > itself, so
> > > >> why
> > > >>>>> the separation Core- Basic if I'm obligated to link it?
> > > >>>>> 6) Making Basic not present in libraries that doesn't
> need it,
> > makes
> > > >>>> people
> > > >>>>> obligated by design to avoid extend Basic classes making
> the
> > effect
> > > but
> > > >>>>> time that things mess between libraries, and obligates
> SDK
> > developers
> > > >> to
> > > >>>>> think about the using of classes, since if we need some,
> maybe
> > that
> > > >> will
> > > >>>> be
> > > >>>>> Core and not Basic
> > > >>>>> 7) Basic is only another UI set at the same level or
> sibling
> > like
> > > >> Jewel,
> > > >>>>> MDL, CreateJS, Flat, and more we want to do, until now
> was very
> > > needed,
> > > >>>> but
> > > >>>>> if we want to make Royale to serve general purpose,
> making it
> > to be
> > > >>>> present
> > > >>>>> always is not the right way to go.
> > > >>>>> 8) reduced size in final jewel applications.
> > > >>>>>
> > > >>>>> I think for sure I put more things on the plate, but
> can't
> > invest now
> > > >> the
> > > >>>>> time to go all 75 emails to retrieve it
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> 2018-05-10 12:48 GMT+02:00 Harbs <harbs.li...@gmail.com
> > <mailto:
> > > harbs.li...@gmail.com>>:
> > > >>>>>
> > > >>>>>> The only reasons I seem to have seen are:
> > > >>>>>> 1. A philosophical opposition to having Basic as a
> dependency.
> > > >>>>>> 2. Not wanting Basic CSS included in a Jewel project.
> > > >>>>>>
> > > >>>>>> Unless I’m missing something, #1 I simply disagree
with.
> > > >>>>>> #2 sounds like a valid argument, but it seems to me
> more like
> > > >> something
> > > >>>>>> which needs to be fixed in the compiler. CSS not used
> by an
> > app
> > > should
> > > >>>> not
> > > >>>>>> be included and I think we need a way of avoiding
> typename
> > conflicts
> > > >>>>>> between component sets.
> > > >>>>>>
> > > >>>>>> Are there other arguments which I missed?
> > > >>>>>>
> > > >>>>>> Since Carlos does not seem to want to explain himself
> again,
> > I’m
> > > >> asking
> > > >>>>>> others on the list:
> > > >>>>>>
> > > >>>>>> Do others understand why Carlos feels the refactor is
> > important?
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Harbs
> > > >>>>>>
> > > >>>>>>> On May 10, 2018, at 1:32 PM, Carlos Rovira <
> > > carlosrov...@apache.org <mailto:carlosrov...@apache.org>>
> > > >>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Can we please keep this discussion about the
technical
> > reasons
> > > for a
> > > >>>>>>>> refactor and whether or not it’s the right thing to
> do? If
> > you
> > > have
> > > >>>>>> strong
> > > >>>>>>>> technical reasons why Basic should not be a
dependency
> > please
> > > >> explain
> > > >>>>>> them.
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> Harbs, I'll explained lots of time, and you keep ask
> the
> > same. What
> > > >> did
> > > >>>>>> you
> > > >>>>>>> not understand of the things I expressed so many time?
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Carlos Rovira
> > > >>>>> https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C66a64d9fd15242f99c3808d5b6bc0fa6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615841189069933&sdata=Df6ouzrzcDFDizCyw2siNJorm6lLTNND3hoXcT2fl7o%3D&reserved=0.
> protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&
> data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=
> bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> > protection.outlook.com/?url=http%3A%2F%2Fabout.me%
> > 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Carlos Rovira
> > > >>> https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C66a64d9fd15242f99c3808d5b6bc0fa6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615841189069933&sdata=Df6ouzrzcDFDizCyw2siNJorm6lLTNND3hoXcT2fl7o%3D&reserved=0.
> protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&
> data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=
> bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> > protection.outlook.com/?url=http%3A%2F%2Fabout.me%
> > 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0> <
> > > https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C66a64d9fd15242f99c3808d5b6bc0fa6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615841189069933&sdata=Df6ouzrzcDFDizCyw2siNJorm6lLTNND3hoXcT2fl7o%3D&reserved=0.
> protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&
> data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=
> bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> > protection.outlook.com/?url=http%3A%2F%2Fabout.me%
> > 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0>>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com%7C66a64d9fd15242f99c3808d5b6bc0fa6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615841189069933&sdata=Df6ouzrzcDFDizCyw2siNJorm6lLTNND3hoXcT2fl7o%3D&reserved=0.
> protection.outlook.com/?url=https%3A%2F%2Fna01.safelinks&
> data=02%7C01%7Caharui%40adobe.com%7C11b8779036f342addf6e08d5b6a01888%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615721089819822&sdata=
> bxWUPeO%2Fg8H0mS9nEBEDpvx1kOJlUM5vVNHy%2F2beFF8%3D&reserved=0.
> > protection.outlook.com/?url=http%3A%2F%2Fabout.me%
> > 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0>
> > >
> >
> >
> >
> > --
> > Carlos Rovira
> > https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%
> 40adobe.com%
> > 7Ce9ca176a8e2c421af01808d5b67fa049%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636615581733737384&sdata=%
> 2FUMMZVm7L5g5MbXsU4BfMrqvcz1GJ
> > xBeR27Le1U3toE%3D&reserved=0
> >
> >
> >
>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7C11b8779036f342addf6e08d5b6a01888%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636615721089819822&sdata=qolRT2SS43TM1bv%2BF92mMJb%
> 2Fd9jD6TltxMXw8hjG6hA%3D&reserved=0
>
>
>
--
Carlos Rovira
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C66a64d9fd15242f99c3808d5b6bc0fa6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636615841189069933&sdata=xt3tEiphcyE6Dk61NV2UDMCWeycNWArXBuBPAaM95BE%3D&reserved=0
