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

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

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

I>>>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.

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

I>Чушь. Эта дорожка была известна ще до джавы и по возможностям язык превзошел джаву на голову. нпример наличие одних только пропертей, индексеров и эвентов это чисто рай для инструментальщиков.

О да, пропертя, индексеры и евенты — это, конечно, супер-пупер возможности! Кстати, я не буду спорить, что они удобны, в жабе приходится воротить более синтаксически сложные конструкции, особенно в случае эвентов, но я не про то говорил.
Я имел ввиду, что в жабе гораздо раньше появились мощные средства рефакторинга, и именно благодаря простоте и отсутствию мозголомных конструкций, как в плюсах. МС при создании шарпа этот опыт учла, и не зря. Под плюсы рефакторинг убогий до сих пор.
То, что в синтаксическом плане шарп сейчас сильнее жабы(и это немного удручает: уж очень со скрипом в последнюю изменения вносятся), я не оспариваю, но мы сейчас не об этом говорим.

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

V>Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.
А каким образом происходит вызов out-of-proc методов?

Hint: там ещё посылается оконное сообщение.

V>Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.
V>Я прав?
Не совсем. D-BUS заточена под локальное использование, но в теории оно возможно.

Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.

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

I>>Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность
I>>Ну да ладно, я давно в курсе что ты очень скромный.
C>То есть? Что именно нужно показать?

А что мешало это разу сделать ? Вместо этого ты нагородил какой то бред с IDispatch

I>>

I>>IServerPtr ptr;
I>>ptr.CreateInstance(clsid);
I>>_bstr_t bstr = ptr->GetStuff(s);

I>>- при том появилоь это более 12 лет назад
C>А теперь попробуй передать в метод карту. Как будешь её представлять? В виде двумерного SAFEARRAY (для которого в ATL нет нормальных байндингов)? А что будем делать с асинхронными вызовами (AKA посылка сообщений)? Напомнить какой это геморрой в COM?

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

C>А как насчёт out-of-proc серверов, напомнить кретинизм с их активацией, маршаллингом, ROT и прочими радостями?

все это _было_

C>Нет, ещё и по удобсвту использования. Но тебе не понять, у тебя мозг вынул и выбросил сертефицированный представитель Microsoft.
C>В общем, твой тезис о том, что в Линуксе нет COM — банально неверен.

На виндовсе COM имеет отличную поддержку и на .Net и в Delphi том же, а в линуксе это yet another ipc.

Вот когда D-bus дорастет до стандарта, как это было с COM, тогда и поговорим.

C>А каким образом происходит вызов out-of-proc методов?
А in-proc?

C>Hint: там ещё посылается оконное сообщение.
Ну да.

V>>Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.
V>>Я прав?
C>Не совсем. D-BUS заточена под локальное использование, но в теории оно возможно.
Тибка тоже отлично работает локально.

C>Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.
И тибка делает то же самое.

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

I>>D-Bus это докомовский период
E>А тебе не кажется, что независимо от простейшего Hello DBUS и Hello COM, все эти вызовы прекрасно оборачиваются в одном методе, интерфейс которого можно подобрать так, что с ним будет достаточно удобно работать. И что вызо функции через COM, что через DBUS — в реальном коде все будет занимать одну простую строчку. Вернее скорее всего 2, одна — получение интерфейса, и вторая — вызов метода этого интерфейса. Или же планируется, что всем эти будут пользоваться индусы, которым платят за количество строчек кода?

COM в первую очередь это стандарт а не "yet another ipc"

Соответсвенно, как стандарт, имеет отличную поддержку в .Net

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

I>>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)
CC>>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

CC>Для шарпа мало. Для С++ — достаточно.
CC>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

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

I>>Чушь. Эта дорожка была известна ще до джавы и по возможностям язык превзошел джаву на голову. нпример наличие одних только пропертей, индексеров и эвентов это чисто рай для инструментальщиков.

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

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

E__>То, что в синтаксическом плане шарп сейчас сильнее жабы(и это немного удручает: уж очень со скрипом в последнюю изменения вносятся), я не оспариваю, но мы сейчас не об этом говорим.

Ну вот щас Оракл покажет, как надо

I>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

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

CC>>Для шарпа мало. Для С++ — достаточно.
CC>>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

I>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
на работе не самый свежий ассист стоит.
глянь на оффсайте, например тут:
http://wholetomato.com/products/default.asp
http://wholetomato.com/products/featureRefactoring.asp

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

I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

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

Например есть

someObj.Prop = something;

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

Что делает инструмент ? Правильно, предлагает создать сеттер, более того, он его и напишет за меня.

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

и вообще, всех действий нужно вдвое меньше, чем в джаве без пропертей

V>>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

