go-mno рулит!

давить эту майкрасофтовскую какашку, JAVA Forever!

ИМХО, проект не имеет будущего. В PHP, Java, MySQL и прочих продуктах сам оригинальный производитель делает версии под разные операционки. Поэтому логично рассчитывать на одинаковое поведение продуктов на разных ОС (как глюки, так и правильное поведение). В случае же Моно - некая сторонняя компания пытается догнать и перегнать оригинальную фирму разработчика, которая все время совершенствует свой продукт. Напоминает борьбу Intel и AMD. На мой взгляд те, кто пишет на .NET будут писать именно на платформе Windows, те, у кого задача писать под Unix - будут выбирать готовые хорошие решения типа Java или PHP. Я сам программист на .NET, но у меня и в мыслях нет разбираться с глюками Mono, мне хватает оригинального .NET

Лучше бы кто-то релизовал XAML, чтобы к выходу Longhorna у винды не было преимуществ...

2anonymous (*) (27.04.2004 15:30:31):"Я сам программист на .NET, но у меня и в мыслях нет разбираться с глюками Mono, мне хватает оригинального .NET"

Продолжай игнорировать, нам работа и бабло достанется. Кстати сказать по негласному опросу менеджеров : они не спускают глаз с моно - на всякий случай... :)

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

Аппликухи писать на mono - извини это далеко от реальности. Писать серверные решения для вебсервисов, так попробуй найди хостинг с моно? Куда проще найти Win2k сервак с .NET фреймворком.

> извини это далеко от реальности

А почему нет? Я могу ошибаться, но на .NET программировать пробовал в свое время и именно аппликуху и писал, очень удобно и быстро получается.

Что за "негласный опрос менеджеров"? - сам только что придумал? А пытаться догнать .NET это и правда нерешаемая задача, пока этим не займётся сам MS

Задача MONO по своей невыполнимости напоминает мне WINE, но: 1) от wine есть польза :) 2) если прога в вине не работает, то пользователь особо не огорчится так как знает что там многое не работает, а программная среда/платформа - это серьёзная вещь и тут баги и недоработки недопустими

А вот интересно, кто их спонсирует?

Пока все, кто спонсирует open-source в итоге сами и страдают :) (IBM, SUN)

опыт показывает что гнаться не нужно. потому что все "мегатехнологии" от мс кончают на задворках ит-индустрии задыхаясь от багов. нет я верю в исключения из правил но не думаю что это тот случай =)

chl

>А вот интересно, кто их спонсирует?

это собственность Novell

>но у меня и в мыслях нет разбираться с глюками Mono, мне хватает оригинального .NET
Это потому, что ты видимо не думаегь о рынку, акциях твоей компании т.д.
Мой босс сказал, что как только mono выйдет мы свой продукт сразу-же начнем патчить на предмет того, чтобы он с моно работал

Вот это серьёзный разговор

2pvv: "Что за "негласный опрос менеджеров"? - сам только что придумал?"

Нет. Кстати, NonHuman только-что подтвердил мои слова. Но ты не верь, это ведь НЕ КОШЕРНО. Продолжай тормозить и тебя когда-нибудь "подвинут"
с работы так как найдётся чувак который может так же linux+mono :)

Всего хорошего.

Ууу... а как с WinAPI быть? Практика показывает, что написать мало-мальски серьезную десктопную программу на .NET невозможно без привлечения средств API. Как пример - контрол вида "дерево папок", и чтоб иконки юзал системные... или вот скажем owner drawn items в ListView или TreeView - опять же приходится переопределять WndProc, ловить сообщения, и заниматься другими совершенно не относящимися к делу вещами...

Re:

До сих пор? Какой ужас.

Полезная фича для FireFox

2 intl9h
А чего для ListView или TreeView GDI+ для собственной отрисовки не хватает?
Я менюху делал чтобы на саму Visual Studio было похоже.

