java.lang.Object
art0.mind.concept
- Direct Known Subclasses:
- concept_statistic
- public class concept
- extends java.lang.Object
Instancias de la clase concept describirán conceptos a añadir en un diccionario
- Version:
- $Date:08-03-2002
ConceptWord
protected java.lang.String ConceptWord
- Identificador del concepto (palabraconcepto)
concept
public concept(java.lang.String CW)
concept
public concept(concept c)
getConceptWord
public java.lang.String getConceptWord()
equals
public boolean equals(java.lang.Object c)
- Description copied from class:
java.lang.Object
- Determine whether this Object is semantically equal
to another Object.
There are some fairly strict requirements on this
method which subclasses must follow:
- It must be transitive. If
a.equals(b) and
b.equals(c), then a.equals(c)
must be true as well.
- It must be symmetric.
a.equals(b) and
b.equals(a) must have the same value.
- It must be reflexive.
a.equals(a) must
always be true.
- It must be consistent. Whichever value a.equals(b)
returns on the first invocation must be the value
returned on all later invocations.
a.equals(null) must be false.- It must be consistent with hashCode(). That is,
a.equals(b) must imply
a.hashCode() == b.hashCode().
The reverse is not true; two objects that are not
equal may have the same hashcode, but that has
the potential to harm hashing performance.
This is typically overridden to throw a java.lang.ClassCastException
if the argument is not comparable to the class performing
the comparison, but that is not a requirement. It is legal
for a.equals(b) to be true even though
a.getClass() != b.getClass(). Also, it
is typical to never cause a java.lang.NullPointerException.
In general, the Collections API (java.util) use the
equals method rather than the ==
operator to compare objects. However, java.util.IdentityHashMap
is an exception to this rule, for its own good reasons.
The default implementation returns this == o.
JAVADOC | 
SOURCE | 
DOWNLOAD | NESTED | FIELD | CONSTR | METHOD