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

AVK>>>Еще один. Анонимные МЕТОДЫ. И анонимные методы это совсем не то же самое, что анонимные классы.
C>>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все.
EC>Type safety тебя не заботит?
Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?

К примеру, из моего кода:

JList needsList;
...
        //Focus listener - show info when we're focused
        needsList.addFocusListener(new FocusListener()
        {
            public void focusGained(FocusEvent e)
            {
                infoPanel.add(InfoUtils.createInfoPanel(curEmployee));
            }

            public void focusLost(FocusEvent e)
            {
                infoPanel.removeAll();
            }
        });

Все красиво и типобезопасно.

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

C>CAS — это Code Access Security?

Да.

C>Transparent proxy — это, я так полагаю, то что описано здесь.

Нет.

C> Рекомендую прочитать первые строчки:
C>

C>The Java community has had the joy of dynamic proxies since JDK 1.3 and .NET has had its counterpart, the TransparentProxy, since .NET version 1.0. However, the .NET TransparentProxy isn't as easy to use as its Java counterpart. This is why DynamicProxy.NET was made.

Нет, dynamic proxy это другое. TP возможно реализовать только с помощью рантайма.

C>WCF — это вот это?

Релиз уже есть? И, что характерно, там явно указывается что ноги растут из WCF .

C>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все. Да, в .NET меньше синтаксического оверхеда, но это чистый сахар.

Нет, не сахар. Делегаты поддерживаются на уровне рантайма, а в джаве делегатов нет. И в свете ковариантности делегатов и вывода типов анонимные классы выглядят далеко не полноценным заменителем.

C> А в JDK7 вообще очень вероятно появление лямбд и настоящих замыканий.

Если уж LINQ нет, хотя beta 2 уже feature complete, то и лямбд с замыканиями в джаве тоже нет.

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

D>Отлично пояснил!

D>Если бы все шаги DataReader->DTO->BO->XML->HTML были чистыми и ленивыми, то указание (в любой форме!) фильтрации на HTML стороне автоматически доехало бы до DataReader'а.
Ты знаешь, а такой язык есть. Называется XQuery. Чистый, функциональный язык. Только он не является языком общего назначения, со всеми вытекающими последствиями.

Что касается ленивости, то тут несколько неприятных проблем. Подобные прикладные системы имеют понятия транзакционности(притом и кэша и бд и файлов и многого еще чего). Из чего следует что многие действия должны выполняться в строгой последовательности. А для этого придется иметь императив.

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

EC>>Type safety тебя не заботит?
C>Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?
А как будет решаться следующая проблема с помощью интерфейсов:
в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.

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

C>Я просто не могу упустить случая посмеяться над .NET-итстами.
Поговорку про смех без причины знаешь? Могу напомнить.

C>Примитивный mapper — это будет iBatis.
Он-то как раз не очень примитивный.

C>Ага. А Hibernate — не ORM, а универсальная система работы с данными. Не веришь?
Не верю. Или ты хочешь сказать это в оправдание его кривизны?.. =)

C>Ага. Тогда в качестве антипримера можно взять RSDN — сколько он у нас глючит?
На RSDN глючит железо. А если бы RSDN был написан на яве с гибернейтом, то железа бы требовалось в два раза больше.

C>Почему тогда RDB — не тупиковое направление?
Потому что пока ничего лучше не придумали.

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

NB>Дорогой друг.

Ну разве где-нибудь еще можно так легко найти друзей? Нигде кроме, как на rsdn.

NB>Мы очень рады что вы вообще не программист,

Вы — коллективный псевдоним или просто представляете инициативную группу? Я для того интересуюсь чтобы знать, несу я радость многим людям или просто одному, который говорит о себе во множественном числе.

NB>но раз уж влезли в дискуссию, то потрудитесь изучить инструмент о котором рассуждаете.

Хороший совет, правда стилистически невыверенный. Начали с дорогого друга, а закончили хамством. Но совет хороший. Раз уж Вы присоединились к дискуссии, то почему бы для начала не выяснить о чем мы тут говорим, и о чем рассуждаю я? Вообще если в этой теме и обсуждается инструмент — то этот инструмент — макросы. Здесь же я рассуждаю не об инструменте, а о задаче. И критикую решение задачи, а не инструмент.

NB>Задачи на expression templates уже много лет не являются проблемой для С++ кодеров.

Верю. Вот только создание удобной библиотеки линейной алгебры является для expression templates, как техники, существенной проблемой. Похоже, что неразрешимой.