Хотя раз пре пршлось сделать обращение к User32.DLL чтобы считать состояние NumLock/CapsLock. Но я не думаю, что тут будет сложно обойти проблему и на лету проверить, что я могу юзать (импорт из User32.dll или соответвсвующую фичу моно) и заюзать. Reflection в .NET хоть не дотягивает до Java, достаточно мошьный.

>Кстати сказать по негласному опросу менеджеров

Мда кррррруто негласный опрос менеджеров:) какого только бреда на ЛОР не вычитаешь. Не успели с .NET расхлебаться на те мона повилась, то есть скоро появится, может быть... А уж то что это будет работать и пользоваться хоть какой то популярность у "менеджеров" ой как сомневаюсь! Чем вас Java то не устраивает? Хорошая стабильная платформа, чё людЯм не хватает?

Mono проект Ximian, а Ximian с недавних пор проект Novell

>Ууу... а как с WinAPI быть? Практика показывает, что написать мало-мальски серьезную десктопную программу на .NET невозможно без привлечения средств API.

Гоните, Сударь. Отдаёт религиозным бредом типа "эта хня нам не нужна патамучта мы линукс". Мало-мальские серьёзные десктопные проги пачками щас пишут под .Net без использования WinAPI потому как всякие изъёбства с нестандартной отрисовкой на стандартных контролах в 90% случаец пустая трата времени. Отдельные глюки дот нета изучены и умело обходятся. Приведённый пример с "деревом папок" (что, кстати, имеется ввиду за контрол?) абсолютно не показателен, если имеет место быть сей факт вообще в .Net 1.1.

>Reflection в .NET хоть не дотягивает до Java, достаточно мошьный.

А пример можно, а то терзают смутные сомнения меня..

>Ууу... а как с WinAPI быть?
А у нас только server side и компоненты для разрботчиков :)

>но на .NET программировать пробовал в свое время и именно аппликуху и
>писал
У меня сейчас .NET идет одной из специализаций. Аппликухи писать удобно и просто, только вот добиться совместимости фреймворков у тебя и у клиента задача нетривиальная. И если у тебя нет какой-то конкретной библиотеки из конкретной версии фреймворка, то тебе не будет сказано что у тебя нет нужной версии фреймворка. Тебе скажут что нет этой библиотеки... кроме того легкие приложения писать на .NET сложно из-за большого размера самого runtime (а он на порядок больше того же JRE), хотя это и перестанет быть проблемой с выходом longhorn. Но сейчас ситуация именно такая. Аппликухи мы как писали на C++, так видимо и будем, а .NET идет как создавалка сайтов взамен ASP и создавалка прослоек между толстыми и тонкими клиентами (веб сервиса).

> А чего для ListView или TreeView GDI+ для собственной отрисовки не хватает?

А там просто нету поддержки owner-draw как класса. Т.е. хочешь что-нибудь нестандартное - пиши весь контрол с нуля, целиком. Или с API ковыряйся.

> Гоните, Сударь. Отдаёт религиозным бредом типа "эта хня нам не нужна патамучта мы линукс".

Да при чем тут линукс вообще?! =) Когда я сравниваю WinForms и Qt - я разумеется имею в виду виндовую версию Qt, софт-то я под винду пишу. Так что не будем переходить на религию =)

> Мало-мальские серьёзные десктопные проги пачками щас пишут под .Net

Еще раз подчеркиваю - речь шла не просто о .NET, а именно о WinForms

> без использования WinAPI потому как всякие изъёбства с нестандартной отрисовкой на стандартных контролах в 90% случаец пустая трата времени.

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

Более того, иногда системные иконки необходимы. Ну не умеют юзеры файлы по расширениям отличать! Им надо, чтоб у вордового файла была бы вордовая иконка, etc...

> Отдельные глюки дот нета изучены и умело обходятся.

Гы =) Так и вижу картину: поле, усеянное граблями, и по нему о-очень осторожно, медленно, настороженно поглядывая по сторонам, крадется .NET-кодер =)

> Приведённый пример с "деревом папок" (что, кстати, имеется ввиду за контрол?) абсолютно не показателен,

