I agree that this is unlikely to be a problem...

One issue is that some directors (I'm not sure which) store info
in hash tables using the actor as a key.  But unless you end you
end up with models where a very large number of models end up
being "equal" I doubt there would be a noticable performance
hit is a few end up this way...


Christopher Brooks wrote:
Implementing equals() and hashCode() in actors is not likely to break much. Actors can be passed as Tokens, there is ptolemy.data.ActorToken.
ActorToken is used in the Graph Transformation and the
Ptolemy Hierarchical Orthogonal Multi-Attribute Solver (PtHOMAS)
work.  I don't think adding equals() and hashCode() to actors will
affect ActorToken, but it could.

I say go for it.   Let me know if you have problems.


Richard Ware wrote:
  I assume then that I won't break the framework by writing equals()
and hashCode() in my actor (because some of my other code wants
to use them).

  Thanks, Christopher!

On Mon, Oct 27, 2008 at 12:40 PM, Christopher Brooks <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Hi Richard,
    Actors usually don't have equals() and hashCode() methods.
    However, if you define a custom token, like
    actor.lib.security.KeyToken, then the custom token should
    have equals() and hashCode() methods.


fn:Edward A. Lee
n:Lee;Edward A.
org:UC Berkeley;EECS
adr:;;545Q Cory Hall;Berkeley;CA;94720-1770;USA
email;internet:[EMAIL PROTECTED]
title:Robert S. Pepper Distinguished Professor

Reply via email to