Sinclair однажды (11 марта 2009 14:57) писал в rsdn.flame.comp:

> Здравствуйте, kuj, Вы писали:
> kuj>Страуструп писал о С#? Что-то я пропустил...
> Нет, не писал. Но Шеридан свое мнение про C# основывает исключительно на нём. Потому как никаких книг по шарпу он не читал.
Читал какието когдато давно, когда еще я нус помогал писать... Уже и не помню что, раздарил...

> Зато вот в обсуждении стоимости виртуального вызова в CLR он приводил скриншоты именно из Страуструпа.
Это из "Дизайн и эволюция С++"

--
Бортовой журнал

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

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

C>>>Таки именно для этого — как lightweight ORM для мэппинга результатов запросов из РБД на туплы. Естественно, LINQ можно использовать и для других целей, но изначально они таки для доступа к БД делался.
G>>Фигню говорите. Linq изначально язык объектых запросов, Linq2SQL прикрутили к релизу .NET 3.5 именно как proof of concept, а потом забросили, потому что параллельно развивался EF.
C>

C>The original idea of integrating data access into the general purpose programming language first appeared in the Cω research project at Microsoft Research. The data access possibilities integrated in Cω includes working with databases and structured XML data. The LINQ project is mostly based on Cω, however there are some differences.

C>Собственно, где-то были статьи про то, что LINQ добавили из-за того, что наиболее частой задачей для C# является работа с базами данных, и надо было как-то её упростить. То что LINQ можно использовать для запросов к нереляционным источникам — вполне логичное продолжение.
Идея встроенного языка запросов появилась потому что хочется типизированно работать с БД.
Но утверджать что Linq создавался для доступа к данным ошибочно.

ЗЫ. В википедии в статье по Cω приводится пример именно работы с коллекциями объектов.

kuj однажды (11 марта 2009 13:44) писал в rsdn.flame.comp:

> Тогда уж:
>

> ФФ — страшный тормоз уже по сравнению со всем под маком и линухом

Осторожнее с рекурсией


--
Бортовой журнал

S> > Покажи где хоть раз предлагали использовать другой .NET язык для такой банальной вещи как ФВП?

S> Почитай, тут сплошь и рядом скачки от немерля к Цшарпу и Фшарпу и обратно.

В случае ФВП таких скачков не было. Хотя... Ты же не знаешь, что такое ФВП...

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

C>>XAML и всё такое...
D>Гы! Сериализация сериализации рознь. XML-сериализация в том же .NET существует с незапамятных времён. Однако к XAML'у это не имеет никакого отношения.
Да я знаю. Просто я имею в виду, что есть именно аналоги XAML, а не просто дампы деревьев объектов.

MK>>>Но в самом деле, интересно, какие факторы позволили записать SWING в аналог WPF?
C>>Явное разделение вида и модели,
D>Понятно. WPF Вы видели только на фотографии... причём чёрно-белой Swing, впрочем, похоже тоже.


D>Модель всегда отделена от её визуального представления, как минимум на логическом уровне. На то она и модель собственно.
Она не отделена в WinForms и других подобных фреймворках. Скажем, в WinForms текстовое поле просто содержит строку, которую ты берёшь как "ctrl.Text".

Для сравнения, в Swing'е для JTextField для хранения и редактирования текста используется модель документа — http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/Document.html , который ты можешь реализовать поверх чего угодно. Вообще, в Swing'е даже у combobox'а есть своя модель (ComboBoxModel).

Аналогично и в WPF — только там для этого используется обобщённый DependencyObject.

D>И задача состоит не в отделении, бо оно аксиома, а в обеспечении мощных и в то же время выразительных, простых и удобных механизмов связи модели с её конкретной визуализацией. Их и предоставляет WPF — binding'и для dependency property. Подобных вещей в Swing'е просто не существует.
В Swing'е это реализуется с помощью виртуальных моделей. Binding реализуется с помощью сторонних библиотек — https://binding.dev.java.net/ , к примеру.

В WPF оно всё сделано более обобщённо и красиво, но суть та же самая осталась.