Контрола кстати такого в .NET нет (а почему??!), поэтому писать его приходится ручками. А почему он не показателен - я так и не понял.

А вот еще другой пример, думаю, более показательный. ListView, в одной колонке которого для каждого пункта списка должен рисоваться progress bar. И никакого API, пожалуйста. И без переписывания всего контрола с нуля. Сделаешь?

> если имеет место быть сей факт вообще в .Net 1.1.

Старья не держим. VB.NET 2003 / .Net 1.1, разумеется.

Да, касательно owner-draw - это будет в Whidbey. Вместе со множеством других (на мой взгляд - критичных!) фич типа нормальной layout-системы. Но пока - WinForms до Qt еще оччень далеко...

> .NET идет как создавалка сайтов взамен ASP и создавалка прослоек между толстыми и тонкими клиентами (веб сервиса).

Вот-вот =) Вот пускай там оно и живет. Как и Java. А десктопные - на чем-нибудь другом.

> WinForms и Qt - я разумеется имею в виду виндовую версию Qt, софт-то я
> под винду пишу. Так что не будем переходить на религию =)
Виндовый QT течет сильно. WinForms без .NET runtime вообще никуда не годится. Остается MFC... не к ночи будь упомянут.

> Гы =) Так и вижу картину: поле, усеянное граблями, и по нему о-очень
>осторожно, медленно, настороженно поглядывая по сторонам, крадется
>.NET-кодер =)
Гы.. а что... на правду похоже ;-). Может триллер кто-нить снимет или клипец хотя бы про это дело ;).

Я сильно сомневаюсь, что бабло достанется программистам на Моно :) Удачи :)

> Гы.. а что... на правду похоже

Еще б не похоже - на собственном опыте... =)

> Виндовый QT течет сильно.

У меня в трее под винду висит Psi, иногда сутками. Он сделан как раз на Qt3. Ничего никуда не течет =) Может, это трабла в более ранних версиях была, а ныне пофиксили?

Полезная фича для FireFox

Выстать через него private поле у чужого класса, так как это делает OJB. Это к возможностям Java.


А теперь проблема: Хочу класс который через единый интерфейс выполняет много разных действий. То есть
class Executor {
void RunAction(String)
}
Строка которая приходит ищется во внутренеей колекции и по ней вызывается метод или группа методов. Большинство из них есть только у потомков Executor и НЕ ДОЛЖНЫ вызыватся другим путем кроме как через RunAction

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

Я бы понял если бы оно не позволяло только protected методы потомков вызывать, но оно даже protected/private методы самого себя не вызывает.

2kka

ИМХО:

Это не .NET рефлекшн до Java не дотягивает - это мозг у тя до .NET не дотягивает ...

this.GetType().InvokeMember(methodName, BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.InvokeMethod, null, this, new object[] { arg1, arg2, arg3 } )

Обрати внимание на BindingFlags.NonPublic - кажется, это как раз то, что тебе нужно =)

2 kka

Если прога требует таких извратов в коде не пора ли подумать об оптимизаци объектной модели проекта?

Полезная фича для FireFox

> Обрати внимание на BindingFlags.NonPublic - кажется, это как раз то, что тебе нужно =)
Если это написанно в документации еще не значит это работает на Managed C++

