«

>> But in your solution you're right,
>> there is only need to store references. But i'm not sure if this solution
>> is
>> safe, because we have references to the same important data from two sets
>> keySet and valueSet, so we have to be careful with them. Mapping object
>> to
>> the same object does not have a big sense, for example what about the
>> method
>> put when the key already exist, after this operation we have a map where
>> key
>> and value are different, so we have inconsistent data.
>
> But what do you provide as the second argument to put()? If
> you always write put(obj,obj) there will never be any kind of
> mismatch. Yes, sometimes put(obj,obj) might replace an existing
> oldobj->oldobj mapping -- but if you didn't want that to happen,
> you shouldn't have called put() in the first place!

You can't use put(obj, obj2), because it doesn't have any sense in this
case. When you have the normal key and value, it has a sense.
What about clients, who want also get functionality?
We have to return Map<T, T> in the interface. How can you be sure that
clients won't call put(obj, obj2), you don't have control on it. You can't
throw exception when this occures with easy. So it might be more mistakes
about this. Also you must desribe this strange mapping in javadoc and be
sure that everyone understand it. You can instead public only a Set and a
get method, and hide a map implementation from the client. But this is
exactly like your own implementation of Set based on Maps, so this is the
same as "associative set".

>
> As for the set of keys and the set (collection, really) of
> values, yes: you must "be careful with them." But this is no
> different from being "careful" with the members of a Set! If you
> add a mutable object to a Set and then mutate it in a way that
> violates the Set's requirements, you're already in trouble. Using
> a Map doesn't make things worse in any way I can think of.

1. You can't assert that client doesn't cause the situation where there will
be mappings with no sense. When we assume that key.equals(value) or key ==
value (when key and a value are nulls), we should
check all situations, and throw exceptions when our assumption was violated
by client, for example (o1, o2) where !o1.equals(o2), or for example (null,
o1) null != o1, there are number of new mistakes, and we have to manage all
of them in some way. How? These client new mistakes don't exist when we use
"associative set".

Marcin

Marcin wrote:
>>> But in your solution you're right,
>>> there is only need to store references. But i'm not sure if this solution
>>> is
>>> safe, because we have references to the same important data from two sets
>>> keySet and valueSet, so we have to be careful with them. Mapping object
>>> to
>>> the same object does not have a big sense, for example what about the
>>> method
>>> put when the key already exist, after this operation we have a map where
>>> key
>>> and value are different, so we have inconsistent data.
>> But what do you provide as the second argument to put()? If
>> you always write put(obj,obj) there will never be any kind of
>> mismatch. Yes, sometimes put(obj,obj) might replace an existing
>> oldobj->oldobj mapping -- but if you didn't want that to happen,
>> you shouldn't have called put() in the first place!
>
> You can't use put(obj, obj2), because it doesn't have any sense in this
> case. When you have the normal key and value, it has a sense.
> What about clients, who want also get functionality?
> We have to return Map<T, T> in the interface. How can you be sure that
> clients won't call put(obj, obj2), you don't have control on it. You can't
> throw exception when this occures with easy. So it might be more mistakes
> about this. Also you must desribe this strange mapping in javadoc and be
> sure that everyone understand it. You can instead public only a Set and a
> get method, and hide a map implementation from the client. [...]

The words you seem to have forgotten are "composition" and
"encapsulation."

You began with a desire for a Set<T> that provides the extra
operation `T get(T)'. Very well: The suggestion is that you go
ahead and write a class that implements Set<T> plus the extra
operation, and that the class' implementation would use Map<T,T>
internally. There is no need to expose the internal Map to the
class' users, nor to allow them to do anything undesirable to it.

--
Eric Sosman
lid

>>You can instead public only a Set and a
>>get method, and hide a map implementation from the client. But this is
>>exactly like your own implementation of Set based on Maps, so this is the
^^^^^^^^^^^^^^
>>same as "associative set".
>
> The words you seem to have forgotten are "composition" and
> "encapsulation."
>
> You began with a desire for a Set<T> that provides the extra
> operation `T get(T)'. Very well: The suggestion is that you go
> ahead and write a class that implements Set<T> plus the extra
> operation, and that the class' implementation would use Map<T,T>
> internally. There is no need to expose the internal Map to the
> class' users, nor to allow them to do anything undesirable to it.

I've written about it in the last sentence. See above and Daniel has
mentioned it. I agree with you.

Thanks for discussion.

Marcin