I>За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов
Геттеры и сеттеры не нужны. Вообще. Приведи пример простого класса, для которого ты считаешь нужными property, и я покажу тебе, почему без них лучше.

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

C>>А каким образом происходит вызов out-of-proc методов?
V>А in-proc?
in-proc его обычно не используют (а смысл?). Хотя можно, он просто будет так же как и COM примерно работать.

C>>Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.
V>И тибка делает то же самое.
Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS

C>Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS
Это вряд ли. Тибка дорогая.
Я просто пытался показать, что технологии КОМ и ДБАС — разные, хотя и обеспечивают похожую функцуиональность.

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

C>>Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS
V>Это вряд ли. Тибка дорогая.
V>Я просто пытался показать, что технологии КОМ и ДБАС — разные, хотя и обеспечивают похожую функцуиональность.
Они разные, но в то же время похожие. Просто в COM упор идёт на in-proc, а маршаллинг out-of-proc вызовов и IDispatch добавлены как afterthought. В D-BUS ровно наоборот — он затачивался под out-of-proc работу и удобные динамические вызовы, а COM-подобные интерфейсы были добавлены уже как дополнительное средство для ускорения работы.

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

I>>За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов
V>Геттеры и сеттеры не нужны. Вообще.

Например, генерим какой класс по базе, это около 2-3 кликов мышом

получаетяс нечто вроде

class MegaItem
{
...

public string SomeField {get;set;}
public string SomeField2 {get;set;}
public string SomeField3 {get;set;}


...
}

далее, получаем инстанц и делаем следующее

MegaItem item = dbMgr.GetMegaItem(query);

и делаем следующее

_propertyGrid.DataSource = item;

где _propertyGrid это экземпляр пропертигрида

в итоге получаем вот ткое представление

название — Хуман ридабл строка для конкретной проперти (строка берется из Display Proxy) : значение (берётся из проперти)

А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF

V>Приведи пример простого класса, для которого ты считаешь нужными property, и я покажу тебе, почему без них лучше.

Например System.Drawing.Graphics

интересуют вот эти

Graphics.CompositingQuality
Graphics.SmoothingMode
Graphics.InterpolationMode
Graphics.TextRenderingHint

или System.Rectangle — там сразу ясно какие

I>Например, генерим какой класс по базе, это около 2-3 кликов мышом
Прости, ничего не понялю. Давай пример попроще, без базы данных. Ну знаешь, как любят в школе объяснять — объект фигура, его потомок — объект квадрат. Или как нибудь в похожем роде.

I>А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF
Что это такое?

I>или System.Rectangle — там сразу ясно какие
Я понятия не имею, что такое System.Rectangle. См. выше.

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

I>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
CC>на работе не самый свежий ассист стоит.
CC>глянь на оффсайте, например тут:
CC>http://wholetomato.com/products/featureRefactoring.asp

Короче говоря — ничего нет

Нужны высокоуровневые средтва, рефакторинг тот же.

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

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

B>>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

E>Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...
Зачем запрещать? Напишите свою библиотеку, лучше STL. Выложите на SourceForge, напишите по ней с десяток статей и радуйтесь. А на практике получается, что народ, не способный написать нормальный код с использованием STL, пишет свои библиотеки, по кривости и глючности превосходящие STL в разы...

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

F>>А я как раз, было дело, руками лепил COM-интерфейс на C++.
F>>И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

V>Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.
COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

class CSomething : ISomething
{
public:
  HRESULT __stdcall Method1();
  HRESULT __stdcall Method2();
};

ISomething *CreateSomething()
{
  return new CSomething;
}

Дюбители "потрахаться с компилятором", безусловно, могут написать на С:

struct CSomething
{
  struct ISomething intf;
};

HRESULT __stdcall CSomething_Method1(struct CSomething *pSomething);
HRESULT __stdcall CSomething_Method2(struct CSomething *pSomething);

struct ISomething *CreateSomething()
{
  struct CSomething *p = (struct CSomething *)malloc(sizeof(struct CSomething));
  p->intf.Method1 = &CSomething_Method1;
  p->intf.Method2 = &CSomething_Method2;
  return (struct ISomething *)p;
}

Результат тот же, а писанины в 2 раза больше. Зато можно почувствовать себя "крутым перцем, пишущим на низком уровне". Детский сад, короче.

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

I>>Например, генерим какой класс по базе, это около 2-3 кликов мышом
V>Прости, ничего не понялю. Давай пример попроще, без базы данных. Ну знаешь, как любят в школе объяснять — объект фигура, его потомок — объект квадрат. Или как нибудь в похожем роде.

Т.е. показать тебе именно пример где проперти не надо ?

I>>А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF
V>Что это такое?

Windows Presentation Framework

I>>или System.Rectangle — там сразу ясно какие
V>Я понятия не имею, что такое System.Rectangle. См. выше.

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