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

Вобще в самом деле я тоже такой вопрос часто задаю бизнесс-пользователям, не помню что они мычат в ответ, но пока им не отдашь набор 100500 столбцов о 100500 строк, они, падлы, приемку не подписывают.

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

Да и форум винградовский слабоват, однака.   

Я понял о чем ты. Ты невнимательно посмотрел мой код. Тот метод расширяет класс Object, то есть доступен для всех типов и возвращает он тот же тип, а стало быть у возвращаемого значения снова можно вызвать этот метод. А о джинерик-параметре я сказал к тому, что если понадобится выражение писать дальше, то неплохо иметь подсказки интеллисенс, для динамических типов это в принципе невозможно.

С помощью апи пространства Microsoft.VisualBasic.CompilerSevices это будут не такие уже и монстры. Все равно будет одна строка. 

Да без проблем

Вот как это выглядит в декомпилированном на C# виде

Вот что  выдает этот код
Проект прилагаю, работает под 2-ым фреймворком. Архив в аттаче.



У метода GetMethod, ЕМНИП, 4 перегрузки. Там есть и такие, где можно передать собственный биндер. Изучи внимательнее.

Не знаю, не пробовал. Если тебе не влом протести сам. Но в любом случае, ты сильно преувеличиваешь критичность производительности и сложного биндинга перегрузок в таких сценариях. Я сколько пользуюсь поздним связыванием и могу сказать, что наиболее часто оно нужно для работы с ком объектами, например, из того же веббраузера можно вытащить ком-объекты и получить полных доступ к возможностям DOM, там нет никаких джинериков и прочего и там вполне сработает тот метод, который я привел, равно как и в подавляющем большинстве реальных примеров использования позднего связывания.

Генератор можно реализовать в виде объекта. Кстати я встречал библиотеку на яваскрипте, реализующую линк, в описании было сказано, что там используются ленивые вычисления(как в дотнете). Что меня удивило, так это то, что библиотека весила 26 кб что ли. Так что кода там совсем немного. Но дело совсем не в этом. Итераторы в языке для работы линка не нужны. В шарпе они появились 8 лет назад и тот факт, что не смотря на это ты в принципе на можешь объяснить для чего они нужны (я уже не говорю о том, на сколько порядков они могут увеличить эффектвность Злохи), сам по себе говорит о том, насколько эта фича востребована, по крайней мере в твоей практике.

Ну и каков итог в плане того, кто и как объясняет фичи.
Я привел тебе достаточно монструозный код с использованием Enumerable, показал, как конвейер делает с подобными вещами то же, что делает линк и далее на более простом числовом примере показал, что это работает для любых функций. Тебе этот пример показался недостаточно наглядным. 
Ты, в свою очередь, продемонстрировал какими должны быть наглядные примеры, на примере аргументов против дельфы. Из четырех пунктов мы получили следующее:
1. Необходимость в динамических типах ты обосновал возможностью позднего связывания. Отрадно, конечно, что в шарпе, наконец-то, спустя восемь лет после появления языка на свет, появилось позднее связывание, но хвалиться этим тоже надо смотреть перед кем, поскольку в дельфах, насколько я понял из этого топика, позднее связывание есть и динамические типы для этого не нужны.
2. Необходимость в генераторах, которые ты представил как архиважную фичу, ты не смог обосновать более убедительно, чем привести в пример другую фичу, где они были использованы. Особенно интересно здесь то, что итераторы появились в шарпе в 2005, линк и в шарпе и в бейсике - в 2008, а итераторы в бейсике - в 2012. Как-то не очень похоже, что это вообще как-то связано. 
3. Решарпер может и имеет кучу полезностей, но это все-таки внешний инструмент, каковые есть и у дельфы, да и пользуются им не все.
4. Использование кода на других языках, в том числе скриптовых, возможно и там, как реализовано - не знаю, но подозреваю, что вполне юзабельно.
 Как-то неубедительно  

Если человек знает что это, то конечно.

Ты о вычислении "наивным" способом? На 40-м члене функция будет вызвана более триллиона раз. Ниче так да?  

Присоединённый файл ( Кол-во скачиваний: 0 )
 LateBinding.rar 47,62 Kb

@Akella


Скрипт может запрашивать у игры информацию о юнитах, зданиях и других объектах; вызывать на них какие-то методы, передавать данные об изменениях в интерфейсе и т.д. и т.п. В общем, нужно полноценное взаимодействие.


Всё не так просто:

Plugins and host created using different development platforms can communicate seamlessly using custom interfaces you can define, and Hydra's IDE integration in Delphi and Visual Studio lets you seamlessly port these interface definitions between the two platforms.