Marcin wrote:

> There is a very useful functionality, that I think should be implemented
> in TreeSet nad HashSet
> that is the method: Object get(Object o).
> The method should return the same object from colletion as the parameter
> object.

I think that's a good idea.

I have evidence on my side too, because the language I normally use has just
that operation (called "find" rather than "get" -- which I think is a better
name, though it could still be improved) on its Sets and Set-like collections.
I find it useful.

For those who say that you can get the same effect with a Map, that's true, but
why should the programmer be forced to use a Map when the ability is
/intrinsically/ something that a Set must be able to provide ? If Sets can
naturally do it themselves (and they can), and if the operation is useful in
practise (and it is), then it should be part of the Set API.

For those who point out that Java's Sets are implemented as Maps anyway, so
there's no gain in avoiding the Map, I think they are confusing specification
with implementation. As it happens, Sun currently does implement Sets as Maps,
but that implementation decision (somewhat questionable as it is) should not
inform the design of the /API/.

The other thing I can't understand is why the hashed collections don't have
pluggable implementations. Seems a blatant oversight to me...

-- chris

Marcin wrote:
>> There is a very useful functionality, that I think should be implemented
>> in TreeSet nad HashSet
>> that is the method: Object get(Object o).
>> The method should return the same object from colletion as the parameter
>> object.

Chris Uppal wrote:
> I think that's a good idea.
>
> I have evidence on my side too, because the language I normally use has just
> that operation (called "find" rather than "get" -- which I think is a better
> name, though it could still be improved) on its Sets and Set-like collections.
> I find it useful.

I am mystified how it helps. What is the difference between

Object obj = o;

and

Object obj = enhancedSet.find( o );
?

- Lew

Lew <> wrote:
>I am mystified how it helps. What is the difference between
>Object obj = o; and Object obj = enhancedSet.find( o );

The difference is that the second will return the "canonical" instance of o,
where the first leaves you with multiple copies.

In the rather specialized case where you have many or large objects and you'd
rather keep one instance of each than many, and you for some reason don't want
to hide it all in a factory or manager, this can make it easy.

In every case I can think of, it's pretty easy to make a factory or FooSet
that's specific to the data and hides the implementation such that nobody
cares whether the Set interface has this method or the factory just keeps a
HashMap.
--
Mark Rafn <http://www.dagon.net/>

You guys need to make up your minds. If you have an object that can be
used to retrieve another object but isn't the 'canonical' object, surely
the first object is a key? which indicates using a Map?

Esmond Pitt wrote:

> You guys need to make up your minds. If you have an object that can be
> used to retrieve another object but isn't the 'canonical' object, surely
> the first object is a key? which indicates using a Map?

No, the question we want to ask the set to answer is "what object, if any, do
you contain that is equivalent (by your rules) to this one?".

For a multiset (bag, or whatever you call it) the question would be "which
objects do [etc] ?".

I don't think that has any more similarity to a mapping operation than asking
the set /whether/ it contains an object which is equivalent to [etc]. Note
that the inclusion test can itself be phrased as an object->boolean mapping,
but no one suggests that Map<Object, Boolean> makes Set<Object> redundant.

Notice also that the equivalent question "which key, if any, do you contain
[etc]" is also something which could also be asked of Maps -- and is not the
same as asking what value is keyed by that object. (I see no obvious use for
that particular operation, though -- but maybe that's only because I don't
already have it available).

-- chris

Chris Uppal wrote:
> No, the question we want to ask the set to answer is "what object, if any, do
> you contain that is equivalent (by your rules) to this one?".
>
> For a multiset (bag, or whatever you call it) the question would be "which
> objects do [etc] ?".
>
> I don't think that has any more similarity to a mapping operation than asking
> the set /whether/ it contains an object which is equivalent to [etc]. Note
> that the inclusion test can itself be phrased as an object->boolean mapping,
> but no one suggests that Map<Object, Boolean> makes Set<Object> redundant.
>
> Notice also that the equivalent question "which key, if any, do you contain
> [etc]" is also something which could also be asked of Maps -- and is not the
> same as asking what value is keyed by that object. (I see no obvious use for
> that particular operation, though -- but maybe that's only because I don't
> already have it available).

Thanks. I see it. Well, I guess Sun can't provide everything we want; they
have to leave a few classes for programmers to write or we'd be out of jobs.

I can see that it'd be easy to implement such a "CanonicalSet" as an
implementor of Set.

- Lew