NB>Если у вас с этим сложности, то почитайте документацию. Ссылки были озвучены.

Почему Вы считаете, что я ее не читал? Или нужно читать и читать пока не исчезнут все симптомы интереса к линейной алгебре?

NB>Реализовывать в 1001 раз линейную алгебру для вас никто не будет.

Опять верю. Пока что ее никто не реализовал даже 1 раз. Линейную алгебру уже реализовывали на C++ один раз на 0,5, тысячу раз на 0,1 и 90050 раз на 0,01 — в том числе и один раз eao197 лично двумя сообщениями выше, так что вместе как раз 1001. Все это очень интересно, но, как говорил Дуглас Адамс, если миллион человек дыхнет на сырое мясо — оно не превратиться в зажареный бифштекс.
Меня интересует хотябы одна реализация на 1. Ну или, на худой конец, одна реализация на 0,9.
Я понимаю, что уметь выдавать перекрашенный фонарный столб за межконтинентальную баллистическую ракету (ну или хотябы убедить, что нужен именно фонарный столб, а не ICBM) для программиста вопрос профессиональной компетентности, но не согласитесь ли Вы, что я как физик имею больше оснований для оценки библиотеки линейной алгебры чем самый пламенный любитель expression templates?
А пока что выслушаешь рекомендации на Blitz++, укажешь на какой-нибудь пустячек вроде четырехкратного оверхэда как здесь

Автор: Klapaucius
Дата: 11.07.07

, например, а собеседник сразу скучнеет и убегает рекламировать Blitz++ в другое место.

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

AVK>Нет, dynamic proxy это другое. TP возможно реализовать только с помощью рантайма.
Я не вижу чем это отличается от java.lang.reflect.Proxy или Javassist.

Вообще, .NET и рядом не стоит по библиотекам манипуляции байт-кодами с Java.

C>>WCF — это вот это?
AVK>Релиз уже есть? И, что характерно, там явно указывается что ноги растут из WCF .
Так это просто пакеты с реализацией WS'ов. У JBoss'а тоже что-то есть на эту тему. Честно говоря, я вообще не интересуюсь ими. Так что не слежу совершенно что там и как.

А вообще, в Java есть http://java.sun.com/developer/products/jini/index.jsp — вроде бы функциональный аналог WCF (и появился, что характерно, раньше всего hype'а с WebServices).

C>>Это философский вопрос. Делаешь интерфейс с одним методом "public <T> T execute(Object ...params)" и все. Да, в .NET меньше синтаксического оверхеда, но это чистый сахар.
AVK>Нет, не сахар. Делегаты поддерживаются на уровне рантайма, а в джаве делегатов нет. И в свете ковариантности делегатов и вывода типов анонимные классы выглядят далеко не полноценным заменителем.
Пока сахар. Ковариантность для методоа в Java есть.

Вывода типов пока действительно нет — но Scala это исправляет

C>> А в JDK7 вообще очень вероятно появление лямбд и настоящих замыканий.
AVK>Если уж LINQ нет, хотя beta 2 уже feature complete, то и лямбд с замыканиями в джаве тоже нет.
Ну да, в Java есть Hibernate и его поддержка в IDEA — что еще для счастья нужно?

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

C>>Я просто не могу упустить случая посмеяться над .NET-итстами.
IB>Поговорку про смех без причины знаешь? Могу напомнить.


C>>Ага. А Hibernate — не ORM, а универсальная система работы с данными. Не веришь?
IB>Не верю. Или ты хочешь сказать это в оправдание его кривизны?.. =)
Почему? В Hibernate подключаешь любой провайдер — и работаешь с любым источником данных. Вот, для XML, например: http://www.hibernate.org/hib_docs/reference/en/html/xml.html

C>>Ага. Тогда в качестве антипримера можно взять RSDN — сколько он у нас глючит?
IB>На RSDN глючит железо. А если бы RSDN был написан на яве с гибернейтом, то железа бы требовалось в два раза больше.
Зато бы работало

У меня вот тоже в кластере железо пару раз подглючивало (RAID-карты оказались кривыми). И ничего, все работало — клинеты даже ничего не замечали, все прозрачно делало failover.

C>>Почему тогда RDB — не тупиковое направление?
IB>Потому что пока ничего лучше не придумали.
Объектные и гибридные базы, например.

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

GZ>Ты знаешь, а такой язык есть. Называется XQuery. Чистый, функциональный язык. Только он не является языком общего назначения, со всеми вытекающими последствиями.