You can define your custom interfaces in Delphi code, and let Hydra's toolchain parse the code to generate the necessary interface definitions in C#, VB, Oxygene or any other .NET language. Or you can define your interfaces in .NET and let Hydra import them into your Delphi project.

Взаимодействие сводится к "плагинам" и "хосту", которые общаются через создаваемые вручную, а потом генерируемые зеркальные интерфейсы. Нельзя просто взять и вызвать что-то, нужно городить кучу кода для каждого чиха, а потом перегенеривать часть кода. И это удовольствие ещё за $500.

В дотнете ты бесплатно можешь положить в один солюшен проекты на разных языках и просто использовать их, как будто они написаны на одном языке.


Ага. Прямо на главной странице: "Как раз сейчас производится подготовка к очередной большой доработке проекта (в т.ч. поддержка Unicode, Delphi >= 2009)." Если пользуешься средой пятилетней давности и никогда не локализуешь приложения -- да, зашибись. А если нет?  

Случай, кстати, очень показательный. Опен-сорсные проекты в подавляющем большинстве или заброшенные, или недоделанные, или кривые.


Этот энтерпрайз можно делать по-человечески, а не запихивать все данные в бесконечные гриды. Но все привыкли...


Значит, и сервер не на 256 ГБ оперативы. То есть свалится из-за фрагментации памяти всё равно.

@serger


Дык если контрол поддерживает такое извращение, то можно же просто его влепить при отключенном мозге и радоваться жизни, пока конечные юзеры чертыхаются и матерятся, пытаясь понять, как пользоваться этим непотребством. Идиллия г#внокодерства.  

@diadiavova


Мне не нужен вызов, в моём изначальном примере возвращалось число.


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


В итоге testobject = testobject.Replace("Anthary", "World") превращается в монстра:

Что, собственно, и требовалось доказать.


Биндер для шарпа есть? Потому что, если его нет, ты его на коленке не напишешь.

Я знаю, что есть биндеры для шарпа и басика, которые работают с CallSite. Наверное, если бы был биндер для шарпа в отражениях, его не реализовывали бы по новой?

Да и вообще, мы говорим о дельфи. Дельфовая RTTI и рядом не стояла с дотнетовыми отражениями, ЕМНИП.


Неправильно понял. Для дельфи есть минимальный proof-of-concept на Variant. Скрипты как через dynamic вызывать не выйдет.


Для дельфи нет сравнимых аналогов. Отсутствие решарпера удорожает разработку софта, поэтому не ставить его -- глупо.


Неправильно подозреваешь. Вон, в топике уже сколько ссылок всплыло: или работающее только под старую анси дельфи, или требующее кучу дополнительного кода и с перезапуском генератора кода после каждого изменения, причём за 500 баксов, или голые биндинги к страшному и ужасному API... Нет ничего сопоставимого.


Мы ж демонстрацией занимаемся, не?

Это утверждение нуждается в пояснении. Насколько я понимаю, все вызовы динамических членов возвращают такие же динамические объекты. Что там внутри - другой вопрос, но без приведения типов нормально работать с ними не получится. Аналогичная фигня получается и в моем примере, то есть метод возвращает Object, который на самом деле будет того или иного типа. Так что я тебя не понял.

Зачем? При чем тут решарпер? Разве мы говорили о вызове из определяющего класса? По твоему поведение динамических типов под решарпер заточено что ли?

Почему странно? Я приводил примеры интересного поведения динамических типов, зря ты их не посмотрел.

Ну не такой уже и монстр. Это одна строчка кода, упакуй ее в приведенный мной выше метод и наслаждайся. Я уже не говорю, что отсутствие позднего связывания - проблема шарпа старых версий и не более того.

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

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

И чем фибоначчи лучше факториала?

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

Но во view-то зачем тянуть?!

На языках .NET т. е.?



Что вообще типично для опен-соурса на всех без исключениях языках.



Вывод, VS - УГ.



Блин, попробовал конвертнуть под 2009+ хотя бы на уровне правильных typecast'ов. В итоге уперся в одну просто замечательную конструкцию. Где сначала класс TLua передается как const, потом от него берется проперти без write, которое аж object, и члену этого обджекта делается присваивание. Х) Блин, я не знаю, как это должно компилироваться в D7, но в XE3 в ситуации когда свойство возвращает структуру, или объект, присвоить что-то их полям нельзя, сеттера нету. Можно сделать методы для доступа к полям, это будет компилироваться, но я сам недавно нарвался на такую ситуацию, и не сразу въехал в чем дело, вроде все правильно, все верно, но раз структуры и обджекты передаются по значению, то метод присваивания с локальной копией и будет работать. В общем надо или класс, или указатель. Х)
Хотя думаю, что сам автор за день-два бы это перевел, нужно по сути выкинуть все обджекты, заменив на структуры, или классы, переделать ф-ии работающие со строками, возможно, лишь на уровне их заголовков. И что-то сделать с одной замечательной таблицей символов LowerChars, которую я бы просто заполнил двумя строчками кода в Initialization и такой дурью не страдал. Ну и замечательные ассемблерные вставки нафиг.

