Yes, it is a very similar if not the same issue, since the type switch must be
at the TOP LEVEL, you guarantee the entire method will be duplicated multiple
times. How you continually do not see the problem with this I am not sure, but
I think it is because you are using trivial methods to “test” the situation.
Here is a fairly simple generic method from TreeMap.java, do you really want N
versions of this when the container have ints and some user interface object?
And since K and V are different types, it is even worse.
And I think you should review the definition of straw-man, because that doesn’t
apply.
If you review the following code, you see that compareTo is used deeply when
comparing keys. Under your proposals, I will need to duplicate the entire
method, since the simple comparison test will be different for the primitives
(==) and structs (compareTo()).
Maybe you can rewrite the following method under your proposal to prove me
wrong… You’ll also notice that this methods supports keys that aren’t
“comparable” by passing a “comparator” to the ctor.
public V put(K key, V value) {
Entry<K,V> t = root;
if (t == null) {
compare(key, key); // type (and possibly null) check
root = new Entry<>(key, value, null);
size = 1;
modCount++;
return null;
}
int cmp;
Entry<K,V> parent;
// split comparator and comparable paths
Comparator<? super K> cpr = comparator;
if (cpr != null) {
do {
parent = t;
cmp = cpr.compare(key, t.key);
if (cmp < 0)
t = t.left;
else if (cmp > 0)
t = t.right;
else
return t.setValue(value);
} while (t != null);
}
else {
if (key == null)
throw new NullPointerException();
@SuppressWarnings("unchecked")
Comparable<? super K> k = (Comparable<? super K>) key;
do {
parent = t;
cmp = k.compareTo(t.key);
if (cmp < 0)
t = t.left;
else if (cmp > 0)
t = t.right;
else
return t.setValue(value);
} while (t != null);
}
Entry<K,V> e = new Entry<>(key, value, parent);
if (cmp < 0)
parent.left = e;
else
parent.right = e;
fixAfterInsertion(e);
size++;
modCount++;
return null;
}
> On Sep 30, 2018, at 9:27 AM, Wojciech S. Czarnecki <o...@fairbe.org> wrote:
>
>> Robert Engels <reng...@ix.netcom.com> wrote about what
>>> Christian Surlykke <christ...@surlykke.dk> wrote:
>
>> The static switch is a big problem. For any complex method you are going to
>> completely duplicate all of the code. Not good.
>
> Now the same straw man argument I read in "critique" about my [1] solution is
> raised against other person's proposal.
>
> No! One need not to "completely duplicate" the code. Not even to mention
> "all", or most. And "static switch" is **not** "a big problem".
> It is a solution to the problem.
>
> For the practical generic code we need to deal with outstanding cases/types
> via the variant generation. Usually, a variant involving **different** code
> or even different underlying algorithm. That's what a `compile-time switch`
> over possible specialized code variants is for. Both in mine's and in Chris'
> proposal.
>
>> Far better to map operators to interfaces then you only need a single
>> method implementation.
>
> Oh, just a single? Rly? Just a single method implementation for each of
> possibly hundreds or thousands of future user types? Aren't you "going
> to completely duplicate all of the code"? Even for non-complex methods?
> (Its current state of affairs, btw).
>
> @Christian <christ...@surlykke.dk>
> Read other threads' replies made from reng...@ix.netcom.com, esp ones of
> "java's better" attitude, before you start to write a reply to an unfounded
> critique. Fighting someone else's straw man makes no sense at all.
>
> [1] https://github.com/ohir/gonerics
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
