db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "ModuleVersioningGuidelinesReviewDjd1" by DavidVanCouvering
Date Fri, 23 Sep 2005 04:11:05 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DavidVanCouvering:
http://wiki.apache.org/db-derby/ModuleVersioningGuidelinesReviewDjd1

New page:
This page contains the full discussion of item DJD1 in the ModuleVersioningGuidelinesReview.

'''DJD:''' Don't force commonality just because classes or concepts seem to be somewhat similar.

----

'''JNB:''' PVH is overkill but an int is too simple. I'd rather see a feature mechanism. We
should be concerned about coupling to common due to the versioning mechanism

----

Jeremy then sent an email to clarify:

I mentioned in ModuleVersioningGuidelinesReview about a feature mechanism rather than version
numbers and thought I should probably should explain that more.

The concern I had with version numbering is that there is a lot of implicit information locked
up in a single String or int. As the objective of this is to cater for scenarios where there
is skew between consumer and implementation I think it is better to make this more explicit.

To that end, I was envisioning a mechanism where the consumer could easily check if a specific
feature was provided by the implementation rather than seeing which version was there and
then inferring.

To achieve this, I was thinking the primary interface would have a method like: {{{#!java
   /**
    * @param className the class providing the feature
    * @param featureId the feature to check for
    * @return true if the implementation supports the requested feature
    */
   boolean hasFeature(String className, String featureId)
}}}

This needs to be loosely coupled i.e. featureId Strings would be documented but the consumer
could not rely e.g. on a constant field as that field may not be defined by earlier versions.

----

'''DVC:''' I think you have a good point, Jeremy.  The consumer shouldn't have to calculate
what features are available based on a version number.  This logic should be encapsulated
in the module, not distributed across all the consumers.

I disagree however that the parameters have to be Strings.  Integer constants are compiled
down to simple integers so there will not be a runtime error.  I would prefer integers constants
because it avoids mistakes (which would be very hard to detect, you would just get a "false"
when it should be "true") and allows for faster lookup.  

Here is an example: {{{#!java
  if ( CommonModule.hasFeature(CommonModule.MESSAGE_UTIL, CommonModule.WHIZBANG_FEATURE) )
  {
     MessageUtil.whizbangFeature();
  }
  else
  {
    MessageUtil.ploddingFeature();
  }
}}}

is compiled down to something like {{{#!java
  if ( CommonModule.hasFeature(2, 4) )
  {
    MessageUtil.whizbangFeature();
  {
  else
  {
    MessageUtil.ploddingFeature();
  }
}}}

If it's the old implementation of `CommonModule`, it will see an integer value it doesn't
recognize (either because the class or the feature does not exist) and return false.

In terms of the conditional calling of a method that may or may not exist in the class, I'd
like to make sure that you can actually do this without getting an error.  Craig Russell was
telling me he wasn't sure whether you could have code blocks that call non-existent methods
even if the actual method call is never hit due to conditional logic.  I'm going to do some
testing to see how that pans out.  

Mime
View raw message