Любой тип приводится к dynamic и из dynamic без явного преобразования типа.

В этом примере, если foo вернёт не int, то будет исключение в рантайме.


Какие примеры?


Моя позиция: упаковать все фичи языка в один красивый метод -- невозможно. Если бы это было возможно, как ты думаешь, авторы дотнета изобретали бы таких монстров? Отмечу, что такие монстры у них получились уже пять раз минимум:

1. System.Reflection -- отражения;
2. VisualBasic.CompilerServices -- утиная типизация VB;
3. Runtime.CompilerServices.CallSite и др. -- общие классы для динамического типа;
4. Microsoft.CSharp.RuntimeBinder и др. -- динамический тип для шарпа;
5. Microsoft.VisualBasic.RuntimeBinder и др. -- динамический тип для басика.

Авторы этой части дотнета -- не индусы, которые пилят WPF, а самые высококлассные программисты, некоторые со всемирной известностью.


По-моему, ты совсем не осознаёшь сложности языка.

1. Открой файл C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC#\Specifications\1033\CSharp Language Specification.docx (также спецификация доступна в виде HTML)
2. Перейди к разделу 7.5.3 Overload resolution (стр. 152)
3. Прочитай полностью


Потому что это разные языки, и правила выбора методов у них разные.

1. Открой файл C:\Program Files (x86)\Microsoft Visual Studio 11.0\VB\Specifications\1033\Visual Basic Language Specification.docx (также спецификация доступна для скачивания онлайн)
2. Перейди к разделу 11.8.1 Overloaded Method Resolution (стр. 238)
3. Прочитай полностью


Тем, что это не "линейная" рекурсия, а "ветвистая".

Обращу внимание ещё раз: C# -- это исторически очень "засахаренный" язык с тьмой фич и желанием его авторов сохранить в языке лаконичность. В нём даже грамматика -- за гранью добра и зла, потому что новые ключевые слова часто делаются контекстно-зависимыми, чтобы не ломать обратную совместимость. Например, можно объявить классс "var", переменную "var" класса "var", при этом ключевое слово "var" станет недоступно. У дженериковых методов не нужно указывать аргументы-типы, если они могут быть хоть как-то выведены из аргументов ("хоть как-то" -- это с разбором всех логических выводов из доступных типов аргументов, и выведение типа одного аргумента по частичной информации из другого аргумента). Таких вещей -- море. Всё это делается ради того, чтобы сам язык был максимально кратким, понятным, логичным, без "сюрпризов". Но спецификация и тем более реализация языка превращается в сущий кошмар.

Ну что тут можно сказать... C# в этом смысле вообще проблемный язык, в бейсике, если отключить Option Strict (а по умолчанию она и так отключена), то явные преобразования придется выполнять только тогда, когда это действительно критично(например в случае сужающих преобразований). Тип Object тоже можно неявно к чему угодно приводить. То есть это опять-таки проблема конкретно языка C#. Я вот совсем недавно писал немного кода на C#, там надо было создать замыкание и вдруг узнал, что оказывается неявно типизированные переменные нельзя инициировать лямбда-выражениями. Почему нельзя? В бейсике можно, я всегда так делаю, прекрасно выводится тип. Почему в шарпе вдруг нельзя? И таких вариантов туева хуча. Поэтому, не смеши лучше, рассказывая о том, какие чудеса начали происходить с появлением динамических типов. Правда смешно.  


Которые ты как всегда окрестил абстрактными.  

Упакуй то, что тебе нужно. И чем по-твоему являются динамические типы, как не упаковкой подобных "монстров"?

А ты создаешь проблему на ровном месте. Те случаи, когда требуется сложный биндинг - единицы, с которыми можно вообще никогда не столкнуться. Я лично, придумать такие вряд ли вообще сумею (не знаю, возможно у тебя получится). В тех единичных сложных ситуациях можно и написать немного ручного кода, для всего остального есть мастеркард  простое решение, которое будет работать безотказно.
В бейсике позднее связывание работает прекрасно, я ни разу не сталкивался с проблемой вызова не того метода например, этот вариант можно экспортировать в шарп и не париться, но нет же тебе надо выдумывать себе проблемы. Тебе видимо и C# нравится больше бейсика именно потому, что он более проблемный  

И как она улучшает показательные возможности примера?

@Beltar


Да. Их всего лишь 36 штук: http://en.wikipedia.org/wiki/List_of_CLI_languages

