One additional point added below:
On 5/10/18, 2:36 PM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
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?
If the technical reason is that you found that it added unnecessary classes to
the application, that should be seen as a bug, and not as a reason to
prioritize component set independence over scalable patterns. We want, in all
use cases, to only bring in classes that are needed. But principles of PAYG,
DRY, and things like that should be first principles. Component set
independence should only happen if it makes sense in the application of those
first principles.
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