GZ>Что касается ленивости, то тут несколько неприятных проблем. Подобные прикладные системы имеют понятия транзакционности(притом и кэша и бд и файлов и многого еще чего). Из чего следует что многие действия должны выполняться в строгой последовательности. А для этого придется иметь императив.

Не уверен. Мы можем описывать только ожидаемый результат. А последовательностью исполнения пускай занимается оптимизатор. Ты же не указываешь порядок JOIN'ов в SQL, когда их несколько?

А с транзакционностью можно тоже работать чисто и лениво — см. Software Transactional Memory (STM), и, в частности, Beautiful concurrency (уже вроде обсуждали в Философии).

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

EC>>>Type safety тебя не заботит?
C>>Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?
EC>А как будет решаться следующая проблема с помощью интерфейсов:
EC>в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.
Можно пример на делегатах?

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

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

EC>>>>Type safety тебя не заботит?
C>>>Ну тогда делаем типизированые интерфейсы. Какие проблемы-то?
EC>>А как будет решаться следующая проблема с помощью интерфейсов:
EC>>в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.
C>Можно пример на делегатах?
Давай по-другому. Я на джаве не пишу и могу что-то путать. Поэтому прошу уточнения.
Чтобы позвать метод некого объекта в джаве, не зная точный тип объекта ты что делаешь?
Объявляешь интерфейс с одним методом с подходящей сигнатурой и реализуешь его в отдельном классе или в классе, метод которого надо позвать?

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

C>>Можно пример на делегатах?
EC>Давай по-другому. Я на джаве не пишу и могу что-то путать. Поэтому прошу уточнения.
EC>Чтобы позвать метод некого объекта в джаве, не зная точный тип объекта ты что делаешь?
То есть? Используешь обычный полиморфизм.

EC>Объявляешь интерфейс с одним методом с подходящей сигнатурой и реализуешь его в отдельном классе или в классе, метод которого надо позвать?
Я уже совсем запутался. Можешь все-таки пример привести? Хотя бы на псевдокоде.

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

GZ>>>>>На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.
IT>>>>Точно? Проверял или сам догадался?
GZ>>>Нет. Догадался.
IT>>Я так и знал.
GZ>
GZ>Факты в виде цифр есть?

Вообще-то, это мой вопрос.

IT>>В общем, я твою точку зрения понял. Я её не разделяю.
GZ>А по моему, нет. Я против такого термина как pass-through как плюса подхода LINQ2SQL.

pass-through как термин существует вне зависимости от линка. Это объективная реальность, присутствующая в большинтсве правильно спроектированных проектах, в которых логика диктуется UI.

GZ>Также, я не особо верю что макросы, как аналогичный функционал, спасут мир и будут концептуально лучше чем LINQ2SQL.

Макросы как альтернативу линку я привёл лишь в качестве примера. Мысль состоит в том, что на макросах можно было бы сделать такой же линк и даже лучше, но ещё вчера.

IT>>ООП не может быть преимуществом сам по себе. Это тоже самое что сказать, что преимущество гвоздя в том, что он забивается молотком.
GZ>ООП — это преимущество перед гипотетическими макросами. Его подводные камни — известны. И как писать сопровождаемый код вполне известно.

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

GZ>>>LINQ2SQL — можно считать заменителем или хелпером для DAL.
IT>>Ты вообще в курсе для чего нужен DAL?
GZ>Получение(изменение) данных, и трансформация из модели источника к логической модели и наоборот.

Ответ неверный. DAL нужен для изоляции кода, работающего с БД от остальных частей приложения. Ключевое слово здесь изоляция. Проблема в том, что фактически мы пишем код на двух языках, при этом один из них, SQL, вообще никак не контролируется компилятором. DAL изолирует этот код и не позволяет ему расползаться по всему приложению.

При этом DAL не решает проблему полностью. С помощью DAL мы загоняем её в дальний угол, где её можно лучше контролировать. Но не более того. Проблема всё ещё существует.

Что делает линк. Линк позволяет работать с БД в терминах основного языка, компилятор которого теперь может на 100% контролировать правильность кода работы с БД ещё в компайлтайм. Это происходит потому, что линк не оперирует строками, а исключительно строготипизированными метаданными. Кстати, на макросах можно было бы пойти ещё дальше — автоматически синхронизировать эти метаданные с БД во время компайл-тайм.

Так вот, теперь подумай, если проблема, которую раньше решал DAL исчезла, то зачем нужен сам DAL?

IT>>

