questions concerning calculation extension

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

questions concerning calculation extension

hbrands
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 third-party 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 third-party 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

Reply | Threaded
Open this post in threaded view
|

Re: questions concerning calculation extension

James Lemieux
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 Function-based 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,

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 third-party 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 third-party 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


Reply | Threaded
Open this post in threaded view
|

Re: questions concerning calculation extension

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

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.


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 Function-based 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


On Sun, Sep 12, 2010 at 3:02 AM, Holger Brands <[hidden email]> wrote:
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 third-party 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 third-party 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



Reply | Threaded
Open this post in threaded view
|

Re: questions concerning calculation extension

James Lemieux
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.
See comments inline.

2010/9/13 James Lemieux <[hidden email]>

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.


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 Function-based 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


On Sun, Sep 12, 2010 at 3:02 AM, Holger Brands <[hidden email]> wrote:
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 third-party 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 third-party 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




Reply | Threaded
Open this post in threaded view
|

Re: questions concerning calculation extension

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

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.
See comments inline.

2010/9/13 James Lemieux <[hidden email]>

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.


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 Function-based 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


On Sun, Sep 12, 2010 at 3:02 AM, Holger Brands <[hidden email]> wrote:
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 third-party 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 third-party 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