Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Generics Considered Harmful:
Лучшее место, на мой взгляд, вот это:

еhat is, someone might declare a Holder<Set<String>>. And, ... uh, hold on, I'm trying to remember the issue here...
Actually, I'm only mildly embarrassed to say that I've forgotten.

Давайте я тоже так начну, а?

Не знаю, как бы так плавно к этому подойти, так что выскажусь прямо:
Программирование — это зло.
Дело в том, что чем бы человек ни занимался, он должен взвесить преимущества и недостатки.
Проблема, собственно в том, что вот человек начинает заниматься программированием. Ну и ему, конечно, надо начать программировать. Вот он типа открывает студию, говорит New Project..., и тут... Ой, погодите, щас вспомню, че там...
Ну, короче я забыл. Но там на самом деле такая блин великая проблема, на которую сразу напарываешься неизбежно, что мой один друг который много программировал, полгода беседовал с еще одним другом. И только через полгода тот второй друг смог ему объяснить, в чем великая проблема программирования и тот первый друг признал, что да, проблема есть и неизбежная.
В общем, первый мегааргумент я изложил.

Во-вторых, программирование требует заниматься вещами, которые никто не понимает. Ну кто может, в натуре, понять, что такое class A: public T<A>{}? А некоторые люди это пишут, и хоть пользоваться этим совершенно необязательно, но то, что я не понимаю, что это означает, и как это A может зависеть от T, который зависит от А, заставляет меня нервничать. Еще больше меня заставляет нервничать тот факт, что это работает, и никто больше не испытывает с этим проблем, если вы поняли о чем я говорю. То в общем, эти те другие, которые это понимают, они тоже занимаются программированием. И что программирование есмь после этого? Правильно — зло.
Вот. Это был второй мегааргумент.

Andrei N.Sobchuck wrote:

> Humans can't track this stuff.

Some humans _can_.

> They are always loosing which exception to what other exception
> applies (or doesn't) in any given case.
> /.../

I can track such sort of things. It's not hard, you just need to know
how things really work.

Of course, most of Java/C# programmers are "code monkeys", so this may
be a problem for them.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Generics Considered Harmful:

Generics are a mistake.
This is not a problem based on technical disagreements. It's a fundamental language design problem.
/.../
Learning to use generified types can get very complicated. It's hard to understand why you cannot do some things without casts, for example. But writing generified classes is rocket science.
/.../
Which brings up the problem that I always cite for C++: I call it the “Nth order exception to the exception rule.” It sounds like this: “You can do x, except in case y, unless y does z, in which case you can if ...”
Humans can't track this stuff. They are always loosing which exception to what other exception applies (or doesn't) in any given case.
/.../

И т.д.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Generics Considered Harmful:

Я бы сказал, не генерики, как таковые, а их ублюдочная реализация в Java (ведь речь идет именно о них?). И без того убогонькую систему типов превратили в какого-то мутанта.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Generics Considered Harmful:
забавная статейка...
Решил попробовать это на C# (к сожалению под рукой Java нет, поэтому сверить различные подходы не могу)

    public interface IHolder<T>
    {
        T[] ToArray();
    }

    public class Holder : IHolder<string>
    {
        #region IHolder<string> Members

        public string[] ToArray()
        {
            return new string[] { "1", "2" };
        }

        #endregion
    }

    public class GenericHolder<T> : IHolder<T>
    {
        #region IHolder<T> Members

        public T[] ToArray()
        {
            return new T[10];
        }

        #endregion
    }

Я так понял, что в Java выделенный вариант работать не будет

            Holder h = new Holder();
            string[] sar = h.ToArray();

            GenericHolder<string> gh = new GenericHolder<string>();
            string[] sar2 = gh.ToArray();

в шарпе все ок.

Далее, объявить цикличный дженерик мне удалось

    public class CyclicGeneric<T> where T : CyclicGeneric<T>
    { }

(я так понял, именно это подразумевалось под Enum

Enum<T extends Enum<T>>

)
но вот специализировать его

Sinclair,

> ANS>Generics Considered Harmful:
> Лучшее место, на мой взгляд, вот это:
>

еhat is, someone might declare a Holder<Set<String>>. And, ... uh, hold on, I'm trying to remember the issue here... Actually, I'm only mildly embarrassed to say that I've forgotten.

> Давайте я тоже так начну, а? <...>

Смешно Не смешно то, что в Java Generics, действительно, существуют проблемы с массивами параметризованных типов, и как раз вокруг того места, которое забыл (или "забыл"?..) автор обсуждаемой статьи:

7.3 Arrays

The component type of an array object may not be a type variable or a parameterized type, unless it is an (unbounded) wildcard type.You can declare array types whose element type is a type variable or a parameterized type, but not array objects. This is annoying, to be sure. This restriction is necessary to avoid situations like:

List<String>[] lsa = new List<String>[10]; // not really allowed
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li; // unsound, but passes run time store check
String s = lsa[1].get(0); // run-time error - ClassCastException

If arrays of parameterized type were allowed, the example above would compile without any unchecked warnings, and yet fail at run-time. We’ve had type-safety as a primary design goal of generics. In particular, the language is designed to guarantee that if your entire application has been compiled without unchecked warnings using javac -source 1.5, it is type safe.

However, you can still use wildcard arrays. Here are two variations on the code above. The first forgoes the use of both array objects and array types whose element type is parameterized. As a result, we have to cast explicitly to get a String out of the array.

List<?>[] lsa = new List<?>[10]; // ok, array of unbounded wildcard type
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li; // correct
String s = (String) lsa[1].get(0); // run time error, but cast is explicit

IIn the next variation, we refrain from creating an array object whose element type is parameterized, but still use an array type with a parameterized element type. This is legal, but generates an unchecked warning. Indeed, the code is unsafe, and eventually an error occurs.

List<String>[] lsa = new List<?>[10]; // unchecked warning - this is unsafe!
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[1] = li; // correct
String s = lsa[1].get(0); // run time error, but we were warned

Similarly, attempting to create an array object whose element type is a type variable causes a compile-time error:

<T> T[] makeArray(T t) { return new T[100]; // error
}

Since type variables don’t exist at run time, there is no way to determine what the actual array type would be.

The way to work around these kinds of limitations is to use class literals as run time type tokens, as described in section 8.