I am in trouble trying to create an indefinite hashed map, as I want as a key specific objects that inherits from an abstract class, so the Key_Type is the parent class-wide, but I do not know what to do with the Hash that the container requires, as the Hash_Type is a modular type.
How can I deal with the hash of a class-wide key?
First thing that comes to mind is to add a "Hash" primitive function to the Key_Type abstract class, to be implemented in each concrete derived key type using the components of that concrete type, and then to make the Hash function for the map call this primitive Hash function with redispatch according to the actual type of the key.
Related
Dart says to avoid equality on mutable classes, that's reasonable. But what about classes with an immutable part like an unique id on which hashcode and equality shall be calculated with and other mutable attributes which shall be ignored. Is that not possible?
C# 9 introduces record reference types. A record provides some synthesized methods like copy constructor, clone operation, hash codes calculation and comparison/equality operations. It seems to me convenient to use records instead of classes in general. Are there reasons no to do so?
It seems to me that currently Visual Studio as an editor does not support records as well as classes but this will probably change in the future.
Firstly, be aware that if it's possible for a class to contain circular references (which is true for most mutable classes) then many of the auto generated record members can StackOverflow. So that's a pretty good reason to not use records for everything.
So when should you use a record?
Use a record when an instance of a class is entirely defined by the public data it contains, and has no unique identity of it's own.
This means that the record is basically just an immutable bag of data. I don't really care about that particular instance of the record at all, other than that it provides a convenient way of grouping related bits of data together.
Why?
Consider the members a record generates:
Value Equality
Two instances of a record are considered equal if they have the same data (by default: if all fields are the same).
This is appropriate for classes with no behavior, which are just used as immutable bags of data. However this is rarely the case for classes which are mutable, or have behavior.
For example if a class is mutable, then two instances which happen to contain the same data shouldn't be considered equal, as that would imply that updating one would update the other, which is obviously false. Instead you should use reference equality for such objects.
Meanwhile if a class is an abstraction providing a service you have to think more carefully about what equality means, or if it's even relevant to your class. For example imagine a Crawler class which can crawl websites and return a list of pages. What would equality mean for such a class? You'd rarely have two instances of a Crawler, and if you did, why would you compare them?
with blocks
with blocks provides a convenient way to copy an object and update specific fields. However this is always safe if the object has no identity, as copying it doesn't lose any information. Copying a mutable class loses the identity of the original object, as updating the copy won't update the original. As such you have to consider whether this really makes sense for your class.
ToString
The generated ToString prints out the values of all public properties. If your class is entirely defined by the properties it contains, then this makes a lot of sense. However if your class is not, then that's not necessarily the information you are interested in. A Crawler for example may have no public fields at all, but the private fields are likely to be highly relevant to its behavior. You'll probably want to define ToString yourself for such classes.
All properties of a record are per default public
All properties of a record are per default immutable
By default, I mean when using the simple record definition syntax.
Also, records can only derive from records and you cannot derive a regular class from a record.
As i read through UML specification that:
class has a set of attributes/operations
and data type has a set of attributes/operations
1)with regards to attributes/operations of data type
what this means?
because i don't know how such a data type has attributes and operations?
2)What’s the main difference between a class and a datatype?
according to UML 2.4.1 specification
A data type is a special kind of classifier, similar to a class. It
differs from a class in that instances of a data type are identified
only by their value. All copies of an instance of a data type and any
instances of that data type with the same value are considered to be
equal instances. Instances of a data type that have attributes (i.e.,
is a structured data type) are considered to be equal if the structure
is the same and the values of the corresponding attributes are equal.
If a data type has attributes, then instances of that data type will
contain attribute values matching the attributes.
1)Attributes/operations of data type have the same meaning than attributes/operations of classes i.e. attributes represent the structure of your data type and operations represent the method available on your data type.
2)The main difference between a class and a datatype is that it is not possible to have two instances of a datatype with the same values (these instance would be one unique instance).
Hoping it helps,
RB
In the Object Oriented
(OO)
approach
,
systems
,
including software
,
are
made up of numerous
objects
that work
together by exchanging information in
the form of data values and ‘messages’
. An object is a specific instance of a
Class
like your dog (an object) is specific instance of the class of all dogs.
Classes define what an object is like, and
objects are practical instances that can be used and manipulated.
As a definition, a class defines what properties will
be used to describe every object based on this class. Within the object each of these properties will have a value that
contributes to its description. Two objects of the same class will have the same properties, but they will have at least
one property that
has a different value in each of the objects
–
if all the properties have the same values in both of the
two objects then they are the same object.
A data type refers to the attributes of an object and what type of data each attribute is, such as string, boolean, integer etc.
Operations or methods is what an object can do such as for a dog:
growl();
bark();
fetch();
etc.
Have a look at this explanation of a Class Diagram, it will make more sense.
Apple's document says if I override isEqual: then I have to override hash to make sure the hash value should be same for two objects that are consider to be equal by isEqual:
Then I read the docs about hash and below is part of it:
Therefore, either the hash method must not rely on any of the object’s internal state information or you must make sure the object’s internal state information does not change while the object is in the collection.
My customize class MyClass have few of members which are int and bool and NSArray which contains number of MyClass and I want two instance of MyClass to be equal if all of the members are equal.
I have no problem with how to override isEqual: but for hash.
Of my understanding, hash should calculate the hash value by combine the members' hash value using bit operation such as XOR or rotational shift.
The problem is how to implement hash in a such way that meets the Apple's requirement that mention at above. Docs says that the hash value should not rely be the internal state(which is the members) but I found I have to use them to compute the value.
Or even do I really need to implement it? Because I sure I will not use this class as a key for NSDictionary and this is the only way I know where hash is used. Are there any other places where hash is used and I should care about it?
There's two options - either don't rely on the internal state, or ensure that the internal state doesn't change while the object is in a collection.
The second option will allow you to rely on the internal state to generate the hash, but your object must be immutable when in a collection, so that changing it doesn't change its hash.
Collections in Cocoa rely on the hash of an object to perform methods such as containsObject:.
If your object implements a hash that relies on its internal state, is inserted into a collection and then changed, its hash will change, and the collection will lose track of the object.
Let's take 2 UML class model entities: One represents an actual Order and another represents an Orede Type. Any Order corresponds to one Type. A 2-way-naviglabe many Orders to one Type relation is meant. Order Type instances are, for example, "Request availability", "Request price", "Preorder", "Buy", "Cancel", "Request support", etc. Order Types are to be addable and editable in the resulting application. Should I model Order Type as Class or as Enumeration? From the data perspective I can't see the difference actually.
I would prefer an enumeration. Classes should define properties and behaviour. In this case the type represents only a value with no need of methods.
Conclusion:
The usage of a class would surely possible but not necessary if you only want to represent values. Also, it would create a lot of extra coding work. You would have to write and maintain a bunch of classes that only represent one value when you could use an enumeration, which is surely the best and shortes way to represent typed values.