Для JVM ещё больше: http://en.wikipedia.org/wiki/List_of_JVM_languages

Есть приёмы для взаимодействия Java и .NET (конвертация в IL в частности), так что при большом желании удалять гланды через анус можно использовать любой язык из этих списков.




Linux, Firefox, Chrome, MySQL, PostgreSQL, Eclipse, OpenOffice, Apache, Android, Webkit, Python, Perl, Git, Hg, Nginx, Node.js, WordPress, Drupal, jQuery, Ruby on Rails -- не слышал?

Ну и по части шарпа: ASP.NET MVC (веб по-правильному), Rx/Ix (асинхронность), Mono (кросс-платформенный .NET), MonoGame (кросс-платформенная разработка игр), Json.net (такая сериализация тебе не снилась), log4net, NAnt, WiX, NUnit, Simple.Data, Paint.net, AutoMapper, CsQuery, IronPython, IronRuby...


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


То есть переписывать некому. Ч. и т. д.

Ассемблерные вставки, кстати, могут быть и не от хорошей жизни, а из-за необходимости.

Вар - это костыль, изобретенный из-за того, что все декларации начитаются с имени типа. В бейсике нет ни вара ни динамика при том, что все фичи с ними связанные есть, они реализованы на тех возможностях языка, которые в нем и так были.

Как я уже показал, вывести тип делегата при неявной типизации замыкания шарп не может и это не единственная странность. А вот если бы ты  ознакомился с  возможностями выведения типов в F#, то понял бы, что то что есть в шарпе и васике - уг по сравнению с этим.

По этому показателю шарпу до васика ой как далеко. 

Дельфи отстой, пруфы во всех постах Beltar, инфа 100%  



У нас организация с ~100к сотрудников, десктопов где-то ~120к, плюс виртуалки. Так вот что я вам имею сказать по поводу организации этого всего безобразия: все компы в домене, на всех компах стоит софт для централизованной установки ПО и системных апдейтов, софт для удаленного администрирования и антивирус. Права админа на локальный комп даются по специальному запросу. Свой комп в общую сеть воткнуть нельзя. Админов я вижу только если надо железо менять (не научились они пока через RDC это делать  ). Винда и офис лицензированна целиком на всю организацию.



Плохо уговариваете, мы своих продавили 1000 строк и все, иначе please refine search criteria.

@diadiavova


Авторы языка объяснили, что данная фича слишком проблемная, а пользы от неё мало. Простая реализация (предполагание Func<> и Action<>) не решает все случаи (out/ref аргументы, в частности).

Это мелочь на самом деле. Меня гораздо больше достаёт, что переменной типа void delegate() нельзя присвоить значение Action -- типы "не совпадают". Так как раньше Func/Action не было, то в дотнете куча кода с явно именованными делегатами. И их просто так не попередаёшь.

Надеюсь, что эту глупость всё-таки исправят. Вон, ко-/контр-вариантность одолели же.


Как особенности вывода "var" соотносятся с преобразованием результатов динамического вызова? Твоя фраза звучит как "в этом вашем шарпе деление байта на байт не даёт байт, поэтому отсутствие сборки мусора в дельфи -- не проблема". Абсолютно столько же логики.


Они в языке выглядят красиво, потому что поддерживаются компилятором. По той же причине выглядят красиво yield return/break или await/async, хотя внутри происходит кошмар. Компилятор этот кошмар скрывает с глаз долой.

У тебя такой возможности в дельфи -- нет. Твой метод находится в рамках языка дельфи, у тебя нет доступа к преобразованию исходного кода.

В шарпе, кстати, compiler as service пилят. Так что такая магия станет доступной. (Не знаю, в каком объёме -- ещё не пробовал беты.)


Всё используется, и очень часто.

Console.WriteLine -- multiple overloads, params parameter
Dictionary<K,V>.TryGetValue -- out parameter, generic type
Enumerable.Select<S,R> -- overloads, generic method, lambda type inference
WebResponse.Dispose -- explicit interface implementation

@diadiavova


Как можно создать объект какого-то типа, явно не указывая тип, если не пользоваться каким-то встроенным синтаксисом для данного конкретного типа (списки, словари, множества, кортежи во многих языках) и не вызывать метод, который возвращает объект данного типа? Ну вот как ты в басике создашь Tuple<Dictionary<int, List<string, Nullable<int>>>, ISet<double>>, не произнеся эту конструкцию?


Я тебе про Фому, ты мне про Ерёму. По кругу. Ты невыводимый в var делегат будешь в каждый аргумент в споре вставлять?  


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


Примеры? Мне, вообще говоря, пофиг, потому что на VB писать не буду, но всё равно любопытно.

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