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...
Edward
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.
_Christopher
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.
_Christopher
begin:vcard
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
tel;work:+1-510-643-3728
tel;fax:+1-510-642-5745
x-mozilla-html:FALSE
url:http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html
version:2.1
end:vcard
