Home » Modeling » EMF » hashcode and Map (non mutable case)
| hashcode and Map (non mutable case) [message #942521] |
Sat, 13 October 2012 16:01  |
 David Michonneau
Messages: 85
Registered: July 2009 |
Member |
|
|
I'm coming back with yet another question about using EObject as keys in Maps. I have read previous posts, javadoc, etc... So I know it is not supported to override hashcode()/equals(). But, this remains a major annoyance, and I agree that it is a bad idea to use mutable objects as keys in HashMaps.
The point is that I use EMF to generate all my model classes, mutable and non-mutable ones. It doesn't seem there is any good reason to prevent the mutable ones to be keys in maps (and especially EMF generated maps, after all those are EMF specialized map classes).
So here is my question: I model a non-mutable class, let's call it Identifier, with two attributes:
- String name
- String path
The two attributes must be set at the construction of Identifier, so I only create instances through a new factory method createIdentifier(name, path). Nobody ever calls setter (or assume I remove setter methods).
Now, given those hypotheses, can I override hashcode/equals to put this Identifier object into an EMap (modeled in the ecore)? Will it cause any problem? If so, can we envision an enhancement to model special immutable objects that will have a generated hashcode/equals (by default hashcode of attributes), that could be overriden? I guess all EMF code (lists, copier,...) would be able to detect those immutable objects, and process them accordingly. Moreover, it would generate smart factory methods for those with all its attributes as arguments.
Thanks,
David
|
|
|
| Re: hashcode and Map (non mutable case) [message #943035 is a reply to message #942521] |
Sun, 14 October 2012 04:58  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943040 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943045 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943050 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943055 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943060 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943065 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943070 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943075 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943080 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943084 is a reply to message #942521] |
Sun, 14 October 2012 04:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 13/10/2012 6:01 PM, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path).
The framework still has access to the reflective methods and those will
be used in, for example, the deserializer and the copier.
> Nobody ever calls setter (or assume I remove setter methods).
This just doesn't seem an appropriate thing to be an EObject.
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)?
You can because I didn't make those methods final in BasicEObjectImpl;
but in hindsight, I should have done that.
> Will it cause any problem?
It might.
> If so, can we envision an enhancement to model special immutable
> objects that will have a generated hashcode/equals (by default
> hashcode of attributes), that could be overriden?
In general that invites problems. For example, all the EObject
containing lists are implemented with the basic premise that (x == y) ==
x.equals(y).
> I guess all EMF code (lists, copier,...) would be able to detect
> those immutable objects, and process them accordingly.
Yet more complexity through out the framework and in the entire stack of
reflectively technologies build on top of it.
> Moreover, it would generate smart factory methods for those with all
> its attributes as arguments.
Consider your example. You'd expect an immutable value-object that has
two fields. Instead of you get something with 2-3 times as many fields
as needed. You end up with the possibility to have containment
references and cross references to such instance, where in actual fact
it should be possible to have a single value to represent that name/path
"pair" across all instances.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
>
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: hashcode and Map (non mutable case) [message #943134 is a reply to message #942521] |
Sun, 14 October 2012 07:10 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
The semantics of equals() is fundamental to the design of the Java
Collection classes. If two objects are equals only one can exist in a Set.
EObject classes are normally distinct with respect to containment and
other semantics so you risk a semantic conflict between hidden Java
mechanisms and your pragmatism.
In UML, OCL semantics has evolved so that DataTypes are equal by deep
value comparison and Classes by simple 'address' identity.
The same principle applies to EDataType and EClass.
So if you want to adjust Ecore equality, I recommend only adjusting
EDataTypes.
Regards
Ed Willink
On 13/10/2012 17:01, David Michonneau wrote:
> I'm coming back with yet another question about using EObject as keys
> in Maps. I have read previous posts, javadoc, etc... So I know it is
> not supported to override hashcode()/equals(). But, this remains a
> major annoyance, and I agree that it is a bad idea to use mutable
> objects as keys in HashMaps.
>
> The point is that I use EMF to generate all my model classes, mutable
> and non-mutable ones. It doesn't seem there is any good reason to
> prevent the mutable ones to be keys in maps (and especially EMF
> generated maps, after all those are EMF specialized map classes).
> So here is my question: I model a non-mutable class, let's call it
> Identifier, with two attributes:
> - String name
> - String path
>
> The two attributes must be set at the construction of Identifier, so I
> only create instances through a new factory method
> createIdentifier(name, path). Nobody ever calls setter (or assume I
> remove setter methods).
>
> Now, given those hypotheses, can I override hashcode/equals to put
> this Identifier object into an EMap (modeled in the ecore)? Will it
> cause any problem? If so, can we envision an enhancement to model
> special immutable objects that will have a generated hashcode/equals
> (by default hashcode of attributes), that could be overriden? I guess
> all EMF code (lists, copier,...) would be able to detect those
> immutable objects, and process them accordingly. Moreover, it would
> generate smart factory methods for those with all its attributes as
> arguments.
>
> Thanks,
>
> David
|
|
|
| Re: hashcode and Map (non mutable case) [message #943210 is a reply to message #943035] |
Sun, 14 October 2012 08:50 |
David Michonneau
Messages: 85
Registered: July 2009 |
Member |
|
|
Ed Merks wrote on Sun, 14 October 2012 00:58David,
Comments below.
In the end, however convenient it would be to generate such things, it
would make much more sense to extend what's possible with an EDataType
so that such things remain value-instances than to make these be
EObjects. Doing so with Xcore, without significantly impacting the
Ecore model itself, seems far more feasible. I.e., we could use the
Xbase compiler to generate the Java for a data type class and use the
standard generator to emit that; in terms of impact on Ecore itself it
would just amount to an annotation on a data type (must as Xcore
operation bodies are mapped annotations on data types).
In fact I ended up creating the datatype as you suggested. The question is why not generating those value objects, if the user wants this? Internally it can still behave as a datatype, no change needed to any internal. I guess the generation template could be very simple. Maybe a new EDataTypeClass that you can edit in the ecore and that can have attributes with regular java types or user-defined types?
I haven't tried Xcore yet, but if this enhancement can make it, I think it would be of great value. I have quite some immutable objects in my models, and it's always a hassle to hide the setters, create the new factory methods for the immutable attributes, and create the wrappers for computing their hashcode when they need to be used in maps. It even came to the point of "why do we use EMF?" if we need to do all those things for some of the model classes.
Cool, so now, note that there is also the case of classes with mixed mutable/non mutable attributes (non mutable ones are usually identifiers or keys, that you would want to rely on in maps...). For instance:
class A {
non-mutable attribute x;
mutable attribute y;
}
What could be the solution in this case? Assume I want a hashcode of A, that is the hascode of x, and I want to put A in a map, or in a set.
Thanks,
David
|
|
|
| Re: hashcode and Map (non mutable case) [message #943244 is a reply to message #943210] |
Sun, 14 October 2012 09:39 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
David,
Comments below.
On 14/10/2012 10:50 AM, David Michonneau wrote:
> Ed Merks wrote on Sun, 14 October 2012 00:58
>> David,
>>
>> Comments below.
>>
>>
>> In the end, however convenient it would be to generate such things,
>> it would make much more sense to extend what's possible with an
>> EDataType so that such things remain value-instances than to make
>> these be EObjects. Doing so with Xcore, without significantly
>> impacting the Ecore model itself, seems far more feasible. I.e.,
>> we could use the Xbase compiler to generate the Java for a data type
>> class and use the standard generator to emit that; in terms of impact
>> on Ecore itself it would just amount to an annotation on a data type
>> (must as Xcore operation bodies are mapped annotations on data types).
>
>
> In fact I ended up creating the datatype as you suggested. The
> question is why not generating those value objects, if the user wants
> this?
Well, you need to generate them from some description...
> Internally it can still behave as a datatype, no change needed to any
> internal.
Yes, it would have to, but instances of EClasses are EObject so it's not
appropriate for producing such a result.
> I guess the generation template could be very simple. Maybe a new
> EDataTypeClass that you can edit in the ecore and that can have
> attributes with regular java types or user-defined types?
I'd rather not complicate Ecore itself.
>
> I haven't tried Xcore yet, but if this enhancement can make it, I
> think it would be of great value.
Yes, it would be quite cool and useful. You could open an bugzilla
enhancement request.
> I have quite some immutable objects in my models, and it's always a
> hassle to hide the setters, create the new factory methods for the
> immutable attributes, and create the wrappers for computing their
> hashcode when they need to be used in maps. It even came to the point
> of "why do we use EMF?" if we need to do all those things for some of
> the model classes.
Ecore isn't intended to be a full replacement for writing Java code...
>
> Cool, so now, note that there is also the case of classes with mixed
> mutable/non mutable attributes (non mutable ones are usually
> identifiers or keys, that you would want to rely on in maps...). For
> instance:
>
> class A {
> non-mutable attribute x;
> mutable attribute y;
> }
>
> What could be the solution in this case? Assume I want a hashcode of
> A, that is the hascode of x, and I want to put A in a map, or in a set.
Xcore also isn't intended to be a full replacement for writing Java
code, but it is intended to help specify behavior and it would be useful
if it helped you define the implementations of new data types in a more
flexible way than is possible with Ecore.
> Thanks,
>
> David
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
Goto Forum:
Current Time: Tue Apr 23 13:27:16 GMT 2024
Powered by FUDForum. Page generated in 0.04562 seconds |
] 
Search
Help
Register
Login
Home
