commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math][proposal] Drop serialization from selected classes
Date Mon, 24 May 2004 22:45:12 GMT
I'd like to clarify my position in more detail because it is not 100% -1 
on removing Serialization Interfaces. There are items on the list for 
which I agree serialization can/should be removed.

1.) Its ok to remove Serialization from Factories which are not 
instantiated.

2.) Its ok to remove Serialization from Abstract classes.

3.) StaticUtils don't benefit from serialization, I didn't see any with 
it present within them. If you see any, feel free to remove the 
Serialization Interface from them.




I would very much prefer to see Serialization interfaces maintained on 
all non-Abstract implementation classes so that the API can be used 
within applications which take advantage of Serialization.


a.) Abstract Classes in which Serialization interface can be removed 
without impact to overall serialization of API:

o.a.c.m.analysis.UnivariateRealSolverImpl
o.a.c.m.stat.univariate.SummaryStatistics
o.a.c.m.stat.univariate.DescriptiveStatistics


b.) Classes I would like to maintain Serialization on (and for which its 
pretty much zero effort).

o.a.c.m.analysis.
  BisectionSolver
  BrentSolver
  NewtonSolver
  PolynomialFunction
  PolynomialSplineFunction
  SecantSolver
  SplineInterpolator
  UnivariateRealSolverFactoryImpl --> Instantiable Factory

o.a.c.m.complex.
  Complex
  ComplexFormat

o.a.c.m.distribution.
  BinomialDistributionImpl
  ChiSquaredDistributionImpl
  DistributionFactoryImpl --> Instantiable Factory
  ExponentialDistributionImpl
  FDistributionImpl
  GammaDistributionImpl
  HypergeometricDistributionImpl
  NormalDistributionImpl
  TDistributionImpl

o.a.c.m.linear
  RealMatrixImpl

o.a.c.m.random
  EmpiricalDistributionImpl (Pluse inner classes)
  RandomDataImpl

o.a.c.m.stat
  Frequency

o.a.c.m.stat.inference
  ChiSquareTestImpl
  TTestImpl

o.a.c.m.stat.multivariate
  BivariateRegression

o.a.c.m.stat.univariate
  DescriptiveStatisticsImpl
  StatisticalSummaryValues
  SummaryStatisticsImpl

o.a.c.m.stat.univariate.xxx (All classes)

o.a.c.m.util
  ContinuedFraction
  ContractableDoubleArray
  DefaultTransformer
  ExpandableDoubleArray
  FixedDoubleArray
  TransformerMap


c.) With very little effort I can make the following Serializable such 
that the Replayable Data Streams can be recovered and continued on from 
given the presence of the Datasource is available.

o.a.c.m.random
  ValueServer


So, to review Phil's list:

> AbstractDescriptiveStatistics

+1


> BisectionSolver
> BrentSolver
> ChiSquareTestImpl
> DefaultTransformer

-1


> DescriptiveStatistics

+1


> DescriptiveStatisticsImpl
> DistributionFactoryImpl
> Erf
> Gamma
> NewtonSolver
> SecantSolver
> SplineInterpolator
> SummaryStatisticsImpl
> TTestImpl
> TransformerMap
> UnivariateRealSolverFactoryImpl

-1


> UnivariateRealSolverImpl

+1


> ValueServer 

-0 (I can make it Serializable if you like)


-Mark

p.s. As a reminder, I've serailversionUID's generated for all these 
files now.


Mark R. Diggory wrote:
> Phil Steitz wrote:
> 
>> Since implementing Serializable requires that all subclasses also 
>> implement serializable and that care be taken to ensure backward 
>> serialization compatability, my view is that we should implement 
>> Serializable iff there is a reason to do so, not by default for all 
>> classes. 
> 
> This is not true, you only have to implement serializable in your 
> subclass if you want to support serialization, there is no requirement 
> that you are forced to do so because the parent class implements it. It 
> is completely transparent to the user in this reguard.
> 
>> I am interested in others' views on this.   Maybe I am missing 
>> something, but I see no value in implementing Serializable for 
>> factories, abstract classes, utility classes and such.
>>  
>>
> Yes, I'll agree for abstracts, its not really neccessary, it was more a 
> practice on my part to confirm that they were truly serializable. I also 
> agree its probibly not very important for factories, but its a 
> no-brainer, effects very little in terms of source code and performance 
> and is a very simple thing toi maintain. Arguing that this creates all 
> kinds of headaches is really a "Red Herring". I spent an hour on it this 
> afternoon and can confidently state that our API can easily support it 
> without headaches to anyone. Removing it only steps on peoples toes in 
> the long run.
> 
> -1 on removing Serialization Interfaces.
> 
> Mark
> 
>>
>> Phil
>>
>>     -----Original Message-----     From: Mark R. Diggory 
>> [mailto:mdiggory@latte.harvard.edu]     Sent: Mon 5/24/2004 12:31 PM 
>>     To: Jakarta Commons Developers List     Cc:     Subject: Re: 
>> [math][proposal] Drop serialization from selected classes
>>     
>>     
>>
>>     Just to give an update, I generated serialversionUID's for all the
>>     current Serializable classes in the src/java directory for which they
>>     were absent. I'm just waiting on our clarifying the decision prior
>>     committing everything. I am currently working on a serialization
>>     solution for the ValueServer/EmpiricalDistribution classes.
>>     
>>     -Mark
>>     
>>     
>>  
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message