Sharing Basic code with other component sets (Was Re: [Discuss] Trying to discern between High-level abstraction...)

[Alex Harui <ah...@adobe.com.INVALID>]

Forking for this particulare topic:

On 12/24/19, 6:46 AM, "Carlos Rovira" <ca...@apache.org> wrote:

    ...Why I think we need to solve is if we have a better way
    to extend UIBase, better than StyledUIBase path, since I'm not very happy
    with it.
    
    The worst problem I see is that all we can do in UIBase, other UI sets will
    need to add in at least 4 points:
    
    
       - An UIBase extension
       - A Group extension
       - A Container extension
       - A DataContainerBase extension
    
    It's that right? or do you see other way, less complicated to add new
    functionality to a visual element?
    
I have not looked at Jewel's code.  What ended up needing to be copied?

There might be other issues causing pain here.  For example, I wouldn't be surprised if we've unintentionally used concrete classes instead of interfaces in places in Basic.

On the other hand, the MXRoyale and SparkRoyale components are good indicators that composition is working reasonably well in Basic.  Lots of Basic classes are repurposed on top of a completely different class hierarchy although UIBase is at the bottom.  IOW, MX and Spark Containers and Groups do not subclass Basic's Containers and Groups.  Things are re-composed.

That said, there is still a fair amount of duplicated code scattered around the repo.  If it weren't for function call overhead, I'd be tempted to move more method bodies into re-usable utility functions, plus, those functions lose scope.  Injecting code into classes generally has too much overhead and I prefer "sealed classes" over runtime-modifiable definitions (Java Aspects) for code-security reasons, but on the other hand, we might consider getting the compiler to do compile-time code injections.

Also, I compiled HelloWorld the other day and HelloWorld.js in bin/js-release was more than 90K.  That made me very sad.  I could swear the original prototype was 27K, possibly less.  We've more than tripled the amount of useless code.  If I ever find time, I'm going to go pruning again.  And having more options on how to use composition will probably help here as well.

I may be slow in keeping up on this fork because of the holidays and some other pressing issues, but I think it would be good to look at what was needed to get Jewel up and what we might do better.

My 2 cents,
-Alex

Re: Sharing Basic code with other component sets (Was Re: [Discuss] Trying to discern between High-level abstraction...)

[Carlos Rovira <ca...@apache.org>]

Hi Alex,

that would be cool. Jewel is not as purist as Basic in terms of PAYG and
other royale concepts, and don't think it should be. While Basic is the
foundation and should try to focus on that kind of concepts and is at the
start of the chain, Jewel is at the end and that implies to solve specific
problems for the final user. So I tried to balance things when developing
Jewel. For example, enabled/disabled functionality is still a bead since is
used sometimes, but styling though "emphasis" property or "multiline"
property in Label are baked into the components since I expect people using
Jewel will use that not once, but many times in all applications.

Anyway I would like to be able to add some code (like
IClassSelectorSupport) in one point instead to split over some classes. I
understand that I should try to recreate some components (mostly
containers) from interfaces instead of extending Basic ones and have
StyledUIBase be at its Core.

I think we can try to do that refactor as we have time, maybe I can focus
on that part (that could be more straight away for me) and maybe you can
see other points of refactor that ease the pain.

Thanks

Carlos



El mié., 25 dic. 2019 a las 7:48, Alex Harui (<ah...@adobe.com.invalid>)
escribió:

> Forking for this particulare topic:
>
> On 12/24/19, 6:46 AM, "Carlos Rovira" <ca...@apache.org> wrote:
>
>     ...Why I think we need to solve is if we have a better way
>     to extend UIBase, better than StyledUIBase path, since I'm not very
> happy
>     with it.
>
>     The worst problem I see is that all we can do in UIBase, other UI sets
> will
>     need to add in at least 4 points:
>
>
>        - An UIBase extension
>        - A Group extension
>        - A Container extension
>        - A DataContainerBase extension
>
>     It's that right? or do you see other way, less complicated to add new
>     functionality to a visual element?
>
> I have not looked at Jewel's code.  What ended up needing to be copied?
>
> There might be other issues causing pain here.  For example, I wouldn't be
> surprised if we've unintentionally used concrete classes instead of
> interfaces in places in Basic.
>
> On the other hand, the MXRoyale and SparkRoyale components are good
> indicators that composition is working reasonably well in Basic.  Lots of
> Basic classes are repurposed on top of a completely different class
> hierarchy although UIBase is at the bottom.  IOW, MX and Spark Containers
> and Groups do not subclass Basic's Containers and Groups.  Things are
> re-composed.
>
> That said, there is still a fair amount of duplicated code scattered
> around the repo.  If it weren't for function call overhead, I'd be tempted
> to move more method bodies into re-usable utility functions, plus, those
> functions lose scope.  Injecting code into classes generally has too much
> overhead and I prefer "sealed classes" over runtime-modifiable definitions
> (Java Aspects) for code-security reasons, but on the other hand, we might
> consider getting the compiler to do compile-time code injections.
>
> Also, I compiled HelloWorld the other day and HelloWorld.js in
> bin/js-release was more than 90K.  That made me very sad.  I could swear
> the original prototype was 27K, possibly less.  We've more than tripled the
> amount of useless code.  If I ever find time, I'm going to go pruning
> again.  And having more options on how to use composition will probably
> help here as well.
>
> I may be slow in keeping up on this fork because of the holidays and some
> other pressing issues, but I think it would be good to look at what was
> needed to get Jewel up and what we might do better.
>
> My 2 cents,
> -Alex
>
>

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