Есть некоторый тип данных пусть будет RRR

это массив и хеш

Если ест обращение к его элементам по индексу то создаеться массив
Если есть метод найти значения (findvalue), то есть хеш

например

def d=RRR();
d.add(1);
d.add(2);
d.add(3);

d.findvalue(1)

тут RRR должен быть хешем

def d=RRR();
d.add("1");
d.add("2");
d.add("3");

d[1];

тут RRR должен быть массивом

def d=RRR();
d.add("1");
d.add("2");
d.add("3");

d.findvalue(1)
d[1];

тут RRR должен быть объединенной структурой массива и хеша

Здравствуйте, Аноним, Вы писали:

А>тут RRR должен быть объединенной структурой массива и хеша

Ну так и сделайте себе "объединенную структуру массива и хеша".

Здравствуйте, catbert, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>тут RRR должен быть объединенной структурой массива и хеша

C>Ну так и сделайте себе "объединенную структуру массива и хеша".

Плохой вариант.
Медленнее массива если не нужен поиск значения и медленнее хеша если не нужен доступ по индексу.

а если это чудо будет передано кудато или из метода вернется? тут некислый вывод типов придется делать.

не говоря уж о том что касты всю малину обо... обжуют вобщем.

Здравствуйте, cvetkov, Вы писали:

C>а если это чудо будет передано кудато или из метода вернется? тут некислый вывод типов придется делать.

C>не говоря уж о том что касты всю малину обо... обжуют вобщем..

Каст это не более чем вызов функции получающий на вход текущий, а возвращающий другой.

Фактически нужно для типа реализовать метод возвращающий все использования его.

Здравствуйте, <Аноним>, Вы писали:

C>>а если это чудо будет передано кудато или из метода вернется? тут некислый вывод типов придется делать.

C>>не говоря уж о том что касты всю малину обо... обжуют вобщем..

А>Каст это не более чем вызов функции получающий на вход текущий, а возвращающий другой.
Ну не скажи. вот такой сценарий:

def a = RRR(); // 1
d.add(1);
Object b = a;

RRR c = (RRR)b;
c.findvalue(); //2

И как нам в момент 1 понять что там гдето в будущем случится именно 2
Тут два плохих решения:
1) каст создает новый инстанс. это плохо потому что не сохраняет равенство ссылок которое мы ожидаем от каста
2) если есть каст готовитсяя к худшему и использовать реализацию которая может все. это плохо потому что убивает всю идею оптимизации.

А>Фактически нужно для типа реализовать метод возвращающий все использования его.
нет. надо найти все использования инстанса, а не типа.

Здравствуйте, cvetkov, Вы писали:

C>Здравствуйте, <Аноним>, Вы писали:

C>>>а если это чудо будет передано кудато или из метода вернется? тут некислый вывод типов придется делать.

C>>>не говоря уж о том что касты всю малину обо... обжуют вобщем..

А>>Каст это не более чем вызов функции получающий на вход текущий, а возвращающий другой.
C>Ну не скажи. вот такой сценарий:
C>

C>def a = RRR(); // 1
C>d.add(1);
C>Object b = a;

C>RRR c = (RRR)b;
C>c.findvalue(); //2
C>

C>И как нам в момент 1 понять что там гдето в будущем случится именно 2
C>Тут два плохих решения:
C>1) каст создает новый инстанс. это плохо потому что не сохраняет равенство ссылок которое мы ожидаем от каста
C>2) если есть каст готовитсяя к худшему и использовать реализацию которая может все. это плохо потому что убивает всю идею оптимизации.

А>>Фактически нужно для типа реализовать метод возвращающий все использования его.
C>нет. надо найти все использования инстанса, а не типа.

соглсен, я не правильно выразился

Здравствуйте, <Аноним>, Вы писали:

А>>>Фактически нужно для типа реализовать метод возвращающий все использования его.
C>>нет. надо найти все использования инстанса, а не типа.

А>соглсен, я не правильно выразился
ну а эта задача нерешаемая.

Здравствуйте, cvetkov, Вы писали:

C>ну а эта задача нерешаемая.

почему?

Здравствуйте, Аноним, Вы писали:

А>Есть некоторый тип данных пусть будет RRR

Что мешает программисту в каждом из сценариев сразу использовать эффективную структуру данных?

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Есть некоторый тип данных пусть будет RRR

H>Что мешает программисту в каждом из сценариев сразу использовать эффективную структуру данных?

Незнание, как эту структуру будут использовать в дальнейшем. Довольно частая ситуация, если есть чужие обновляемые исходники.

Здравствуйте, Аноним, Вы писали:

А>Незнание, как эту структуру будут использовать в дальнейшем. Довольно частая ситуация, если есть чужие обновляемые исходники.

В каком дальнейшем? Приведенные сценарии применимы только в рамках одного метода.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Незнание, как эту структуру будут использовать в дальнейшем. Довольно частая ситуация, если есть чужие обновляемые исходники.

H>В каком дальнейшем? Приведенные сценарии применимы только в рамках одного метода.

Ты всегда анализируешь эффективность каждой структуры? Постоянно конвертируешь массив в хеш для быстрого поиска элемента, а потом удаляешь хеш?


После чего возник такой вопрос. У меня исходник.

для массива там добавлен метод findelement/
В тестах на него приходиться 0,01% нагрузки

В моем варианте использования пришлось 80%

Здравствуйте, Аноним, Вы писали:

А>Ты всегда анализируешь эффективность каждой структуры? Постоянно конвертируешь массив в хеш для быстрого поиска элемента, а потом удаляешь хеш?

Зависит от задачи, но стараюсь выбирать наиболее эффективные структуры данных.


А>для массива там добавлен метод findelement/
А>В тестах на него приходиться 0,01% нагрузки

А>В моем варианте использования пришлось 80%

Неиспользование волшебной макры (читай — использование неэффективной структуры данных) приведет к такому же результату.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Ты всегда анализируешь эффективность каждой структуры? Постоянно конвертируешь массив в хеш для быстрого поиска элемента, а потом удаляешь хеш?

H>Зависит от задачи, но стараюсь выбирать наиболее эффективные структуры данных.


А>>для массива там добавлен метод findelement/
А>>В тестах на него приходиться 0,01% нагрузки

А>>В моем варианте использования пришлось 80%

H>Неиспользование волшебной макры (читай — использование неэффективной структуры данных) приведет к такому же результату.

почему не переложить на компилятор возможность анализировать и выбирать пусть и для простых случаев структуры данных?

Здравствуйте, Аноним, Вы писали:

А>почему не переложить на компилятор возможность анализировать и выбирать пусть и для простых случаев структуры данных?

Смысл? В простых случаях программист в состоянии выбрать между массивом, списком, деревом и хэштаблицей.

Здравствуйте, <Аноним>, Вы писали:

C>>ну а эта задача нерешаемая.

А>почему?

так предется data flow построить. а его построить нельзя из-за проблемы останова. в общем случае невозможно даже сказать что программа не зацикливается, а уж анализ проводить можно только приблизительно.

Здравствуйте, hardcase, Вы писали:

H>Смысл? В простых случаях программист в состоянии выбрать между массивом, списком, деревом и хэштаблицей.

а например между массивом+хештаблица?

в 2 раза больше памяти, но зато константный доступ по индексу и по поиску элемента?

часто код бывает написан уже, а только постфактум можно выяснить, что структура выбрана не верно и код для скорости на первый взгляд не критичен(в 3-4 раза туда сюда не важно)
вообще было бы хорошо иметь в языке возможности для таких вещей.

Здравствуйте, cvetkov, Вы писали:

C>так предется data flow построить. а его построить нельзя из-за проблемы останова. в общем случае невозможно даже сказать что программа не зацикливается, а уж анализ проводить можно только приблизительно.

жадного анализа достаточно, а он не связан с проблемой остонова, если не генерируется новый код.

Здравствуйте, Аноним, Вы писали:

А>часто код бывает написан уже, а только постфактум можно выяснить, что структура выбрана не верно и код для скорости на первый взгляд не критичен(в 3-4 раза туда сюда не важно)
А>вообще было бы хорошо иметь в языке возможности для таких вещей.

а еще лучше иметь в рантайме возможность статистического определения и выбора структур и алгоритмов