Попробуй из строки сделать какой-нибуть enum на Managed С++ (на C# работает) через Enum.Parse

Полезная фича для FireFox

> Если прога требует таких извратов в коде не пора ли подумать об оптимизаци объектной модели проекта?

И так задача, нужно в конфиге указывать набор действий. Которые слебует выполнить. Каждое действие будем для простоты считать является вызовом метода. Все действия которые нужно подерживать в конифгах неизвестно и будет постоянно расширятся. Мы создаем потомки по мере надобности, которые умеют регистироватся в Executor, а он их потом выполняет на базе конифга + применяеет политику прав доступа.

Предложи болеее простой с точки зрения разработчика набора действий (потомка) вариант.

Ах, речь шла о C++... ну тут ничем не могу помочь - я под .NET кодю на C#/VB.NET.

А что с MC++ проблемы - так это не удивительно, все-таки поддержка .NET в нем пока явно сыровата, особенно в плане синтаксиса. Вот дождемся Whidbey и C++.NET, тогда посмотрим, как и что.

> Предложи болеее простой с точки зрения разработчика набора действий (потомка) вариант.

Одно действие - один класс-синглтон, реализующий интерфейс IConfigParameter, и один объект этого класса в ArrayList'е внутри Executor'а.

Полезная фича для FireFox

2 int19h
Именно про Managed C++ или как ты назвал C++.NET
В нем реально куча кривостей, которых нет в C#, хотя в C# прикол в Reflection не смотрел


IConfigParameter, чего найти не могу:
Ни так
http://search.microsoft.com/search/results.aspx?qu=IConfigParameter&View=...
ни так
http://www.google.com/search?q=IConfigParameter&sourceid=mozilla-search&a...

А Singleton и есть и колекция в Executore есть.
Только одно действие на класс не получается, нужно связанная группа + иногда одно действие есть композиция других из группы

> Именно про Managed C++ или как ты назвал C++.NET

Извиняюсь, под С++.NET я имел в виду C++/CLI - это _не_ Managed C++, это то, что нам обещают в Whidbey;

> IConfigParameter, чего найти не могу:

А его не надо искать, его надо объявить =)

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

Не совсем понял, о чем речь. Можешь показать "на пальцах" (лучше на примере)?

Полезная фича для FireFox

Если на пальцах, то одно действие это последовательность шагов (я писал "будем для простоты считать является вызовом метода" ), каждый шаг это вызов метода (причем в рамках каждого действия, мы имеем statefull)
То есть
action 1
step 1
step 2
step 3
action 2
step 1
step 4
step 5
и т.д.
ПО этому одно действие один класс не очень удобно.

Реализовывать обработку параметров из конфига в каждом классе не иммет смыла. У меня реализован шаблон Builder, т.к. процес конфигурирования одинаков.

Посмотрел что такое С++\CLI - если действительно сделают более совместимым с CLR будет хорошо. Но что-то слабо верится.

> ПО этому одно действие один класс не очень удобно.

Ну так и в чем проблема? "Действие" - класс, заведи метод DoStep(int), состояние действия храни внутри объекта для этого действия, глобальное состояние - в Executor.

> Посмотрел что такое С++\CLI - если действительно сделают более совместимым с CLR будет хорошо. Но что-то слабо верится.

А я на самом деле очень даже верю. На то есть причины - в силу перетаскивания всех на .NET в связи с лонгхорном, им надо было как-то подсластить пилюлю для C++-программистов, коих очень много пасется под Win-платформу. MC++ со своей ролью не шибко хорошо справился, вот и решили не отворачиваться от пользовательской (в смысле, программерской) базы и сделать полноценную интеграцию C++ в .NET, пусть даже ценой введения нестандартных ключевых слов в язык, но чтоб нормально работало и легко писалось.

Ну и еще, напомню, нам там шаблончики обещают - в свете этого дела шаблонные классы C++ должны прозрачно интегрироваться в .NET.

1int19h : "Hу и еще, напомню, нам там шаблончики обещают - в свете этого дела шаблонные классы C++ должны прозрачно интегрироваться в .NET."

Нефига не прозрачно, начинай копать отсюда http://msdn.microsoft.com/msdnmag/issues/04/05/C20/default.aspx

http://www.linux.org.ru/profile/eRazor/view-message.jsp?msgid=544735&noca...

В Develop тема с названием "4kka: .Net reflection vs Java reflection"

Anybody are wellcome!!!

>>> Обрати внимание на BindingFlags.NonPublic - кажется, это как раз то, что тебе нужно =) >Если это написанно в документации еще не значит это работает на Managed C++

Напомню исходное утверждение:

>>Reflection в .NET хоть не дотягивает до Java, достаточно мошьный.

Managed C++ != .Net спорить с этим не будем? На C# работает всё.

> Нефига не прозрачно, начинай копать отсюда

И где там про C++?