[kepler-dev] extending Ptolemy's moml filters

[Christopher Brooks]

Hi Daniel,

Thanks, your changes look good!  Many thanks for following the Ptolemy
coding style.  The only change I made was that in
PropertyClassChanges, the remove and put methods were not
alphabetical.  This could have been a pre-existing condition, I did
not check.

I considered adding a interface called MappedMoMLFilter, that would
extend the MoMLFilter interface and add these methods:

  public static void clear();
  public void put(String className, HashMap portNameMap);
  public void remove(String className);

However the filter seemed odd, since the put() methods are a putting a
classname and HashMap, which seems very filter specific and might be
hard to explain in documentation for the MappedMoMLFilter.  If we get
more MoMLFilters like PortNameChanges and PropertyClassChanges, then
maybe we should add an interface.

It looks like there are no tests for these new methods, see
http://chess.eecs.berkeley.edu/ptexternal/nightly/coverage.html#ptolemy.moml.filter
If you are feeling daring, you could add tests by adding 
moml/filter/test/PortNameChanges.tcl and PropertyClassChanges.tcl
and creating Unit tests.  If you do this, you would also need to
edit moml/filter/test/makefile and add the new .tcl files.

How I would test these is by looking at BackwardCompatibility.tcl and 
creating a small piece of MoML that gets filtered with and without
put(), remove() and clear() called.

Thanks again for adding these methods.

_Christopher


--------

    
    Developers,
    
    There are now Kepler-specific moml filters that rely on these
    new accessor methods. You will probably need to update your
    Ptolemy CVS.
    
    Thanks,
    
      --dan
    
    
    Christopher Brooks wrote:
    > Hi Daniel,
    >
    > I'd prefer to see accessor methods added instead of making the HashMap
    > public.  The reason is that information hiding is, in general, good.
    >
    > RemoveGraphicalClasses has
    >
    > public static void clear()
    > public void remove(String className)
    > public void put(String className, String replacement)
    >
    > I've used these methods for some time and it has worked out.
    > I might be good to have an accessor method that would return 
    > probably a copy of the HashMap, but I have not needed it.
    >
    > If you want, you could add similar methods to the filters in which you
    > are interested.  It might make sense to add these methods to the
    > MoMLFilter baseclass.  However, I don't think all MoMLFilters have
    > HashMaps, so it might not make sense.  Though we could add an
    > interface that had these methods defined
    >
    > If you are willing to make the changes in the Ptolemy style, then I
    > could give you write access to the Ptolemy II tree and you could add
    > them.  To do this, go to
    > http://chess.eecs.berkeley.edu/options
    > and request a  CVS account.
    >
    > If you go the route of updating the Ptolemy II tree, then you could do
    > what Chad usually does, which is drop me a line before and after he
    > makes changes.  This is somewhat optional, but it helps me keep track
    > of what is going in and I tend to sometimes review the changes and see
    > if there are other places similar changes should go.
    >
    > _Christopher
    >
    >     
    >     Hi Christopher,
    >     
    >     I would like to use Ptolemy's backwards-compatibility moml filters
    >     to provide the same functionality for Kepler. However, the HashMaps
    >     that contain the changes for each filter are private. What do you
    >     think of making these protected or adding a public method to update
    >     them?
    >     
    >       --dan
    > --------
    >   
    
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------