[kepler-dev] extending Ptolemy's moml filters

Daniel Crawl crawl at sdsc.edu
Wed May 28 13:00:20 PDT 2008

Hi Christopher,

I'm willing to implement accessor methods and will go request a CVS



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

More information about the Kepler-dev mailing list