Administrator

Hey guys,
I was thinking about adding SwingProxyCalculation (see issue 471) and SwtProxyCalculation. So I thought where to put this classes in? Currently, the calculation extension contains all calculations I think. For example, there is a CalculationCategoryDataset for integration with JFreeChart. So, I could put SwtProxyCalculation into the calculation extension and add dependency to SWT. In terms of layering we'd have something like calculation swt  swinglabs  jfreechart  ... core (although calculation does not depend directly on classes of other extensions, but on thirdparty libs). Another way to think about the layering would be: swt  swinglabs  jfreechart  ... calculation core E.g. the calculation extension would only contain the foundation for calculations and each extension could provide its own calculations. In this scenario, CalculationCategoryDataset would belong to the jfreechart extension and SwtProxyCalculation to the SWT extension. This way, the dependencies on thirdparty libs would be more consistent. (We could even think about moving the calculation foundation into core.) I would prefer the second option of layering. What do you think? We then would have factory classes like SwingCalculations SwtCalculations JFreeChartCalculations  or  CalculationsSwing CalculationsSwt CalculationsJFreeChart The first naming convention is more intuive, while the second one is closer to our existing convention (GlazedListsSwing, GlazedListsSwt, ...). What do you prefer? Finally, would it make sense to retrofit the calculations to use functions for the concrete calculation instead of "hardcoding" the calculation into different calculation classes? (Ideally, there would be one ByFunctionCalculation and the factory methods for creating the different calculations would pass in the correct function.) I'm not sure if this would work for all existing calculations, just asking if it makes sense to elaborate this idea... Thanks, Holger 
core > calculation > (other extensions) is the better layering approach IMO.
The goal of "extensions" was/is to bridge from the GL core to another specific library. By keeping extensions separate from each other and separate from the GL core, our build system could one day build "minimal" GL jars for people that didn't care about some of the libraries we bind with (e.g. SWT). Moving calculations into the core build is also not unreasonable... it is a small number of classes and a small size... that is unlikely to grow significantly. So, classes like CalculationsSWT or SWTProxyCalculation are best housed in the SWT extension, as you're proposing. A Functionbased calculation is very natural and makes good sense. One small thing to consider is that you should assume the Function is expensive (imagine it has to loop over all elements to do it's job every time for some reason). In this case, minimizing the number of times we must call the function is a win. Maybe there's some list changes that can be ignored? Maybe there's some data values not considered in the function itself? It's true that subclassing AbstractCalculation is always available for those cases, but use your best judgment to decide if a FunctionCalculation class really does "pull its API weight" and justifies its existence. :) On Sun, Sep 12, 2010 at 3:02 AM, Holger Brands <[hidden email]> wrote: Hey guys, 
Administrator

Thanks for the feedback, James.
See comments inline. 2010/9/13 James Lemieux <[hidden email]> core > calculation > (other extensions) is the better layering approach IMO. Ok. So would you agree to move CalculationCategoryDataset and the factory method from the calculation extension to the freechart extension and to rename SwingCalculations to CalculationsSwing? A Functionbased calculation is very natural and makes good sense. One small thing to consider is that you should assume the Function is expensive (imagine it has to loop over all elements to do it's job every time for some reason). In this case, minimizing the number of times we must call the function is a win. Maybe there's some list changes that can be ignored? Maybe there's some data values not considered in the function itself? It's true that subclassing AbstractCalculation is always available for those cases, but use your best judgment to decide if a FunctionCalculation class really does "pull its API weight" and justifies its existence. :) The idea is that the functions used in the calculations would be reusable in FunctionLists or elsewhere. But you make good points to consider. I'll think more about it, but it's not a priority anyway. Holger

Yes, CalculationCategoryDataset can move to JFreeChart extension. The rename is also fine, for consistency.
You know, it's only legacy reasons that we even have Swing stuff in the GL core. If we were designing from the ground up again, we'd definitely move the link between GL Core and Swing into an extension of its own as well. On Sun, Sep 19, 2010 at 12:16 PM, Holger Brands <[hidden email]> wrote: Thanks for the feedback, James. 
Administrator

Ok, I added SwingThreadProxyCalculation and SWTThreadProxyCalculation with appropriate factory
methods. I also checked in the move of CalculationCategoryDataset and rename of SwingCalculations to CalculationsSwing. Holger 2010/9/20 James Lemieux <[hidden email]> Yes, CalculationCategoryDataset can move to JFreeChart extension. The rename is also fine, for consistency. 
Free forum by Nabble  Edit this page 