IT>>class UI
IT>>{
IT>>  void OnLoad()
IT>>  {
IT>>    binder.List = from c in Customer select c;
IT>>  }
IT>>}
IT>>

GZ>Пример достойный example или простейшего проекта.

О! Видишь что с людями делает декларативщина? Тебе этот код кажется примитивным? Правильно. А почему? Да потому что в нём нет ничего лишнего. Ни одного лишнего элемента. Учитывая, что в обычном коде мусора как правило больше половины, то смотря на такой код хочется зажмурится, как когда смотришь на яркий свет. Что-то тут не так, где-то нас обманывают. Только с декларативностью можно добиться такого примитивизма.

IT>>Можно для лучшей наглядности замешать сюда ещё и ad-hoc запрос.
GZ>Можешь показать как?

Я уже показывал выше. Впрочем, вот копипейст:

grid.Source = from c in customers   
              join o in orders on c equals o.Customer into oo   
              select new { c.CompanyName, OrderCount = oo.Count()

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

IT>>Теперь сформулируем вопрос по-другому. Что тебе реально даст оставление двух таких pass-through методов в данном случае, учитывая что вся логика здесь диктуется UI?
GZ>Логика по любому диктуется UI. Если пользователь не чуствует работу той, или иной функции — то эта функция не нужна.

И как тебе в этом случае поможет наличие pass-through методов?

GZ>OK. Кое что, ты уже описал. Нужно вставлять кэширование, секьюрити, логгирование и e.t.c. И желательно, чтобы вызовы были в одном слое,

Зачем? Какую проблему мы решаем располагая все вызовы в одном слое?

GZ>а посему — даже во избежание бардака стоит делать pass-thought когда оных функциональностей нет. Одни и те-же вызовы могут использоваться в различных прецедентах, в том числе которые могут быть написаны после оной итерации.

А после следующей итерации у нас появятся методы, которые вообще никем не используются. И так и будут висеть по жизни рудиментами и атавизмами.

GZ>В ситуации бардака, стоимость внесения изменений увеличивается.

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

GZ>Ежели оные объекты еще публикуются через API (то есть должны быть отчуждаемы), то все совсем плохо. Но что совсем плохо — проект без выделенного слоя становится не тестируемым.

Что именно ты собираешься тестировать? Соответствие имён полей структур и полей таблиц в БД? Так это за тебя уже сделал компилятор.

GZ>А посему — LINQ2SQL может быть заменой(хедпером) DAL, но не более того. В остальном он сопровождаемых решений не дает.

Это заблуждение. Точнее, нежелание отказываться от старых привычек.

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

IT>>Я уже у Глеба спрашивал, могу тебе задать тот же вопрос. Ты вообще в курсе зачем нужен DAL?
C>Вообще-то да. Поэтому у меня он сведен к минимуму

Если ты его сводишь к минимуму, продемонстрированными выше способами, то это собственного говоря то, откуда 10 лет назад начали бежать и в результате прибежали к такому понятию как DAL.

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

>> binder.List = myMapper.select("from c in " + ReadCustomerTableNameFromXml() + " select c").list();
.>А зачем?

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

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

C>У меня вот тоже в кластере железо пару раз подглючивало (RAID-карты оказались кривыми). И ничего, все работало — клинеты даже ничего не замечали, все прозрачно делало failover.

Так мы тоже можем failover сделать. Оплатишь?

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

EC>>в классе есть 2 метода с одинковой сигнатурой и в зависимости от условий надо звать то один, то второй, при наличии извне ссылки на интерфейс.
C>Можно пример на делегатах?

class A
{
    private bool Foo() {...}
    private bool Bar() {...}
    
    static void Main()
    {
        bool flag = ...;
        var x = "abcdef".Find(flag ? Foo : Bar);
    }
}

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

C>Я уже совсем запутался. Можешь все-таки пример привести? Хотя бы на псевдокоде.
Ты таки заставил меня запустить Visual Studio
Типа так:

using System;

namespace Cyberax
{
    class Program
    {
        static void Main(string[] args)
        {
            Test2 t = new Test2();
            t.Action(1);
        }
    }

    class Test
    {
        public void Method1(int i)
        {
        }

        public void Method2(int i)
        {
        }
    }

    class Test2
    {
        private readonly Test _t = new Test();

        public Action<int> Action
        {
            get { return DateTime.Now.Second > 10 ? new Action<int>(_t.Method1) : new Action<int>(_t.Method2); }
        }
    }
}

Где Action это:

public delegate void Action<T>(T obj);

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

AVK>>Нет, dynamic proxy это другое. TP возможно реализовать только с помощью рантайма.
C>Я не вижу чем это отличается от java.lang.reflect.Proxy или Javassist.

Если ты не видишь, это не значит что проблем нет. Вот тебе псевдокод:

var x = GetProxy(...);
var y = x as Y;
Console.WriteLine(y == null); // false
y.AppendContract(typeof (Y));
var y = x as Y;
Console.WriteLine(y == null); // true

Такое ни на каких отдельно сгенеренных проксях ты не сделаешь.

C>Вообще, .NET и рядом не стоит по библиотекам манипуляции байт-кодами с Java.

TransparentProxy это не манипуляция байткодами, это CLR, сколько можно повторять?

AVK>>Релиз уже есть? И, что характерно, там явно указывается что ноги растут из WCF .
C>Так это просто пакеты с реализацией WS'ов. У JBoss'а тоже что-то есть на эту тему. Честно говоря, я вообще не интересуюсь ими.

Это и видно.
C>А вообще, в Java есть http://java.sun.com/developer/products/jini/index.jsp — вроде бы функциональный аналог WCF (и появился, что характерно, раньше всего hype'а с WebServices).

Если это функциональный аналог, зачем тогда Tango Project?

C>Вывода типов пока действительно нет — но Scala это исправляет

А при чем тут Scala?

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

G>Плохо объясняешь? Если ты словами задачу и проблему объяснить понятным образом не можешь,
А может просто ты не хочешь принять то что нет способа объехать данный комбинаторный взрыв?
Нужно же как-то доказать самому себе что макросы не нужны.

G>то каково то по твоему коду будет разбирать, интересно? С мега-макросами и всем прочим.
А мой код очень простой.
Причем он простой именно благодоря макросам.
Хотя не только. Я еще использовал визитеры, замыкания и немного зашаблонил.

Обязьянка конечно не поймет но их к разработке это либы и близко не подпустят.
А при использовании этой либы есть просто класс Image и набор свободных функций который этот Image плющат. И никаких макросов и прочего.

В любом случае понять почему альгоритмы (при реализации которых напрямую макросы не использованы) реализованны именно так, а не иначе будет во много раз сложнее чем понять как работают макросы снижающие сложность обвязки.
Те человек без опыта работы с изображениями разбирется с макрами за пол дня максимум, а на алгоритмы будет еще как минимум пол года смотреть непонимающими глазами.
Некоторые алгоритмы я и сам не понимаю я их просто скопипастил и причесал под мою обвязку.

G>Почему их несколько, а не один?
По тому что надо.
G>Сколько у тебя таких кластеров — в штуках, и сколько всего пространств, тоже в штуках?
А какая разница? Ибо либа не стоит на месте и в любой момент могут появится новые.

G>Не может такого быть, чтобы по другому было нельзя.
С потерей эффективности и точности можно. Но это не мой путь.

G>Да? И чем эти разные RGB отличаются, интересно? Ну не разрядностью же, ты ведь наверняка в плавающей запятой из преобразуешь, как разумный человек.
Работаю я в основном с плавучкой.
Но:
1)Я не в вакууме работаю
2)Некоторым алгоритмам пофигу с каким именно цветовым пространством они работают.
Те я могу загрузить картинку, повернуть ее на 90 градусов, увеличить в 2 раза (point sampler'ом) и сохранить.
При этом ни разу не приведя картинку в пространство с плавающей точкой.
Причем если дело дойдет до плавучки то придется не только приводить к плавучке но и производить нелениейные коррекции, а если есть альфа то еще и домножать каналы на занчение альфы..., а потом обратно...
3)Некоторым алгоритмам нужны битмапы с низкой разрядностью.
...

G>Тогда чем? Нелинейной шкалой яркости? При применении плавающей запятой это никак не повлияет на точность, все эти гамма-коррекции и прочие нелиейные шкали яркости правильно вынести за рамки пространств, сделав преобразованиями.
Тогда теряется контроль компилятора.
А это критично. Ибо если использовать цвета которые скоректированны не так то полезут артефакты.
А делать коррекции на каждый чих это очень дорого.
Я пробовал.
Это просадило библиотеку и по скорости и по объему и по запутанности кода.

G>Приведи пример двух разных RGB, если тебя не затруднит.
Линейное и прецептурно линейное. Отличаются грубо говоря гамма-коррекцией (реально там болие сложная зависимость но гамма-коррекция дает неплохое приближение).
Путать их нельзя. Иначе полезут артефакты.