C>>отход от оконной модели интерфейса.
D>М-м-м... А где это в Swing'е-то можно увидеть ???
Что именно? В Swing'е рисованием компонентов занимается look&feel, который отделён от самого контрола и может меняться (в том числе в runtime'е). Это можно на SwingSet2 посмотреть из поставки JDK. В JavaFX оно ещё больше отделено — есть явная концепция scene graph'а, на котором можно запускать анимации.

C>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
D>Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например.
Лучше явно выделять такие сервисы в сервисные классы.

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

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

C>>>Явное разделение вида и модели, отход от оконной модели интерфейса. Точнее, тут уж скорее WPF будет аналогом SWING'а, если смотреть на приоритет.
MK>>Ну. Ладно. Я надеялся увидеть больше конкретики, но т.к. Swing не знаю, спорить не буду.
C>Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.\
Конкретно в чем заключается схожесть? Если в MVC, то что конкретно понимается под идеей MVC в Swing и WPF?

MK>>>>Еще интересно, что кривого в extension methods?
C>>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
MK>>Extension methods используют публичный контракт класса, так что по факту никакого нарушения инкапсуляции нет.
C>Они маскируются под методы класса. Это уже нарушение.
Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП.

MK>>>>Ну и к библиотекам тоже самое... вообще пугает меня это разнообразие библиотек в проектах, тонны всего стороннего..
C>>>Более того, оно ещё умеет автоматически устанавливаться по зависимостям!
MK>>Что устанавливаться, куда устанавливаться? Setup-проект в Студии тоже все сборочки упаковывает "по зависимостям".
C>См.: Maven2. Я прописываю в файле зависимость от org.hibernate:hibernate:3.2 и оно мне скачает Hibernate 3.2 с зависимостями из публичнго репозитория (http://repo2.maven.org/maven2/) и добавит в проект.
Ты правда считаешь, что это какая-то мега-супер-фича? А как ты узнал, что нужно прописать зависимость в виде строки "org.hibernate:hibernate:3.2"? Нашел? Ну так и я нужную библиотечку найду. Мест полно.

MK>>>>Оно что, правда весьма безглючно, надежно и не требует грабель?
C>>>Основные проекты (Spring, Hibernate, Apache *, ...) — надёжны, мне баги в фреймворках проблем не создают вообще.
MK>>Баги = фичи?
C>Недокументированые фичи.
И после этого ты указываешь нам на кривизну extension методов?

MK>>>>"Тут опять разница между теорией и практикой проявляется"
C>>>Опять же, реально уже вполне есть нормальные альтернативные языки для JVM, которые широко поддерживаются фреймворками. Тот же Groovy и BeanShell.
MK>>Не, ну это уже двойные стандарты
C>Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться.
Уверен, можно пользоваться: C#, VB.Net, C++\CLI, Delphi.Net, F#, J#, Nemerle, IronPython. Мало?

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

C>>Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.\
MK>Конкретно в чем заключается схожесть? Если в MVC, то что конкретно понимается под идеей MVC в Swing и WPF?
Ответил в другом письме.

C>>Они маскируются под методы класса. Это уже нарушение.
MK>Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП.
Ext. methods часто используются для нарушения SRP.

C>>См.: Maven2. Я прописываю в файле зависимость от org.hibernate:hibernate:3.2 и оно мне скачает Hibernate 3.2 с зависимостями из публичнго репозитория (http://repo2.maven.org/maven2/) и добавит в проект.
MK>Ты правда считаешь, что это какая-то мега-супер-фича?
Ага.

MK>А как ты узнал, что нужно прописать зависимость в виде строки "org.hibernate:hibernate:3.2"? Нашел? Ну так и я нужную библиотечку найду. Мест полно.
Узнать — это фигня. В общем, читай предидущие флеймы про Maven.

MK>>>Баги = фичи?
C>>Недокументированые фичи.
MK>И после этого ты указываешь нам на кривизну extension методов?
Ну вообще-то, это достаточно общепринятое определение

C>>Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться.
MK>Уверен, можно пользоваться: C#, VB.Net, C++\CLI, Delphi.Net, F#, J#, Nemerle, IronPython. Мало?
J# — нельзя, Nemerle — весьма условно, VB.NET — зачем? Iron.Python и F# — это да, хорошие вещи.

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

D>>Чушь. С инкапсуляцией здесь всё в порядке. Мы просто тип расширяем. Можете смотреть на этот момент как на облегчённую форму наследования, например.
C>Лучше явно выделять такие сервисы в сервисные классы.

:) А extension methods, по-твоему, как реализуются? Ты даже можешь писать не так:

"Hello".MyExtensionMethod(args);

а так:

MyStringExtensionMethods.MyExtensionMethod("Hello", args);

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

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

MK>>>>Еще интересно, что кривого в extension methods?
C>>>Нарушение инкапсюляции (я знаю, что они не нарушают права доступа) — все методы класса должны быть в нём.
G>>Где нарушение инкапсуляции?
C>Методы маскируются под объектные...
Ну и что? Где нарушение инкапсуляции?
Нарушение инкапсуляции это когда для работы с объектом требуется знать о нем больше, чем только публичный контракт. Распухший публичный контракт класса говорит о том что инкапсуляция у вас была где-то нарушена.
Экстеншен методы не требуют дополннительных знаний, кроме того вынос некотороых методов класса в экстеншены позволяет упростить публичный контракт, что только улучшит инкапсуляцию.

C>>>Да, до некоторой степени, к сожалению. Но Скала постепенно становится практикой — она начинает поддерживаться в IDEA ( http://plugins.intellij.net/preview/popup/?sid=1682&pid=1347 )
G>>У меня на этом форуме стойкое чувство дежавю. Когда начинают говорить про фичи ФП в джаве сразу начинают рекомендовать скалу.
C>Ну да. Это как-бы аналог C# в мире Java, когда сама Java — аналог VB.NET.
В VB.NET тоже много фич, которых в Java нету и в ближайшее время не будет.
Вообще в свете выравнивания VB.NET и C# по фичам в десятой\четвертой версии уже нет смысла рассматривать их как сильно разные языки.

G>>Далеко не все могут изучить еще один язык, а те кто могут изучить не всегда смогут его использовать.
C>То же относится к ФПшным фичам в C#.
С чего бы это? Не нужна ни другая среда, ни другой компилятор, да и основные идиомы остаются теми же, да и не видел я ни одного случая когда человек который пишет на 2008 студии не использовал бы фичи C# 3.0

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

S>gandjustas однажды (11 марта 2009 11:33) писал в rsdn.flame.comp:

>> Покажи где хоть раз предлагали использовать другой .NET язык для такой банальной вещи как ФВП?
S>Почитай, тут сплошь и рядом скачки от немерля к Цшарпу и Фшарпу и обратно.
Если не занешь — молчи.
C# и F# поддерживают функции фвысшего порядка.

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

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

C>>>Что именно более конкретно нужно? Сам по себе Swing мало похож на WPF, но идеология в них сходная.\
MK>>Конкретно в чем заключается схожесть? Если в MVC, то что конкретно понимается под идеей MVC в Swing и WPF?
C>Ответил в другом письме.
Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется?

C>>>Они маскируются под методы класса. Это уже нарушение.
MK>>Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП.
C>Ext. methods часто используются для нарушения SRP.
"Вы это по матерному, а-ли по научному" (c) Куклу
Конкретнее, без теории, ближе к практике.

MK>>А как ты узнал, что нужно прописать зависимость в виде строки "org.hibernate:hibernate:3.2"? Нашел? Ну так и я нужную библиотечку найду. Мест полно.
C>Узнать — это фигня. В общем, читай предидущие флеймы про Maven.
Значит геммора тоже хватает. Ну...

C>>>Почему? Я не рассматриваю какой-нибудь Haskell для Java — его просто для практических целей не существует. А вот Groovy нормально поддерживается IDEA и Eclipse, т.е. им можно пользоваться.
MK>>Уверен, можно пользоваться: C#, VB.Net, C++\CLI, Delphi.Net, F#, J#, Nemerle, IronPython. Мало?
C>J# — нельзя, Nemerle — весьма условно, VB.NET — зачем? Iron.Python и F# — это да, хорошие вещи.
Зачем, зачем... Чтобы Шеридан наконец научился хоть что-то толковое под .Net писать.
И без того имеем разные другие хорошие вещи, на чем думаю данный абзац можно завершить

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

Q> А extension methods, по-твоему, как реализуются? Ты даже можешь писать не так:
Да знаю я как они реализуются.

Q>

Q>"Hello".MyExtensionMethod(args);
Q>

Q>а так:
Q>

Q>MyStringExtensionMethods.MyExtensionMethod("Hello", args);
Q>

А лучше так ValidationServices.validateEmail("Hello@aaa.com").

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


C>>>Они маскируются под методы класса. Это уже нарушение.
MK>>Нет, они не маскируются под методы класса. Intelliscense, как и MSDN, явно выделяет extension методы. Но даже, если бы это было не так, я по прежнему не вижу, что они нарушают. Не согласен, приведи реальный пример, где использование extension methods опасно с точки зрения ООП.
C>Ext. methods часто используются для нарушения SRP.

Это как?

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

C>>Ответил в другом письме.
MK>Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется?
Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка.

А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству.

C>>Ext. methods часто используются для нарушения SRP.
MK>"Вы это по матерному, а-ли по научному" (c) Куклу
MK>Конкретнее, без теории, ближе к практике.
Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".

C>>Узнать — это фигня. В общем, читай предидущие флеймы про Maven.
MK>Значит геммора тоже хватает. Ну...
Нет, там .NET-овцы тоже утверждали, что потребности в колбасе нет.

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

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

C>>>Ответил в другом письме.
MK>>Я честно говоря вообще не увидел связи между ComboBoxModel и DependencyObject. Давай лучше так. Вот у меня есть "модель документа". Как оно используется?
C>Вот у тебя есть список элементов — реализуешь ListBackedListModel, и твой комбо-бокс будет отображать элементы этого списка.
C>А можешь реализовать BindingListModel, которая занимается binding'ом к другому свойству.
Я ничего не понял. Для меня WPF — это прежде всего шаблонность. Возможность через XAML изменять визуальное представление любого элемента управления без всякой строчки кода, используя любые примитивы. Ничего не стоит за 10 минут сворганить гибрид ListView с ListBox'ами в качестве item'ов, где элементы ListBox'а располагаются по горизонтали, а не по вертикали... И это только малая часть. Как это решается в Swing?

C>>>Ext. methods часто используются для нарушения SRP.
MK>>"Вы это по матерному, а-ли по научному" (c) Куклу
MK>>Конкретнее, без теории, ближе к практике.
C>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".
Если в моём конкретном проекте класс String должен уметь валидировать email, то почему-бы и нет?

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

C>>>Ext. methods часто используются для нарушения SRP.
MK>>"Вы это по матерному, а-ли по научному" (c) Куклу
MK>>Конкретнее, без теории, ближе к практике.
C>Single Responsibility Principle. Нефиг в класс String добавлять методы "validate email".
Если почитать про SRP, то можно понять что экстеншены не нарушают этот принцип.

Вообще экстеншены — не добавление методов в класс, вызов через точку — синтаксический сахар. Вполне мог бы быть вызов через любой другой значок, например -|- или ==]======>.

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

G>==]======>.
call by dick

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

C>А лучше так ValidationServices.validateEmail("Hello@aaa.com").

Ну, это уже зависит, как лучше.

Когда ты формируешь запрос типа

var books = dataContext.Books
  .Where(b => b.Title.Contains("LINQ"))
  .OrderBy(b => b.Title)
  .Take(20);

раскрытие каждого extension method'а в цепочке как статического метода было бы совершенно неудобно.

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

C>Нет, там .NET-овцы тоже утверждали, что потребности в колбасе нет.

Раз овца, значит Долли, раз множественное число, значит много, раз много и Долли, значит клоны, раз много клонов, значит стадо... Граждане! Он вас стадом тупых клонированных овец обозвал!

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

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

G>>==]======>.
MK>call by dick
Я же вроде стер член и нирисовал меч.
Спалился блин...