[kepler-dev] extending Ptolemy's moml filters

Christopher Brooks cxh at eecs.berkeley.edu
Tue May 27 15:42:44 PDT 2008

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


    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

More information about the Kepler-dev mailing list