Btw, I realize that in this particular case, you would probably write a
“compareKeys” method to perform the key comparison, and that would have the
type switch, but I was trying to show that in general a method that uses a lot
of math and or comparison operations will need to be duplicated, probably more
so for the math operations.
> On Sep 30, 2018, at 10:18 AM, robert engels <reng...@ix.netcom.com> wrote:
>
> 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
>> <mailto:o...@fairbe.org>> wrote:
>>
>>> Robert Engels <reng...@ix.netcom.com <mailto:reng...@ix.netcom.com>> wrote
>>> about what
>>>> Christian Surlykke <christ...@surlykke.dk <mailto: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 <mailto:christ...@surlykke.dk>>
>> Read other threads' replies made from reng...@ix.netcom.com
>> <mailto: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 <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
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout
>> <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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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.
