royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: Container change
Date Thu, 10 May 2018 11:41:33 GMT
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

When I mentioned reason #1, I think it includes:
#3, #5 and #7

#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.

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.

Please explain why you think $8 is true. What about the refactoring will reduce the size of

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.


> On May 10, 2018, at 2:13 PM, Carlos Rovira <> 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 <>:
>> 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 <>
>> 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

View raw message