royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: Container change
Date Thu, 10 May 2018 19:23:34 GMT
Hi Harbs,

2018-05-10 20:44 GMT+02:00 Harbs <harbs.lists@gmail.com>:

> Hi Carlos,
>
> I’d like to be clear about one thing:
>
> I have had my app break *many* times while we’ve been developing Royale
> and changing things. That’s OK. That’s part of the cost of working on the
> bleeding edge. I’m fine adjusting things to invest in improving our
> framework.
>
> I only have trouble if the changes are not warranted. I’m not convinced
> that these changes were warranted. We also agreed about a half a year ago
> that all breaking changes should be done in a feature branch. That’s
> something we’ve been pretty good at in general lately. We all agree that it
> was a mistake to make these changes on the develop branch, but mistakes
> happen and and let’s work with that.
>

If you see the I really did a feature branch...only that it was only one
commit and then merged. then I did one commit more for a thing I forget,
and then I was fixing things you and others say.


>
> Instead of pointing fingers, let’s try to focus on the technical reasons
> for refactoring and figuring out how and where refactoring should be done
> (if at all). If a refactor breaks my app(s), I’ll deal with it. But, let’s
> please first come to an agreement on what is best to do on technical merit.
>
>
but I expressed largely about the technical merit, for 90 emails in this
thread. You talk about this philosophic and I pointed you many tangible
technical reasons, and in opposite, you only give me philosophical reason
on your part...



> I’m making an effort to be quiet now to get input from others. I think
> I’ve already said pretty much what I’ve had to say.
>

I spent all the they with this, and I'm really upset on how my work is
saw...


>
> If you want my response on specific points, please let me know and I’ll
> respond to them.
>
> Thanks,
> Harbs
>
> > On May 10, 2018, at 9:01 PM, Carlos Rovira <carlosrovira@apache.org>
> wrote:
> >
> > Hi Alex,
> >
> > 2018-05-10 18:50 GMT+02:00 Alex Harui <aharui@adobe.com.invalid <mailto:
> aharui@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.rovira@gmail.com on behalf of Carlos
> >> Rovira" <carlos.rovira@gmail.com on behalf of carlosrovira@apache.org>
> >> wrote:
> >>
> >>    Hi Harbs
> >>
> >>    2018-05-10 15:55 GMT+02:00 Harbs <harbs.lists@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 <
> >> carlosrovira@apache.org>
> >>> wrote:
> >>>>
> >>>> 2018-05-10 14:30 GMT+02:00 Harbs <harbs.lists@gmail.com <mailto:
> >>> harbs.lists@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 <
> >> carlosrovira@apache.org
> >>> <mailto:carlosrovira@apache.org>>
> >>>>> wrote:
> >>>>>>
> >>>>>> 2018-05-10 13:41 GMT+02:00 Harbs <harbs.lists@gmail.com <mailto:
> >>> harbs.lists@gmail.com> <mailto:
> >>>>> harbs.lists@gmail.com <mailto:harbs.lists@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 <
> >> carlosrovira@apache.org
> >>> <mailto:carlosrovira@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.lists@gmail.com
> >> <mailto:
> >>> harbs.lists@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 <
> >>> carlosrovira@apache.org <mailto:carlosrovira@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=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=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=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=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
> > http://about.me/carlosrovira <http://about.me/carlosrovira>
>



-- 
Carlos Rovira
http://about.me/carlosrovira

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