Почему D? - Философия программирования

Мысли (спорадические) по поводу D.

В настоящее время готовлю к выпуску
Harmonia GUI framework for D.
screenshot: http://www.terrainformatica.com/screenshots/harmonia.png
Demo: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
Собственно D здесь: http://www.digitalmars.com/d/

Т.е. определенный опыт приобрел. С чего бы начать? С классификации пожалуй.

Прежде всего, трудное это дело — отклассифицировать D. К какой он группе относится?
К C/C++ или все-таки к Java/C#?

По моему ощущению D мультипарадигмный язык. Т.е. на нем можно писать
как на C/C++ вплоть до использования C runtime (pointers,memmove,memcpy, printf, writef, scanf, etc. )
так и в стиле Java — с примитивами верхнего уровня.

D имеет встроенные примитивы которые в общем-то делают основные STL конструкции не
нужными. Например:
динамические массивы,

  char[] chars;
  chars ~= "Hello world"; // concatenation
  int sz = chars.length; // длина массива 
  
  char[] chars2 = chars[6..11]; // slicing
  assert( chars2 == "world" );

ассоциативные массивы,

 alias char[] string;
 int[string] map;
 map["one"] = 1;
 assert( "one" in map );

foreach — итерирование

  foreach(char c; chars2) 
    if( c == 'd' ) break;

В Harmonia, кстати, я обошелся только базовыми средствами языка.
Т.е. никаких generic collections/templates/classes мне не потребовалось.
Что есть хорошо.

Templates в D.
Templates по мощности такие же как в C++. Но синтаксис другой.
Например в D параметрический класс можно описать так:

class SymTable(T)
{
  T[] data;
  ...
}

И это уже будет template. Инстанциация template тоже по другому:

SymTable!(string) symtable = new SymTable!(string) (...);

Mixins: В D есть уникальная фича которая в C/C++ в прямом виде отсутствует — mixins.
Скажем у меня есть две функции в которых используется один и тот же фрагмент кода, тогда в D
делают так:

template(T) average 
{
  T val = x + y / 2;
}

int foo(int x, int y) 
{
  mixin average!(int); // "подмешивание" фрагмента
  return val;
}

double bar(double x, double y) 
{
  mixin average!(double); // "подмешивание" фрагмента
  return val;
}

Garbage collector.

Вот это одна из самых принципиальтных тем. Прежде всего D имеет операторы
new и delete. Т.е. здесь все нормально. Выделил память — освободи её
если знаешь что она никому больше не нужна — не увеличивай энтропию.

Но! D имеет еще и garbage collector (mark-n-sweep).
Если объект используется во многих местах то можно оставить его на откуп GC.
GC подберет объект когда он станет никому не нужен.

Т.е. GC не мешает писать эффективный код а наоборот помогает.
Т.е. все эти жутко smart_ptr<> и shared_ptr<> становятся не нужны.

Я например считаю что в UI GC — ощутимый бенефит. Большая система в которой много
компонентов ссылающихся сами на себя по кругу — очень частое явление.
GC помогает сильно. Код становится проще — доказуемее — суть надежнее.

Скорость
Родной DMD compiler бьет в моих тестах VC++ (не на много — 3-7%, но бьет).
Можно загрузить мою дему и подвигать например splitter. Скорость должна ощущаться.
Там в темпе вальса выполняется HTML remeasure (как правило нетривиальная задача).

Runtime.
В смысле .NET runtime или JRE.
Так вот его в D нет. D компилируется в нативный код.
Со всеми вытекающими.

Ну и собственно Почему D?
Или где его имеет смысл использовать?
Собственно везде где используется C++/Java/C# в настоящее время.
Особенно тем кто собирается делать a) GUI на С++ (MFC/WTL/OWL и т.д.)
или b) нечто типа Web Services я бы порекомендовал взглянуть на D.
Не пожалеете. GC и компактная нотация помогают здорово.

Теперь два слова про Harmonia.
Это portable "windowless" GUI framework со встроенными
HTML engine (вместо пресловутых XUL и XAML) и themes engine.
В качестве прототипа структуры был взят пакет Java/AWT —
имхо наиболее правильный иделогически GUI framework (исполнение — ..., но идея правильная).
Использование D и переосмысление некоторых базовых концепций
позволяет (so far) иметь нечто что работает быстро и на чем можно
писать без эстетического шока как от WTL.

Нижний слой Harmonia написан в С стиле — взаимодествие с платформой напрямую.
Верхний слой в стиле Java. Что есть имхо хорошо — чистый код.

Исходный текст демы ссылка на которую вверху:


import harmonia.ui.application;
import harmonia.ui.frame;
import harmonia.ui.widget;
import harmonia.ui.containers.splitter;
import harmonia.ui.containers.tabs;
import harmonia.html.view;
import harmonia.gx.graphics;
import harmonia.gx.images;


//|
//| static module ctor
//|
//| Harmonia way to setup GUI application
//| 

static this() 
{
  Application.onStart = 
    // Runtime started. Statics intitalized.
    // Voulez-vous dancer? 
    function void() // anonymous function, D-ism
    { 
      // create MainWindow here
      (new MyFrame()).state = Window.STATE.SHOWN;
    };

  Application.onStop = 
    // All windows closed so do graceful quit.
    function void() 
    { 
      // close files, etc.
    };
}


class MyFrame: Frame!(Splitter) // Splitter will be Frame's view
{
  Image     im;
  HtmlPanel hp;
  Tabs      tabs;

  this() 
  {
    // menu initialization
      menu ~=
        new Menu("File")
          ~ FileCommand.New
          ~ FileCommand.Open
              ~ Menu.Separator
          ~ FileCommand.Save
          ~ FileCommand.SaveAs
              ~ Menu.Separator
          ~ FileCommand.Send
          ~ FileCommand.Print
            ~ Menu.Separator
          ~ FileCommand.Exit;

      menu ~= 
        new Menu("Edit")
           ~ EditCommand.Undo
           ~ EditCommand.Redo
              ~ Menu.Separator
           ~ EditCommand.Cut
           ~ EditCommand.Copy
           ~ EditCommand.Paste
              ~ Menu.Separator
           ~ EditCommand.Find 
              ~ Menu.Separator
           ~ ( new Menu("SubEdit") ~ EditCommand.Cut ~ EditCommand.Copy ~ EditCommand.Paste );


      windowPlace = rect(point(100,100),Application.screenSize / 2);
            
    // listbox (left side)
      ListBox lb = new ListBox();
      this.view ~= lb;
      lb.place = rect(10,40,115,140);
      
    // fill it by items
      static string[] items =
      [
        "One",
        "Two",
        "Three",
        "Four",
        "Five",
        "Six Six Six Six Six Six Six Six",
        "Seven",
        "Eight",
      ];
      lb.addItems( items );


      tabs = new Tabs;
      this.view ~= tabs;

    // HTML panel  
      hp = new HtmlView();
      hp.name = "HTML Test";
      tabs ~= hp;

      hp.load( htmlTest ); // see below for htmlTest
      
      for(int i = 1; i < 10; ++i) // add nine dummy tabs for testing purposes.
      {
        HtmlPanel w = new HtmlPanel();
        w.name = toUTF16(format("Test #%d", i));
        tabs ~= w;
        w.load(format("<HTML back-color=edit border='1px solid dialog-shadow' padding=8px>Test #<B>%d</B></HTML>", i));
      }

      im = Image.create(logo);

  }

  override void drawContent(Graphics g)
  {
      super.drawContent(g);
      if(im !== null)
      {
        // draw the Bird - PNG with alpha
        auto Graphics ig = new Graphics(im);
        rect  src = rect(im.dimension);
        point dst = place.pointOf(1); // bottom left corner, see NUM keypad why 1
              dst.y -= im.dimension.y;
        g.copyRect(dst,src,ig);
      }
  }

}

static ubyte[] logo = [ /* real bytes skiped*/ ];

static char[] htmlTest = 
"<HTML back-color='edit dialog' padding=8px>
  <H1 padding=3px>H1:This is <I>HTML text</I> &nbsp;loaded into <B>HTMLView</B> - scrollable HTML container.</H1>
  <TABLE cellspacing=10px cellpadding=10px padding=10px border-width=1px border-style=solid border-color=dialog-shadow >
    <TR>
    <TD width=30% height=100%>Inline editbox: <INPUT type=text value='hello world' width=100px />
and button:<INPUT type=button value='button' width=60px />
and combobox:
<INPUT type=select width=60px>
        <OPTION>One</OPTION>
        <OPTION>Two</OPTION>
        <OPTION>Three</OPTION>
        <OPTION>Four</OPTION>
        <OPTION>Five</OPTION>
        <OPTION>Six Six Six Six Six Six Six Six</OPTION>
        <OPTION>Seven</OPTION>
        <OPTION>Eight</OPTION>
        <OPTION>Nine</OPTION>
        <OPTION>Ten</OPTION>
</INPUT>
</TD>
      <TD>two</TD>
      <TD width=40 back-color='dialog-light scrollbar' border='1px solid dialog-shadow'>1</TD>
    </TR>
    <TR>
      <TD border='1px solid dialog-shadow' text-align=right>right aligned cell with border</TD>
      <TD>four</TD>
      <TD back-color='dialog-light' border='1px solid dialog-shadow'>2</TD>
    </TR>
    <TR>
      <TD colspan=2 back-color='dialog-light dialog-shadow dialog-shadow dialog-light'>colspan=2, table cell with gradient backgrounds</TD>
      <TD border='1px solid dialog-shadow' back-color='dialog-light'>3</TD>
    </TR>
  </TABLE>
  <P>Inline image:<IMG src='test.png'/> and <CODE> code example; </CODE></P>
  <P><B>Unit tests:</B></P>
  <UL>
    <LI>Tooltips: Button 'button' shall show HTML formatted tooltip</LI>
    <LI>Tab Stops: TAB and SHIFT-TAB shall enumerate all input widgets.</LI>
    <P>Menu:</P>
    <UL>
        <LI>When edit box is in focus then Edit menu items shall be enabled.</LI>
        <LI>Tooltips shall appear if mouse will not move on menu item.</LI>
    </UL>
    <LI>Hyperlink: Mouse over it shall change cursor shape.</LI>
    <LI>Tab control: LEFT, RIGHT, HOME, END keys when in focus.</LI>
    <LI>PNG with alpha channel: Logo shall be drawn with transparency.</LI>
  </UL>
  <P height=100% padding=10pt border-width=3px border-style='solid none none none' border-color=dialog-shadow >
    This paragraph declared as <CODE>&lt;P height=100%&gt;</CODE>. This means that it will take 100% of height left from other elements.
    This is a major difference from standard HTML - percents here are <I>percents from free space</I>.
    <BR/>Notice 3 pixel bar at the left side - it is left border of the paragraph. Such percents are used instead of flex'es in XUL.</P>
  <P>Hyperlink test: <A href='http://terrainformatica.com'>Terra Informatica</A></P>
</HTML>";

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

CS> Х D — это круто и всё такое. Ъ

Как обстоят дела с рефлекшном и генерацией кода в рантайме? Как там с компонентами?

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

LCR>Как обстоят дела с рефлекшном и генерацией кода в рантайме? Как там с компонентами?

Как и в C++ — в чистом виде reflection нет.
Есть более толковый typeof/typeid который позволил кстати сделать
typesafe writef (прямой аналог printf).

Но! Есть JavaScript написанный на D (http://www.digitalmars.com/dscript/index.html)
который позволяет "рефлекшн и генерацию кода в рантайме" в тех местах
где это нужно.

Такой подход, имхо, правильный.

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

CS>Но! Есть JavaScript написанный на D (http://www.digitalmars.com/dscript/index.html)
CS>который позволяет "рефлекшн и генерацию кода в рантайме" в тех местах
CS>где это нужно.
CS>Такой подход, имхо, правильный.

Правильный в отношении чего? Я не совсем понимаю... Подход в шарпе и джаве — там классы генерятся на лету.

Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка D?

c-smile:

Прости, завалил совсем вопросами

Есть ли переменное число параметров в шаблонах?
Есть ли списки типов?
Есть ли делегаты?
Есть ли замыкания?

Есть ли способы взаимодействия с legacy кодом?

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

LCR>c-smile:

LCR>Прости, завалил совсем вопросами

LCR>Есть ли переменное число параметров в шаблонах?
Нет. Есть aliases но это другое — возможность
пареметризовать template именем переменной или функции.

LCR>Есть ли списки типов?
Что это?

LCR>Есть ли делегаты?
LCR>Есть ли замыкания?
Да, см.
http://www.digitalmars.com/d/function.html
"Delegates, Function Pointers, and Dynamic Closures"

LCR>Есть ли способы взаимодействия с legacy кодом?
Да. вот как описываются функции Win32 API

  alias uint ULONG;
  alias ULONG *PULONG;
  alias ushort USHORT;
  alias USHORT *PUSHORT;
  ....

extern (Windows) // __stdcall в VC
{
  HMODULE LoadLibraryA(LPCSTR lpLibFileName);
  FARPROC GetProcAddress(HMODULE hModule, LPCSTR lpProcName);
  DWORD GetVersion();
}

extern (C) //__cdecl calling convention
{
  void* memcpy(void*,void*,size_t);
}

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

LCR>Здравствуйте, c-smile, Вы писали:

CS>>Но! Есть JavaScript написанный на D (http://www.digitalmars.com/dscript/index.html)
CS>>который позволяет "рефлекшн и генерацию кода в рантайме" в тех местах
CS>>где это нужно.
CS>>Такой подход, имхо, правильный.

LCR>Правильный в отношении чего? Я не совсем понимаю... Подход в шарпе и джаве — там классы генерятся на лету.

В Java нет опции "генерация классов на лету". Для генерации .class файла (или массива байт) нужен компилятор.
В C# насколько я знаю тоже нет.

Я наверное не понял вопрос. Что exactly означает "классы генерятся на лету"?

LCR>Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка D?

Что такое "нормальный объект"? Это DOM построить? Все как обычно SAX parser -> DOM factory.
Или я чего не понял?

c-smile:

Вообще, было бы ещё лучше, если бы были множества типов (просто в Loki это реализовано как список типов).

При наличии множеств типов можно было бы в компайл-тайм определять, принадлежит ли тип множеству, добавлять и удалять тип из множеств. Для чего?
1. Генерация типов на основе типов из множества.
2. Контроль над инстанцированием шаблонов.

Хотя вот подумалось — это вполне можно реализовать, средства вроде есть в D.

Вот: макросы!? Препроцессор там есть? Насколько он туп или умён?

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

LCR>Вот: макросы!? Препроцессор там есть? Насколько он туп или умён?

Нет там препроцессора. И это хорошо.

Есть понятие version и debug

version (Windows)
{
    // Windows
}
version (linux)
{
    // ....
}
else
{
    static assert(0);        // Windows or Linux only
}

debug void dwritef(...) { .... DebugOutputString(..). . }
else  void dwritef(...) { }

А для всего остального — mixin работают.

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

LCR>Есть ли переменное число параметров в шаблонах?
Нет. Но в отличие от C++ есть возможность объявлять шаблоны с одинаковым именем и разным числом параметров.
LCR>Есть ли списки типов?
Нет, но вышеупомянутая возможность позволяет организовать их более удобным(imho) способом:

class NullT
{
}

class TypeList
{
    public:
    alias NullT H;
    alias NullT T;
    const int Length = 0;
}

class TL(T0) : TypeList
{
    public:
    alias T0 H;
    alias NullT T;
    const int Length = 1;
}

class TL(T0,T1) : TypeList
{
    public:
    alias T0 H;
    alias .TL!(T1) T;
    const int Length = 2;
}

// и так далее ...

Естественно работает ограничение на максимальную длину — сколько сгенеришь, столько и будет. Еще можно использовать трюк C++ с параметрами, имеющими значение по умолчанию. Или использовать более гибкую, но менее удобную, рекурсивную форму. Но при отсутствии макросов особого смысла в ней нет.

На самом деле конечно шаблоны D по техническим характеристикам не превосходят шаблоны C++. Определенно можно сказать, что они удобнее в некоторых случаях, но никак не мощнее. Самый большой недостаток — отсутствие неявной инстанциации. В качестве proof-of-concept я как-то давно реализовывал шаблоны для работы со списками типов на D. Если кому интересно — я их выложил здесь.

Вообще не стоит требовать слишком многого от языка, делаемого одним человеком, да еще и на чистом энтузиазме. Опять таки автор является профессионалом в области разработки компиляторов, а не гуру шаблонного метапрограммирования. Более того к последним он скорее всего относится с большим скептицизмом. Так что ожидать в D подобных фич не приходится. Если нужно что-такое, именно в этом языке — есть open-source front-end и даже gnu версия компилятора.Imho обе фичи, тобой упомянутые, достаточно легко внедрить в сам язык. Просто такая мысль автору этого языка даже в голову прийти не могла.

LCR>Есть ли делегаты?
Есть.
LCR>Есть ли замыкания?
Смотря что под этим подразумевать. Автор языка считает, что есть.

LCR>Есть ли способы взаимодействия с legacy кодом?
Есть. Например бинарная совместимость с C. Правда для линковки объектные файлы должны быть в формате OMF.

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

CS>Мысли (спорадические) по поводу D.

А как у D дело с компонетностью? По сравнению С++ какие нибудь подвижки есть?

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

LCR>>Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка D?

CS>Что такое "нормальный объект"? Это DOM построить? Все как обычно SAX parser -> DOM factory.
CS>Или я чего не понял?

Кусок нумбер 1.

    // obtain value of attribute "number"
    NamedNodeMap common_attrib = common_node.getAttributes();
    Node common_number = common_attrib.getNamedItem("number");
    if (common_number == null)
        continue; // ignore the node
    String s = common_number.getNodeValue();

Кусок нумбер 2.

    String s = xxx.Number; // ну или String s = xxx.getNumber();

В данном случае я этот xxx назвал "нормальным объектом". С ним работать легко и приятно. Класс создаётся на основе содержимого XSD, а объект — на основе содержимого конкретной XML. Это так называемый binding.

CS>Я наверное не понял вопрос. Что exactly означает "классы генерятся на лету"?
Хорошо, продолжим пример выше... Как такой binding можно реализовать на D? Вот у нас запущена программа. Прекрасно! К нам приходит по сети XSD. Мы можем вызвать генератор, он сгенерит файл с исходным кодом, затем мы можем вызвать компилятор — скомпилируется бинарный файл. Но теперь нужно создать объект этого класса — и вот тут мы приплыли. У нас нет инструментов для загрузки этого файла в программу, чтобы потом ему сделать newInstance. (То есть я как бы ждал аналога ClassLoader, теперь я понял что его не может быть принципиально).

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

CS>Т.е. определенный опыт приобрел. С чего бы начать? С классификации пожалуй.

CS>Прежде всего, трудное это дело — отклассифицировать D. К какой он группе относится?
CS>К C/C++ или все-таки к Java/C#?

CS>По моему ощущению D мультипарадигмный язык. Т.е. на нем можно писать
CS>как на C/C++ вплоть до использования C runtime (pointers,memmove,memcpy, printf, writef, scanf, etc. )
CS>так и в стиле Java — с примитивами верхнего уровня.

Так все-таки, чем же D лучше C# или Java? А чем он лучше C++?

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

psg>Здравствуйте, c-smile, Вы писали:

CS>>Т.е. определенный опыт приобрел. С чего бы начать? С классификации пожалуй.

CS>>Прежде всего, трудное это дело — отклассифицировать D. К какой он группе относится?
CS>>К C/C++ или все-таки к Java/C#?

CS>>По моему ощущению D мультипарадигмный язык. Т.е. на нем можно писать
CS>>как на C/C++ вплоть до использования C runtime (pointers,memmove,memcpy, printf, writef, scanf, etc. )
CS>>так и в стиле Java — с примитивами верхнего уровня.

psg>Так все-таки, чем же D лучше C# или Java? А чем он лучше C++?

К тому же есть тема, что язык, содержащий внутри себя "мультипарадигмность" будет (a) очень сложно компилировать и (b) очень медленно компилировать. Из (a) имеет массу "особенностей"

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

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

Ах уж сколько трудноуловимых и неочевидных моментов добавит эта "мультипарадигмность"... С++'сники посинеют от зависти

Перестаем оверквотить

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

psg>К тому же есть тема, что язык, содержащий внутри себя "мультипарадигмность" будет (a) очень сложно компилировать и (b) очень медленно компилировать. Из (a) имеет массу "особенностей"

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

Это точно не про D.

Это про C++...

На D 2-3 мегабайта кода вполне могут скомпилироваться за пару секунд. К сожалению сложные(например рекурсивные) шаблоны компилируются практически за то же время, что и в C++. Правда они пока используются не настолько часто.

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

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

psg>>К тому же есть тема, что язык, содержащий внутри себя "мультипарадигмность" будет (a) очень сложно компилировать и (b) очень медленно компилировать. Из (a) имеет массу "особенностей"

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

uw>Это точно не про D.

Это про C++...

uw>На D 2-3 мегабайта кода вполне могут скомпилироваться за пару секунд. К сожалению сложные(например рекурсивные) шаблоны компилируются практически за то же время, что и в C++. Правда они пока используются не настолько часто.

Ну вот, один минус мы уже нашли

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

CS>В C# насколько я знаю тоже нет.

Твои знания не соответствуют действительности, Reflection.Emit никто не отменял.

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

AVK>Здравствуйте, c-smile, Вы писали:

CS>>В C# насколько я знаю тоже нет.

AVK>Твои знания не соответствуют действительности, Reflection.Emit никто не отменял.

Про Reflection.Emit я знал. Но мне кажется вопрос был в том чтобы динамически
в runtime создать класс(?) и объект его и его исполнить.
Я так это понял.

В .NET с помощью Reflection.Emit и плясок с бубном можно создать сборку (PE файл)
и его динасически загрузить.

Это в принципе тоже самое что и в D или в C++ — можно сгенерировать исходный текст класса и динамически скомпилировать в DLL и уже её динамически закрузить.

В Java в этом смысле лучше — bytecodes можно склеить в памяти и подсунууть в ClassLoader

Но во всех случаях — сам по себе язык (ни C# ни Java ни D) к такого рода фичам оношения не имеет.
Это дело билиотек.

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

LCR>Здравствуйте, c-smile, Вы писали:

LCR>>>Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка D?

Я опять не понял. Если класс описан в D то написать
нечто типа:

MyClass m = new MyClass(someXMLstring);

можно в любом языке. в D само собой тоже.

CS>>Что такое "нормальный объект"? Это DOM построить? Все как обычно SAX parser -> DOM factory.
CS>>Или я чего не понял?

LCR>Кусок нумбер 1.
LCR>

LCR>    // obtain value of attribute "number"
LCR>    NamedNodeMap common_attrib = common_node.getAttributes();
LCR>    Node common_number = common_attrib.getNamedItem("number");
LCR>    if (common_number == null)
LCR>        continue; // ignore the node
LCR>    String s = common_number.getNodeValue();
LCR>

LCR>Кусок нумбер 2.
LCR>

LCR>    String s = xxx.Number; // ну или String s = xxx.getNumber();
LCR>

Вот то же самое но на D.

  Node[string] common_attrib = common_node.attributes;
  if( ! ("number" in common_attrib) )
    continue;
  Node common_number = common_attrib["number"];
  string s = common_number.value;

LCR>В данном случае я этот xxx назвал "нормальным объектом". С ним работать легко и приятно. Класс создаётся на основе содержимого XSD, а объект — на основе содержимого конкретной XML. Это так называемый binding.

Это не binding. Это классический XML persisting.

CS>>Я наверное не понял вопрос. Что exactly означает "классы генерятся на лету"?
LCR>Хорошо, продолжим пример выше... Как такой binding можно реализовать на D? Вот у нас запущена программа. Прекрасно! К нам приходит по сети XSD. Мы можем вызвать генератор, он сгенерит файл с исходным кодом, затем мы можем вызвать компилятор — скомпилируется бинарный файл. Но теперь нужно создать объект этого класса — и вот тут мы приплыли. У нас нет инструментов для загрузки этого файла в программу, чтобы потом ему сделать newInstance. (То есть я как бы ждал аналога ClassLoader, теперь я понял что его не может быть принципиально).

то же самое ты можешь сделать и в D. Сгенерировать DLL на лету и сделать LoadLibrary. Но для этого на клиенте должен быть комилятор D.

Лично бы я не свзывался с XML в этом случае. Если нужно получать
с сервера динамический контент то я бы перешел на JavaScript.
Т.е. вместо XML приходил бы с сервера JavaScript который бы загружался
и исполнялся на клиенте. Самое имхо естесвенное решение, нет?

С легкой руки c-smile'а изучаю сабж 3ий день.
Мне кажется, многим будут небезынтересны вот эти штуки:
соотношение фич C и D
соотношение фич C++ и D
соотношение фич препроцессора C и D
Overview языка содержит must read разделы "Features To Keep From C/C++" и "Features To Drop".
Мне хватило этого, чтобы бросить на язык первый сознательный взгляд

Счастливого плаванья!

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

psg>>>К тому же есть тема, что язык, содержащий внутри себя "мультипарадигмность" будет (a) очень сложно компилировать и (b) очень медленно компилировать. Из (a) имеет массу "особенностей"

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

uw>>Это точно не про D.

Это про C++...

uw>>На D 2-3 мегабайта кода вполне могут скомпилироваться за пару секунд. К сожалению сложные(например рекурсивные) шаблоны компилируются практически за то же время, что и в C++. Правда они пока используются не настолько часто.

psg>Ну вот, один минус мы уже нашли

Какой?

Дело в том что templates в D нужны меньше чем в C++.
Как я уже сказал язык сам по себе включает многие базовые
конструкции.

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

AVK>>Твои знания не соответствуют действительности, Reflection.Emit никто не отменял.

CS>Про Reflection.Emit я знал. Но мне кажется вопрос был в том чтобы динамически
CS>в runtime создать класс(?) и объект его и его исполнить.
CS>Я так это понял.

Ну и? Если ты помнишь про Reflection.Emit, то в чем проблема?

CS>В .NET с помощью Reflection.Emit и плясок с бубном можно создать сборку (PE файл)
CS>и его динасически загрузить.
CS>Это в принципе тоже самое что и в D или в C++ — можно сгенерировать исходный текст класса и динамически скомпилировать в DLL и уже её динамически закрузить.

Вобщем не буду углублятся в дотнетовские потроха и просто скажу что твои представления весьма поверхностны.

CS>Это дело билиотек.

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

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

Андрей, ты можешь предложить способ используя Reflection.Emit
решить задачу:
"Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка C#(было D)?" (С) LCR

Отрешимся на секунду от того что задача некоректно поставлена, т.е.
не известно сам класс он как? тоже генерится динамически?
If класс не генерится динамически то примитивная factory вкупе с SAX parser
решает проблему га любой платформе then exit(0).

else....

Наиболее близкий пример как бы это можно сделать на .NET здесь.

Но у меня почему-то складывается ощущение что это все-таки
"умерщвление пернатыхъ посредствомъ стрельбы главнымъ калибромъ дредноута Императрица Мария".

Как-то это все коряво и неправильно концептуально.
Т.е. я могу конечно извратиться и руками склеить кусок кода из асемблерных
инструкций. Что с msil что без него — напрямую в машинные коды.

Но это грязный хак. Если это рекомендованный путь решать проблемы в .NET — я пас.

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

GIV>Здравствуйте, c-smile, Вы писали:

CS>>Мысли (спорадические) по поводу D.

GIV>А как у D дело с компонетностью? По сравнению С++ какие нибудь подвижки есть?

Сильных подвижек нет.

Но есть встроенная поддержка COM:

COM Interfaces
A variant on interfaces is the COM interface. A COM interface is designed to map directly onto a Windows COM object. Any COM object can be represented by a COM interface, and any D object with a COM interface can be used by external COM clients.

http://www.digitalmars.com/d/class.html#interface

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

CS>Андрей, ты можешь предложить способ используя Reflection.Emit
CS>решить задачу:
CS>"Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка C#(было D)?" (С) LCR

Да, если речь об некоем аналоге XmlSerializer (я так понял). Правда сам XmlSerializer таки работает через компилятор, но ничто не мешает сделать то же самое на основе Reflection.Emit. Да, тут есть еще одно тонкое отличие рантайма дотнета от JRE — в состав первого входят компиляторы C#, VB.NET, JScript.NET.

CS>Отрешимся на секунду от того что задача некоректно поставлена, т.е.
CS>не известно сам класс он как? тоже генерится динамически?

В моем понимании да.

CS>Наиболее близкий пример как бы это можно сделать на .NET здесь.

Это совсем не то. Посмотри лучше http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemXmlSerializationXmlSerializerClassTopic.asp.

CS>Как-то это все коряво и неправильно концептуально.
CS>Т.е. я могу конечно извратиться и руками склеить кусок кода из асемблерных
CS>инструкций. Что с msil что без него — напрямую в машинные коды.
CS>Но это грязный хак.

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

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

GIV>>А как у D дело с компонетностью? По сравнению С++ какие нибудь подвижки есть?

CS>Сильных подвижек нет.

Крайне печально. На сегодня это приговор ИМХО.

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

CS>Отрешимся на секунду от того что задача некоректно поставлена, т.е.
CS>не известно сам класс он как? тоже генерится динамически?

Аргх! Нормально задача поставлена

(Ладно, следую баскетбольному принципу "виноват дающий" и раскладываю всё по полочкам).

Процесс следующий:
1. Виртуальная машина работает.
2. По сети приходит файл.
3. Файл парсится, там URI на схему. Схема запрашивается.
4. По сети приходит схема.
5. По этой схеме генерится класс (именно тип, это и означает генерация кода на лету).
6. Этот класс инстанцируется и заполняется данными из файла.

Это и есть Data Binding. Именно binding, а не сериализация объектов в XML — принципиальная разница в том, что тип генерируется на основе данных. Прочувствуй различие, пожалуйста.

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

AVK>Да, если речь об некоем аналоге XmlSerializer (я так понял). Правда сам XmlSerializer таки работает через компилятор, но ничто не мешает сделать то же самое на основе Reflection.Emit. Да, тут есть еще одно тонкое отличие рантайма дотнета от JRE — в состав первого входят компиляторы C#, VB.NET, JScript.NET.

Подчёркивается наличие компилятора аж для трёх языков, или наличие компилятора вообще?

Хотя здесь мне даже самому непонятно что помешало сановцам добавить в JRE компилятор (или убрать из Java2 RE), тем не менее эту проблемку давно научились решать: 1. JDK такой же свободно скачиваемый; 2. tools.jar размером = 5Mb.

У меня такое ощущение, что компилятор убрали из-за запарок с лицензиями.

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

LCR>Процесс следующий:
LCR>1. Виртуальная машина работает.
LCR>2. По сети приходит файл.
LCR>3. Файл парсится, там URI на схему. Схема запрашивается.
LCR>4. По сети приходит схема.
LCR>5. По этой схеме генерится класс (именно тип, это и означает генерация кода на лету).
LCR>6. Этот класс инстанцируется и заполняется данными из файла.

LCR>Это и есть Data Binding. Именно binding, а не сериализация объектов в XML — принципиальная разница в том, что тип генерируется на основе данных. Прочувствуй различие, пожалуйста.

Вот теперь более-менее понятно.
Только при чем здесь binding?

binding это когда у тебя есть instance какого-то известного
клиенту класса и ты хочешь связать его поля (динамически) с каким-то источником
данных.

То про что ты говоришь это serialization или marshalling — передача
объектов (instances of some classes) между компонентами системы посредством
каналов связи.
instance-on-server -> serialization -> transfer -> deserialization -> instance-on-client.

Единственная проблема — и клиент и сервер обязаны знать про классы.

Т.е. клиент обязан знать про typelib сервера иначе эти instances
клиенту не нужны — например он не знает какие методы он может позвать у таких объектов (if any).

В D как и в C++ можно воспользоваться разными методами для передачи таких данных:
например использовать struct как application bynary interface + XML emitter + XML parser.
Можно воспользоваться механизмом COM marshalling и всем что с этим связано.

Еще раз: если нужно совсем нечто аморфное то можно использовать JavaScript
или LUA или что другое по желанию.

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

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

psg>>>>К тому же есть тема, что язык, содержащий внутри себя "мультипарадигмность" будет (a) очень сложно компилировать и (b) очень медленно компилировать. Из (a) имеет массу "особенностей"

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

uw>>>Это точно не про D.

Это про C++...

uw>>>На D 2-3 мегабайта кода вполне могут скомпилироваться за пару секунд. К сожалению сложные(например рекурсивные) шаблоны компилируются практически за то же время, что и в C++. Правда они пока используются не настолько часто.

psg>>Ну вот, один минус мы уже нашли

CS>Какой?

CS>Дело в том что templates в D нужны меньше чем в C++.
CS>Как я уже сказал язык сам по себе включает многие базовые
CS>конструкции.

Точно такой же "массив" можно сделать с помощью ArrayList, LinkedList и т.п. Включение таких конструкций в язык кроме усложнения синтаксиса IMHO ничего не даст.

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

Помучил я немного D

c-smile.

В общем-то понятно, почему мы друг друга не понимаем — мы пришли из разных "миров", поэтому терминология для одних и тех же вещей у нас различная. Я просто привык к тому, что, например, Castor (http://www.castor.org/) это

An open source data binding framework for Java[tm]. It's basically the shortest path between Java objects, XML documents, SQL tables and LDAP directories. Castor provides Java to XML binding, Java to SQL/LDAP persistence, and then some more.

То есть он в частности

Generates Java classes from XML Schemas.

Но как ты понимаешь, выбор терминологии — вопрос шестнадцатый. Хоть горшком назови, только в печку не суй

CS>Еще раз: если нужно совсем нечто аморфное то можно использовать JavaScript
CS>или LUA или что другое по желанию.

Да, кристально ясно. Спасибо.

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

LCR>Подчёркивается наличие компилятора аж для трёх языков, или наличие компилятора вообще?

Наличие компилятора вобще.

LCR>Хотя здесь мне даже самому непонятно что помешало сановцам добавить в JRE компилятор

Размер рантайма скорее всего.

LCR>У меня такое ощущение, что компилятор убрали из-за запарок с лицензиями.

Вряд ли.

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

AVK>Здравствуйте, c-smile, Вы писали:

CS>>Андрей, ты можешь предложить способ используя Reflection.Emit
CS>>решить задачу:
CS>>"Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка C#(было D)?" (С) LCR

AVK>Да, если речь об некоем аналоге XmlSerializer (я так понял). Правда сам XmlSerializer таки работает через компилятор, но ничто не мешает сделать то же самое на основе Reflection.Emit. Да, тут есть еще одно тонкое отличие рантайма дотнета от JRE — в состав первого входят компиляторы C#, VB.NET, JScript.NET.

CS>>Отрешимся на секунду от того что задача некоректно поставлена, т.е.
CS>>не известно сам класс он как? тоже генерится динамически?

AVK>В моем понимании да.

Так я не понял это serialization или что? И зачем там компайлер?

AVK>Это совсем не то. Посмотри лучше http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemXmlSerializationXmlSerializerClassTopic.asp.

Спасибо.

CS>>Как-то это все коряво и неправильно концептуально.
CS>>Т.е. я могу конечно извратиться и руками склеить кусок кода из асемблерных
CS>>инструкций. Что с msil что без него — напрямую в машинные коды.
CS>>Но это грязный хак.

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

Наверное от незнания. Хотя Java VM я был написал руками как ты наверное знаешь.
MSIL судя по спецификации где-то рядом. С моей колокольни что x86 asm,
что MSIL что Java bytecodes *принципиально* не отличаются.

"но в ряде случаев это очень мощное средство оптимизации"

Тогда встроенный в D asm (http://www.digitalmars.com/d/iasm.html)
еще более мощное средство оптимизации. ы?

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

CS>Тогда встроенный в D asm (http://www.digitalmars.com/d/iasm.html)
CS>еще более мощное средство оптимизации. ы?

Нет. Не та продуктивность.

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

LCR>c-smile.

LCR>В общем-то понятно, почему мы друг друга не понимаем — мы пришли из разных "миров", поэтому терминология для одних и тех же вещей у нас различная. Я просто привык к тому, что, например, Castor (http://www.castor.org/) это
LCR>

LCR>An open source data binding framework for Java[tm]. It's basically the shortest path between Java objects, XML documents, SQL tables and LDAP directories. Castor provides Java to XML binding, Java to SQL/LDAP persistence, and then some more.

LCR>То есть он в частности
LCR>

LCR>Generates Java classes from XML Schemas.

LCR>Но как ты понимаешь, выбор терминологии — вопрос шестнадцатый. Хоть горшком назови, только в печку не суй

Как я понимаю базовый use case это
"Generate source code from an XML Schema"
Чтобы его скомпилировать (класс) и включить в свой проект. Т.е. не динамически, а статически.
Я бы не назвал это binding, это скорее какой-то class builder.

Вполне возможная конструкция как для D так и для C/C++ и вообще всего чего шевелится.

Динамически же (в runtime) создавать классы ( .class files ) имхо бессмысленно.
Или я ошибаюсь? Если да то можно ли use case?

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

CS>>Тогда встроенный в D asm (http://www.digitalmars.com/d/iasm.html)
CS>>еще более мощное средство оптимизации. ы?

AVK>Нет. Не та продуктивность.

Кого/чего? Кода или программера?

Если программера то имхо что msil, что D asm все едино.

Ты сходи по ссылке — asm достаточно высокоуровневый в D.

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

AVK>Крайне печально. На сегодня это приговор ИМХО.

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

CS>Если программера то имхо что msil, что D asm все едино.

CS>Ты сходи по ссылке — asm достаточно высокоуровневый в D.

Глядел я D, еще полгода назад. До MSIL он не дотягивает. Да и не в этом дело. Дело в другом — этот MSIL можно тут же и выполнять.
Да и вобще — исходный мой пост был не о применимости эмита, а о том что твой тезис о том что в дотнете нет средств создания кода на лету не соответствует действительности.

... << RSDN@Home 1.1.4 beta 6a rev. 441>>

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

psg>Помучил я немного D

— и так и не понял, зачем нужно было пихать в одну кучу низкоуровневые и высокоуровневые features?... Все эти конструкции IMHO выглядят как-то незаконченно и "грязновато". Это — личное впечатление.

Я ж и говорю, трудно его отклассифицировать.
D это "С++ без оператора ->" и "Java указателями и union".

Я для себя его классифицирую как Java, JNI и С/C++ в одном флаконе.
Просто удобно.

Но D не для всех, согласен.

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

CS>>Если программера то имхо что msil, что D asm все едино.
CS>>Ты сходи по ссылке — asm достаточно высокоуровневый в D.

AVK>Глядел я D, еще полгода назад. До MSIL он не дотягивает.

MSIL не дотягивает до чего? До asm x86?

AVK>Да и не в этом дело. Дело в другом — этот MSIL можно тут же и выполнять.

Ну и? А машинные инструкции нельзя тут же исполнять?

AVK>Да и вобще — исходный мой пост был не о применимости эмита, а о том что твой тезис о том что в дотнете нет средств создания кода на лету не соответствует действительности.

Это я понял. Спасибо.
Только вопрос был насколько я понял типа:

Есть ли *в языке* конструкция типа eval("source code").
Ответ — нет. Ни в C# ни в D, ни в Java, ни в С/С++. Как в любом другом компилируемом языке.

В JavaScript (JS.NET и JS.D) — да есть. Как наверное и в любом другом *интерпретируемом* языке/системе.

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

AVK>>Глядел я D, еще полгода назад. До MSIL он не дотягивает.

CS>MSIL не дотягивает до чего? До asm x86?

asm D до MSIL

AVK>>Да и не в этом дело. Дело в другом — этот MSIL можно тут же и выполнять.

CS>Ну и? А машинные инструкции нельзя тут же исполнять?

Можно. Но программирование на MSIL на порядок проще.

... << RSDN@Home 1.1.4 beta 6a rev. 443>>

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

С другой стороны, генерация классов как самоцель никому не нужна. Класс — это прежде всего декларация, смысл которой помочь разработчику в compile time.

PS. По поводу D вообще и его универсальности. Один из моих самых первых учителей (мудрый старик) любил поговаривать — "Возможности программ не могут превышать на порядок возможностей средств, на которых они разработаны". Применительно к D, отсутствие run-time фрэймворка может оказаться его фатальным недостатком. Сотню мегобайт работающего и отлаженного кода в .NET Framework ещё никто не отменял. А кроме своей ещё чуть-чуть большей гибкости, как я понял, D ничем существенным от C-семейства языков не отличается. Вот если бы в нём было хотя бы что-то от АОП...

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

c-smile,

CS>Как я понимаю базовый use case это
CS>"Generate source code from an XML Schema"
CS>Чтобы его скомпилировать (класс) и включить в свой проект. Т.е. не динамически, а статически.

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

CS>Я бы не назвал это binding, это скорее какой-то class builder.

Это неважно вообще как ты это назовёшь.

CS>Вполне возможная конструкция как для D так и для C/C++ и вообще всего чего шевелится.

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

CS>Динамически же (в runtime) создавать классы ( .class files ) имхо бессмысленно.
CS>Или я ошибаюсь? Если да то можно ли use case?

Это существенно для asp.net, JSP, JSF. Текущий мой проект содержит генерацию иерархий классов из спецификации в XML как необходимый ингредиент. Эти спецификации могут меняться, размножаться и т.п., перекомпиляция и перезапуск недопустимы.

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

IT>Здравствуйте, c-smile, Вы писали:

CS>>Андрей, ты можешь предложить способ используя Reflection.Emit
CS>>решить задачу:
CS>>"Вот приходит большая XML-на из сетки, мы её можем без интеллектуальной работы руками превратить в нормальный объект класса языка C#(было D)?" (С) LCR

IT>Этим remoting с сотоварищами справляются без всяких имитов. Сериализация, тыксызыть

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

"классы уже определены и сгенерированы" в этом
и есть весь key point.

Я вообще не понимаю фишку с этим автоматическим XML генерированием.
XML вообще-то это lingua franca для т.н. слабосвязанных систем.
Т.е. как правило "тупая" десерлизация приходящих данных не работает.
Если строго известно что система A посылает всегда
данные класса C ситеме B то зачем тогда XML вообще?

В принципе сгенерировать классы (или описания структур) некоего DOM по XML Schema
задача линейная что для Java, .NET, C или того же D.
Обратная задача — генерация XML schema по code DOM тоже в общем-то
линейна. Для D можно воспользоваться например
DMD Front End Starter Kit
если кому-то сильно требуется. Т.е. типов данных настолько много что невмоготу.

IT>С другой стороны, генерация классов как самоцель никому не нужна. Класс — это прежде всего декларация, смысл которой помочь разработчику в compile time.

Вот. И я о том.

IT>PS. По поводу D вообще и его универсальности. Один из моих самых первых учителей (мудрый старик) любил поговаривать — "Возможности программ не могут превышать на порядок возможностей средств, на которых они разработаны". Применительно к D, отсутствие run-time фрэймворка может оказаться его фатальным недостатком. Сотню мегобайт работающего и отлаженного кода в .NET Framework ещё никто не отменял. А кроме своей ещё чуть-чуть большей гибкости, как я понял, D ничем существенным от C-семейства языков не отличается. Вот если бы в нём было хотя бы что-то от АОП...

Хм... по мне (и не только по мне) наличие этого самого framework это просто один большой минус.

Если я пишу программу для некоего оффиса в одном здании то да — я могу
позволить себе роскошь использовать framework. Да и то...
Если я скажем пишу программу для основных GUI платформ то зачем мне "кузнец"?
Инвестиции в то что работает на отдельно взятой платформе и при хорошем раскладе меня не устраивают собственно как и ни одного нормального производителя ПО.

Честно говоря я не собирался, не собираюсь и не хочу противопоставлять .NET и D.

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

Чего нынче модно ждать? XAML, да? ну подождем...

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

IT>>Этим remoting с сотоварищами справляются без всяких имитов. Сериализация, тыксызыть

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

CS>"классы уже определены и сгенерированы" в этом и есть весь key point.

А другое на сегодняшний день пока неопределено даже в теории. За исключением конечно случаев "доопределения и догенерирования" по заранее предопределённым правилам.

CS>Я вообще не понимаю фишку с этим автоматическим XML генерированием.

Какую фишку? XML как универсальный формат описания и хранения (в разумных пределах) чего-либо вполне хорош. Другого от него требовать не имеет смысла. Генерация на основе XML в design time очень даже удобная вещь. WSDL, XSD-схемы живое тому подтверждение.

CS>XML вообще-то это lingua franca для т.н. слабосвязанных систем.

XML — это универсальный формат хранения данных. Такой же как кома-разделители, фиксированные знакоместа и INI-файлы. Ожидать от него чего-то большего сегодня уже не модно. Но и принижать его значение тоже не стоит.

CS>Т.е. как правило "тупая" десерлизация приходящих данных не работает.
CS>Если строго известно что система A посылает всегда данные класса C ситеме B то зачем тогда XML вообще?

Например, использование HTTP протокола может быть одним из non functional requirements.

CS>Хм... по мне (и не только по мне) наличие этого самого framework это просто один большой минус.

По мне и не только по мне (а по мнению тех миллионов, которые не используют D) это его фатальный недостаток.

CS>Если я пишу программу для некоего оффиса в одном здании то да — я могу позволить себе роскошь использовать framework. Да и то...

Странное дело... Разве большинство из нас не занимается именно этим?

Ну хорошо... для двух зданий, ну может для десяти...

CS>Если я скажем пишу программу для основных GUI платформ то зачем мне "кузнец"?

Если речь идёт о ширпотребе, то я вполне с тобой согласен.

CS>Инвестиции в то что работает на отдельно взятой платформе и при хорошем раскладе меня не устраивают собственно как и ни одного нормального производителя ПО.

Это специфика твоей работы. Я бы даже сказал сегодняшняя специфика заказчика, на которого нацелен твой бизнес. Но это вовсе не означает что это специфика всей индустрии. Для примера скажу, что бюджет IT департмента Morgan Stanley составляет 5 миллиардов долларов в год. Не думаю, что весь экспорт софта в России даже близко приближается к этой цифре. Тем не менее, ребята там не пишут софт на "все платформы". Это просто не нужно.

CS>Честно говоря я не собирался, не собираюсь и не хочу противопоставлять .NET и D.

Раз уж зашла речь о D, как о полноценной современной среде для разработки софта, то этого не избежать. Более того, современное средство разработки должно соответствовать современным требованиям. Отсутствие фреймворка очень серьёзный недостаток сегодня. Очень.

CS>Для себя лично я не считаю возможным инвестировать в нечто работающее на одной платформе и при хорошем раскладе карт. Во всяком случае не GUI разработку.

Для GUI ещё долго не будет ничего работающего на всех платформах. Java уже обломалась, а в .NET это и не планируется. Специфика не та. Это вам не поля из базы данных на объекты мапить. Тут надо пиксель к пикселю, полутень к полутени. Раперы вещь конечно хорошая, но пока они перед гуями пасуют. Думаю, без помощи железячников нам тут не обойтись.

CS>Уже четыре года я слышу, вот сейчас, сейчас что-то дяди сделают и будет всем шастя великое.
CS>Чего нынче модно ждать? XAML, да? ну подождем...

Дяди берут то что есть и делают. Если нужен универсальный гуй для любой платформы, то на сегодняшний день он только один — HTML.

ЗЫ. Что касается твоего поста в целом, то он мне вполне симпатичен

Самое время задвинуть традиционную фразу RSDN тимера — а статейку про D для журнала не напишешь?

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

CS>>Т.е. как правило "тупая" десерлизация приходящих данных не работает.
CS>>Если строго известно что система A посылает всегда данные класса C ситеме B то зачем тогда XML вообще?

IT>Например, использование HTTP протокола может быть одним из non functional requirements.

Я не понял про http....

В http запросе есть поле Accept: mime type; xml — один из тысяч известных
типов. Другой известный тип кстати application/octet-stream.

CS>>Хм... по мне (и не только по мне) наличие этого самого framework это просто один большой минус.

IT>По мне и не только по мне (а по мнению тех миллионов, которые не используют D) это его фатальный недостаток.

Другие миллионы также не используют .NEt и что?

Давай разберемся что есть framework.
В терминах D (и С/C++) это набор библиотек — templates/classes/whatever.
Например для D известно что-то около 5 GUI имплементаций (шестая Harmonia).
Для .NET — одна и та толком даже родную платформу не держит.
Что лучше?

Или уже считается что отсутствие выбора это тот бенефит который заставит эти самые миллионы
использовать только .NET?

Не понимаю я твоего довода.

CS>>Если я пишу программу для некоего оффиса в одном здании то да — я могу позволить себе роскошь использовать framework. Да и то...

IT>Странное дело... Разве большинство из нас не занимается именно этим?

Ну хорошо... для двух зданий, ну может для десяти...

Для десяти зданий уже не работает. Затраты на IT department и требования поддержки
framework up to date на всех машинах это уже нетривиальная задача.

CS>>Если я скажем пишу программу для основных GUI платформ то зачем мне "кузнец"?

IT>Если речь идёт о ширпотребе, то я вполне с тобой согласен.

Речь идет о разработке программных систем вообще а не только для корпоративных
приложений с клиентами на Wintel платформе.

CS>>Инвестиции в то что работает на отдельно взятой платформе и при хорошем раскладе меня не устраивают собственно как и ни одного нормального производителя ПО.

IT>Это специфика твоей работы. Я бы даже сказал сегодняшняя специфика заказчика, на которого нацелен твой бизнес. Но это вовсе не означает что это специфика всей индустрии. Для примера скажу, что бюджет IT департмента Morgan Stanley составляет 5 миллиардов долларов в год. Не думаю, что весь экспорт софта в России даже близко приближается к этой цифре. Тем не менее, ребята там не пишут софт на "все платформы". Это просто не нужно.

Morgan Stanley... и чего?

Вот выдержка из последнего Morgan Stanley CEO survey:

IT Vendor Spending Intentions Over the Next Twelve Months

1 Cisco            81% 162
2 Symantec         71% 120
3 IBM              71% 153
4 Red Hat          70% 118
5 Mercury          66% 100
6 Microsoft        66% 195
7 Juniper Networks 64% 92

здесь

Цифры мне не говорят о том что миллионы начали программировать .NET framework.
Crossplatform solutions — да, говорят.
Ниша для D в том числе? да, несомненно.

CS>>Честно говоря я не собирался, не собираюсь и не хочу противопоставлять .NET и D.

IT>Раз уж зашла речь о D, как о полноценной современной среде для разработки софта, то этого не избежать. Более того, современное средство разработки должно соответствовать современным требованиям. Отсутствие фреймворка очень серьёзный недостаток сегодня. Очень.

Еще раз. Дай определение framework. Что ты имеешь ввиду?

CS>>Для себя лично я не считаю возможным инвестировать в нечто работающее на одной платформе и при хорошем раскладе карт. Во всяком случае не GUI разработку.

IT>Для GUI ещё долго не будет ничего работающего на всех платформах. Java уже обломалась, а в .NET это и не планируется. Специфика не та. Это вам не поля из базы данных на объекты мапить. Тут надо пиксель к пикселю, полутень к полутени. Раперы вещь конечно хорошая, но пока они перед гуями пасуют. Думаю, без помощи железячников нам тут не обойтись.

Проблема Java/AWT и WinForms — они система врапперов.
Где-то это хорошо — где-то плохо.
Нужен оптимальный выбор под задачу.

CS>>Уже четыре года я слышу, вот сейчас, сейчас что-то дяди сделают и будет всем шастя великое.
CS>>Чего нынче модно ждать? XAML, да? ну подождем...

IT>Дяди берут то что есть и делают. Если нужен универсальный гуй для любой платформы, то на сегодняшний день он только один — HTML.

Согласен. Но это не гуй. Явно ему требуется Виагра.

IT>ЗЫ. Что касается твоего поста в целом, то он мне вполне симпатичен

Самое время задвинуть традиционную фразу RSDN тимера — а статейку про D для журнала не напишешь?

Чукча не писатель. Вернее писатель но не того.
Могу статью про D в контексте Harmonia — это мне интересно.

CS>Вот выдержка из последнего Morgan Stanley CEO survey:

CS>

CS>IT Vendor Spending Intentions Over the Next Twelve Months

CS>1 Cisco            81% 162
CS>2 Symantec         71% 120
CS>3 IBM              71% 153
CS>4 Red Hat          70% 118
CS>5 Mercury          66% 100
CS>6 Microsoft        66% 195
CS>7 Juniper Networks 64% 92
CS>

CS>здесь

Рекомендую глянуть на survey повнимательнее.
Там зело много интересных тенденций.
Думающий да обрящет.

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

CS>>

CS>> ...
CS>>4 Red Hat          70% 118
CS>> ...
CS>>

Кто бы мог подумать! Хотелось бы узнать причину...

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

CS>>>

CS>>> ...
CS>>>4 Red Hat          70% 118
CS>>> ...
CS>>>

LCR>Кто бы мог подумать! Хотелось бы узнать причину...

А чего тут думать то?

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

CS>Мысли (спорадические) по поводу D.

c-smile, а что повлияло на решение создать GUI для D? Личное любопытство в изучении D или интерес к D настолько возрос, что появился смысл в разработке библиотек для него?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

CS>>>>

CS>>>> ...
CS>>>>4 Red Hat          70% 118
CS>>>> ...
CS>>>>

LCR>>Кто бы мог подумать! Хотелось бы узнать причину...

CS>

А чего тут думать то?

Круто! А это что, %-т virtual hosts, или оборот компаний, использующих это ПО?

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

LCR>>Кто бы мог подумать! Хотелось бы узнать причину...

CS>

А чего тут думать то?
CS>[Кульный график]

Ну собственно о причинах. Ибо графики и числа — следствия.

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

IT>>Например, использование HTTP протокола может быть одним из non functional requirements.

CS>Я не понял про http....
CS>В http запросе есть поле Accept: mime type; xml — один из тысяч известных типов. Другой известный тип кстати application/octet-stream.

Только вот не все файерволы пропускают бинарные данные.

CS>>>Хм... по мне (и не только по мне) наличие этого самого framework это просто один большой минус.
IT>>По мне и не только по мне (а по мнению тех миллионов, которые не используют D) это его фатальный недостаток.
CS>Другие миллионы также не используют .NEt и что?

Для .NET это миллионом больше миллионом меньше. Для D всегда меньше

CS>Давай разберемся что есть framework.
CS>В терминах D (и С/C++) это набор библиотек — templates/classes/whatever.

Ok, согласимся с таким определением.

CS>Например для D известно что-то около 5 GUI имплементаций (шестая Harmonia).

И какую мне выбирать в случае чего? А между собой они совместимы?

CS>Для .NET — одна и та толком даже родную платформу не держит.
CS>Что лучше?

Да ну? Не помню как называлась эта контора, кажется бывший Sybase, да уже и не важно, с сегодняшнего дня она подразделение IBM. Исторически сервера приложений там пишутся на Java, а вот GUI с некоторых пор на .NET. Симптоматично, не правда ли?

CS>Или уже считается что отсутствие выбора это тот бенефит который заставит эти самые миллионы использовать только .NET?

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

CS>Для десяти зданий уже не работает. Затраты на IT department и требования поддержки framework up to date на всех машинах это уже нетривиальная задача.

.NET Framework меняется раз в год, обновляется через Windows Update. В чём проблема?

IT>>Если речь идёт о ширпотребе, то я вполне с тобой согласен.

CS>Речь идет о разработке программных систем вообще а не только для корпоративных приложений с клиентами на Wintel платформе.

И ты считаешь это возможным, особенно для гуёв? Вроде бы Java уже всем доказала, что write once, run everywhere не бывает. Зато очень даже бывает write once, debug everywhere

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

CS>Цифры мне не говорят о том что миллионы начали программировать .NET framework.

Занимаемся выдёргиванием слов из контекста? Напомню, я говорил о разработке многоплатформенных приложений, а не о .NET и не об использовании многих платформ. Я надеюсь, мы все пониаем разницу между "писать многоплатформенные приложения" и "иметь много платформ". .NET, кстати, раз уж ты его бесконечно упоминаешь, великолепно справляется с задачей интеграции с другими платформами. В D вообще предусмотрены какие-либо средства для этого или это вещь в себе?

CS>Crossplatform solutions — да, говорят.
CS>Ниша для D в том числе? да, несомненно.

Вот это как раз и интересно. Как ты собираешься интегрировать свой D-приложение скажем с сервером приложений на Java?

CS>Проблема Java/AWT и WinForms — они система врапперов.
CS>Где-то это хорошо — где-то плохо.
CS>Нужен оптимальный выбор под задачу.

А Harmonia (и остальные 5 гуёв для D) разве не раперы? Ты хочешь сказать, что ты напрямую с железом работаешь?

IT>>Дяди берут то что есть и делают. Если нужен универсальный гуй для любой платформы, то на сегодняшний день он только один — HTML.

CS>Согласен. Но это не гуй. Явно ему требуется Виагра.

Может быть даже уже и не требуется совсем.

IT>>ЗЫ. Что касается твоего поста в целом, то он мне вполне симпатичен

Самое время задвинуть традиционную фразу RSDN тимера — а статейку про D для журнала не напишешь?

CS>Чукча не писатель. Вернее писатель но не того.
CS>Могу статью про D в контексте Harmonia — это мне интересно.

Напиши в контексте. Только желательно без упоминания .NET, а то получается, что мы не достоинства D обсуждаем, а недостатки .NET

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

[ Поскипано про .NET. Закрыли тему ]

CS>>Например для D известно что-то около 5 GUI имплементаций (шестая Harmonia).
IT>И какую мне выбирать в случае чего? А между собой они совместимы?

В основном это wrappers вокруг существующих OS widgets.
Посмотри здесь http://www.dsource.org/projects/

Harmonia не использует underlying os widgets. Посмотри demo через SPY++
Т.е. использует подход browsers — os independent widget set.

Что выбрать? В зависимости от того что тебе нужно.
Можешь идти по пути SWT http://www.dsource.org/projects/dwt/ —
это путь Eclipse.

Если же тебе нужно на всех платформах иметь строго одинаковый look and
feel — Harmonia.

CS>>Речь идет о разработке программных систем вообще а не только для корпоративных приложений с клиентами на Wintel платформе.

IT>И ты считаешь это возможным, особенно для гуёв? Вроде бы Java уже всем доказала, что write once, run everywhere не бывает. Зато очень даже бывает write once, debug everywhere

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

Да это возможно. Если твои классы не используют внутри переключатели
version(Windows) version(linux) то они с вероятностью 99% переносимы.

Да, тестировать нужно на всех платформах.
Но не переписывать.

CS>>Crossplatform solutions — да, говорят.
CS>>Ниша для D в том числе? да, несомненно.

IT>Вот это как раз и интересно. Как ты собираешься интегрировать свой D-приложение скажем с сервером приложений на Java?

Как обычно. Могу написать JNI модуль на D.
А могу на D запустить инстанс Java VM.
Это если это действительно нужно кому-нибудь.

CS>>Проблема Java/AWT и WinForms — они система врапперов.
CS>>Где-то это хорошо — где-то плохо.
CS>>Нужен оптимальный выбор под задачу.

IT>А Harmonia (и остальные 5 гуёв для D) разве не раперы? Ты хочешь сказать, что ты напрямую с железом работаешь?

Я работаю напрямую с window manager — использую только top level windows (no child controls)
Т.е. внутри чистых native классов всего ничего: NativeApplication, NativeGraphics и NativeWindow.

IT>>>Дяди берут то что есть и делают. Если нужен универсальный гуй для любой платформы, то на сегодняшний день он только один — HTML.
CS>>Согласен. Но это не гуй. Явно ему требуется Виагра.

IT>Может быть даже уже и не требуется совсем.

Требуется.
Модель HTML — бесконечная плоская лента не работает толком
для экранных форм.
Набор базовых widgets — явно не достаточен.
Попытки создания чего-то своего типа datetime selector — плакать хочется.

CS>>Чукча не писатель. Вернее писатель но не того.
CS>>Могу статью про D в контексте Harmonia — это мне интересно.

IT>Напиши в контексте. Только желательно без упоминания .NET, а то получается, что мы не достоинства D обсуждаем, а недостатки .NET

Ни сном ни духом не хотел и не хочу про .NET. Надоело.
Но как-то всегда находятся люди которые говорят "Если вы, гражданские, такие умные чего ж у вас фреймворка то нет"

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

CS>Harmonia не использует underlying os widgets. Посмотри demo через SPY++
CS>Т.е. использует подход browsers — os independent widget set.

Т.е. практически всё с самого нуля? Если так, то тебе один шаг до переноса этого и на C# и на Java. Или есть трудности?

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

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

CS>Да, тестировать нужно на всех платформах.
CS>Но не переписывать.

Тут под Windows-то приходиться 4-ре define держать (95, 98/SE/ME, W2K, XP) — в вы "многоплатформенность"

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

E>c-smile, а что повлияло на решение создать GUI для D? Личное любопытство в изучении D или интерес к D настолько возрос, что появился смысл в разработке библиотек для него?

Мотиваций много.

Одна из них:

Проект(исследовательская фаза) спонсируется фирмой (государственный контрактор) поддерживающую информационную
систему объединяющие полицию, пожарников и скорую североамериканского континента. Унифицированная клиентская платформа. После обсуждения возможности создания системы wrappers для HTMLayout я предложил D/Harmonia подход.
Они согласились.

Вторая: следующая версия BlockNote для Win и Mac.

Есть еще примерно десяток интересных проектов связанных с этим подходом.

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

CS>>Вполне возможная конструкция как для D так и для C/C++ и вообще всего чего шевелится.

LCR>Все современные языки полны по Тьюрингу. Тем не менее важность адекватной нотации трудно переоценить.

О, да! Полноту по Тьюрингу и важность адекватной нотации трудно переоценить. И также факт что здоровым и богатым быть вельми как хорошо.

CS>>Динамически же (в runtime) создавать классы ( .class files ) имхо бессмысленно.
CS>>Или я ошибаюсь? Если да то можно ли use case?

LCR>Это существенно для asp.net, JSP, JSF. Текущий мой проект содержит генерацию иерархий классов из спецификации в XML как необходимый ингредиент. Эти спецификации могут меняться, размножаться и т.п., перекомпиляция и перезапуск недопустимы.

Дашь IP сервера на попробовать? У меня есть пара XML Schemas прикольных. Размножаются — что те кошки.

(Не бери в голову — это я выпендриваюсь)

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

IT>Здравствуйте, c-smile, Вы писали:

CS>>Harmonia не использует underlying os widgets. Посмотри demo через SPY++
CS>>Т.е. использует подход browsers — os independent widget set.

IT>Т.е. практически всё с самого нуля? Если так, то тебе один шаг до переноса этого и на C# и на Java. Или есть трудности?

На Java переносить не надо, т.к. собсвенно вот с чего все начиналось
http://terrainformatica.com/org/j-smile/index.htm
это Java + C

На C# в принципе возможно перенести. Но про WinForms придется забыть.

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

psg>Здравствуйте, c-smile, Вы писали:

CS>>Да, тестировать нужно на всех платформах.
CS>>Но не переписывать.

psg>Тут под Windows-то приходиться 4-ре define держать (95, 98/SE/ME, W2K, XP) — в вы "многоплатформенность"

Harmonia использует голый WinAPI. Предполагается что для всех Win32 будет работать один и тот же
exe. В этом собственно и идея/потребность.

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

CS>На C# в принципе возможно перенести. Но про WinForms придется забыть.

Это как бы не проблема. О WinForms даже MS рада забыть.

А для линукса у тебя версия есть? Может тогда это дело и под Моно портировать? Это уже будет серьёзный удар по вражеским бастионам

... << RSDN@Home 1.1.4 beta 5 rev. 395>>

В дотнете можно сформировать в рантайме класс без всяких компиляторов. Можно динамически создать сборку и емитить ее в лоб используя МСИЛ-инструкции. Но используется такой подход весьма редко в виду сложности отладки.

Posted via RSDN NNTP Server 1.9

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

IT>Это как бы не проблема. О WinForms даже MS рада забыть.

Откуда дровишки?

IT>А для линукса у тебя версия есть? Может тогда это дело и под Моно портировать? Это уже будет серьёзный удар по вражеским бастионам

Для линукса пока нет. Но будет.

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

IT>Для GUI ещё долго не будет ничего работающего на всех платформах. Java уже обломалась, а в .NET это и не планируется. Специфика не та. Это вам не поля из базы данных на объекты мапить. Тут надо пиксель к пикселю, полутень к полутени. Раперы вещь конечно хорошая, но пока они перед гуями пасуют. Думаю, без помощи железячников нам тут не обойтись.

У меня есть чувство что Avalon (или подобная библиотека) может исправить это положение вещей.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

CS>Откуда дровишки?
Avalon

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Здравствуйте, c-smile, Вы писали:

CS>>Откуда дровишки?
WH>Avalon

Т.е. ты хочешь сказать что Avalon заменит собой WinForms?
И WinForms канут в лету?
Честно говоря я так и не понял Avalon он поверх, рядом или вместо WinForms?

Или если проводить аналогии с Java, то WinForms это Java/AWT (собственно так оно и есть по большому счету),
а Avalon это уже как бы Swing будет?

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

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

IT>>Для GUI ещё долго не будет ничего работающего на всех платформах. Java уже обломалась, а в .NET это и не планируется. Специфика не та. Это вам не поля из базы данных на объекты мапить. Тут надо пиксель к пикселю, полутень к полутени. Раперы вещь конечно хорошая, но пока они перед гуями пасуют. Думаю, без помощи железячников нам тут не обойтись.

WH>У меня есть чувство что Avalon (или подобная библиотека) может исправить это положение вещей.

Для того чтобы Avalon это исправил нужен reengineering всего оконного хозяйства.
Как минимум всех child controls. win controls и common controls. Что в принципе
не сложно, но иметь два параллельных набора.... ну не знаю...
Судя по ушам и хвосту кто-то главный в МС всегда пресекает такие попытки.

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

CS>Т.е. ты хочешь сказать что Avalon заменит собой WinForms?
Да.
CS>И WinForms канут в лету?
Да.
CS>Честно говоря я так и не понял Avalon он поверх, рядом или вместо WinForms?
Вместо. Причем Avalon не имеет ничего общего с виндовым гуи. Он построен на совершенно иных принципах и с моей точки зрения ему ничто не мешает быть кроссплатформенным.
Болие того огромная часть Avalon'а managed. В нативную сборку уходит только низкоуровневый рендер.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

CS>Для того чтобы Avalon это исправил нужен reengineering всего оконного хозяйства.
Avalon не использует оконное хозяйство.
CS>Как минимум всех child controls. win controls и common controls. Что в принципе не сложно, но иметь два параллельных набора.... ну не знаю...
Скорей всего MS просто забъет на старый гуи. Баги они еще какоето время будут фиксить, а вот развивать врятли.
CS>Судя по ушам и хвосту кто-то главный в МС всегда пресекает такие попытки.
Раньше это было не эффективно. Переделка ГУИ нигего не давала с точки зрения пользователя.
Сейчас с распространением 3D акселераторов появилась возможность вывести ГУИ на качественно новый уровень. Вот ребята из MS и занялись этим. И за компанию переделывают все по умному плюс ради удешевления разработки и раскрутки .НЕТ'а они все это делают на .НЕТ'е.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Болие того огромная часть Avalon'а managed. В нативную сборку уходит только низкоуровневый рендер.

Насколько я понял Avalon это такой большой MFC.

Вот высказывание одного из разработчиков.
http://channel9.msdn.com/ShowPost.aspx?PostID=1653

Вот статья Chris Anderson (aka Avalon).
http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnavalon/html/avalon03262004.asp

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

CS>Насколько я понял Avalon это такой большой MFC.
Нет "такой большой MFC" это WinForms. А Avalon это совершенно другуй ГУИ.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

CS>Или если проводить аналогии с Java, то WinForms это Java/AWT (собственно так оно и есть по большому счету),

Так да не совсем. AWT на порядок более убог.

CS>а Avalon это уже как бы Swing будет?

Да, но в отличие от свинга внизу лежит не AWT, а DirectX и специализированный код.

... << RSDN@Home 1.1.4 beta 6a rev. 443>>

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

CS>Есть ли *в языке* конструкция типа eval("source code").
CS>Ответ — нет. Ни в C# ни в D, ни в Java, ни в С/С++. Как в любом другом компилируемом языке.

Сколко можно повторять одни и те же заблуждения? Скачай R# полюбуйся на аналог eval("source code") или RFD и полюбуйся на возможности Emit-а.

CS>В JavaScript (JS.NET и JS.D) — да есть. Как наверное и в любом другом *интерпретируемом* языке/системе.

JS.NET, как ты его называешь, не интерпретируемый язык. Он всегда компилируется. Как и Шарп. В нем просто встроены дополнительные механизмы вывода и приведения типов.

... << RSDN@Home 1.1.4 beta 4 rev. 351>>

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

И почему это не мешат куче языков в том числе тому же C# 2.0? А ведь на нем и в функциональном стиле можно писать, и в ООП, и в компонентном, обобщенном и даже в процедурном.

... << RSDN@Home 1.1.4 beta 4 rev. 351>>

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

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

psg>>К тому же есть тема, что язык, содержащий внутри себя "мультипарадигмность" будет (a) очень сложно компилировать и (b) очень медленно компилировать. Из (a) имеет массу "особенностей"

, а из (b) — тихое бешенство, когда тестовый проектик собирается по 40 минут.

VD>И почему это не мешат куче языков в том числе тому же C# 2.0? А ведь на нем и в функциональном стиле можно писать, и в ООП, и в компонентном, обобщенном и даже в процедурном.

Ага, постепенно рождается очередной монстр-уродец наподобие C++. Ну правильно, свято место пусто не бывает

c-smile пишет:

> *Mixins*: В D есть уникальная фича которая в C/C++ в прямом виде
> отсутствует — mixins.
> Скажем у меня есть две функции в которых используется один и тот же
> фрагмент кода, тогда в D
> делают так:
>
>template(T) average
>{
> T val = x + y / 2;
>}
>
>int foo(int x, int y)
>{
> mixin average!(int); // "подмешивание" фрагмента
> return val;
>}
>
>double bar(double x, double y)
>{
> mixin average!(double); // "подмешивание" фрагмента
> return val;
>}
>
>
>
А от этого может быть больше вреда, чем пользы, будет способстовать
плохому стилю, ИМХО.

Posted via RSDN NNTP Server 1.9

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

A>c-smile пишет:

>> *Mixins*: В D есть уникальная фича которая в C/C++ в прямом виде
>> отсутствует — mixins.

A>А от этого может быть больше вреда, чем пользы, будет способстовать
A>плохому стилю, ИМХО.

Может.
Но это лучше чем #define в С/С++ правда?
См. http://digitalmars.com/d/pretod.html (в самом конце)

c-smile wrote:
> Здравствуйте, achmed, Вы писали:
>
>> c-smile пишет:
>
>>> *Mixins*: В D есть уникальная фича которая в C/C++ в прямом виде
>>> отсутствует — mixins.
>
>> А от этого может быть больше вреда, чем пользы, будет способстовать
>> плохому стилю, ИМХО.
>
> Может.
> Но это лучше чем #define в С/С++ правда?

В данном случае C++ аналогом будет не define, а шаблонная функция. Проще и
понятнее, чем mixin.

Posted via RSDN NNTP Server 1.9

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

A>В данном случае C++ аналогом будет не define, а шаблонная функция. Проще и
A>понятнее, чем mixin.

В данном случае да.

Но вот из реальной жизни пример, имплементация intrusive list

//|
//| tree_element - mixin template - implemetation
//| of tree node
//|
template tree_element(NODE) 
{
    NODE _parent;
    NODE _next;
    NODE _prev;
    NODE _firstchild;

    void tree_element_initialize() { _next = _prev = this; }
}

//|
//| access methods/properties likely to be public
//| 
template tree_element_methods(NODE) 
{
    bool detached() { return (_parent is null); }
    bool attached() { return !(_parent is null); }

    // sibling ops
    NODE nextSibling()  { return (_parent is null)? null: (this is _parent.lastChild()? null: _next); }
    NODE prevSibling()  { return (_parent is null)? null: (this is _parent.firstChild()? null: _prev); }
    NODE firstSibling() { return _parent is null? null: _parent.firstChild(); }
    NODE lastSibling()  { return _parent is null? null: _parent.lastChild(); }

    ....
 
}

// class - tree node

class MyTreeNode {

  private:
     mixin tree_element!(MyTreeNode); 

  public:
     this() { tree_element_initialize(); }

     mixin tree_element_methods!(MyTreeNode); // standard tree methods

     ....
}

"c-smile" <13953@users.rsdn.ru> wrote in message
news:1159339@news.rsdn.ru
> Здравствуйте, alexeiz, Вы писали:
>
>> В данном случае C++ аналогом будет не define, а шаблонная функция.
>> Проще и понятнее, чем mixin.
>
> В данном случае да.
>
> Но вот из реальной жизни пример, имплементация intrusive list

На C++ такое тоже можно. Curiously recurring template называется. Опять не #define, но, может быть, не так чисто, как в D.

Posted via RSDN NNTP Server 1.9

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

uw, а не могли бы Вы послать мне
письмо на news@terrainformatica.com ?
Это по поводу thor...

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

A>"c-smile" <13953@users.rsdn.ru> wrote in message
A>news:1159339@news.rsdn.ru
>> Здравствуйте, alexeiz, Вы писали:
>>
>>> В данном случае C++ аналогом будет не define, а шаблонная функция.
>>> Проще и понятнее, чем mixin.
>>
>> В данном случае да.
>>
>> Но вот из реальной жизни пример, имплементация intrusive list

A>На C++ такое тоже можно. Curiously recurring template называется. Опять не #define, но, может быть, не так чисто, как в D.

А причем здесь curiously recurring templates скажи на милость?
В моем примере mixin использованы именно как defines только правильные

Кстати D тоже поддерживает curiously recurring templates
http://c2.com/cgi/wiki?CuriouslyRecurringTemplate

and the D Programming Language implementation of it:

class ArithmeticType(T)
{
    T opAdd(T other)
    {
        T result = new T(this);
        result += other;
        return result;
    }
}

class Quaternion: ArithmeticType!(Quaternion)
{
    this() { }
    this(ArithmeticType!(Quaternion) t) { }

    Quaternion opAddAssign(Quaternion other)
    {
         // etc.
    }
}

So now there are two languages that can do the CRTP <g>. (Walter)

"c-smile" <13953@users.rsdn.ru> wrote in message
> Здравствуйте, alexeiz, Вы писали:
>
>> "c-smile" <13953@users.rsdn.ru> wrote in message

>>> Но вот из реальной жизни пример, имплементация intrusive list
>
>> На C++ такое тоже можно. Curiously recurring template называется.
>> Опять не #define, но, может быть, не так чисто, как в D.
>
> А причем здесь curiously recurring templates скажи на милость?

Таким образом mixins эмулируются на C++. Вот, примерно так я бы реализовал это с помощью curiously recurring templates:

template <typename NODE>
struct tree_element
{
    NODE * parent_;
    NODE * next_;
    NODE * prev_;
    NODE * firstchild_;

    tree_element()
    {
        next_ = prev_ = static_cast<NODE *>(this);
    }
};

template <typename NODE>
struct tree_element_methods
{
private:
    NODE * derived()
    {
        return static_cast<NODE *>(this);
    }

public:
    bool detached() { return derived()->parent_ == NULL; }
    bool attached() { return !detached(); }

    // sibling ops
    NODE * nextSibling() 
    {
        NODE * d = derived();
        return d ? NULL : (d == d->parent_->lastChild() ? NULL : d->next_);
    }
};

class MyTreeNode
    : private tree_element<MyTreeNode>
    , public tree_element_methods<MyTreeNode>
{
public:
    MyTreeNode() {}
};

> В моем примере mixin использованы именно как defines только
> правильные

Я же хотел сказать, что если есть возможность сделать что-либо без использования #define, то так и нужно поступать.

Тут нужен посложнее пример, типа message crackers из MFC, чтобы показать приемущество прямой поддержки mixin'ов в языке. Хотя, в принципе, и message crackers тоже совсем даже неплохо реализуются без define'ов.

>
> Кстати D тоже поддерживает curiously recurring templates

Woo-hoo! Way to go D!

Posted via RSDN NNTP Server 1.9

Полезна для быстрого ознакомления: что есть D как язык.

http://uvsc.freshsources.com/D.ppt

CS>В настоящее время готовлю к выпуску
CS>Harmonia GUI framework for D.
CS>screenshot: http://www.terrainformatica.com/screenshots/harmonia.png
CS>Demo: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
CS>Собственно D здесь: http://www.digitalmars.com/d/

Андрей, а почему ты придерживаешься HTML в GUI?

Здравствуйте, Кодёнок, Вы писали:

CS>>В настоящее время готовлю к выпуску
CS>>Harmonia GUI framework for D.
CS>>screenshot: http://www.terrainformatica.com/screenshots/harmonia.png
CS>>Demo: http://www.terrainformatica.com/screenshots/HarmoniaDemo.zip
CS>>Собственно D здесь: http://www.digitalmars.com/d/

Кё>Андрей, а почему ты придерживаешься HTML в GUI?

Хороший вопрос. Но непонятно как на него отвечать.

Прежде всего зачем язык разметки в GUI?:
HTML выполняет три базовых функции: 1) layout manager
( в Harmonia нет layout managers в чистом виде вообще кроме HTML )
и 2) renderer всякой текстовой информации и оформления и
3) удобное средсво локализации

смотри имеем две версии:

<P>Please input amount of money: <INPUT id=amount /> and select currency <INPUT type=select /></P>

<P>Пожалуйста введите сумму денюжек: <INPUT id=amount /> и выберите тип валюты <INPUT type=select /></P>

Понятно что форма/диалог настраиваемая таким образом в разы лучше чем то что нам предлагает resource editor.

Почему именно HTML?

1) Зачем изобретать велосипед (XAML/XUL) когда уже все (почти) есть ? (XAML/XUL это нечто более чем просто разметка, но это мы опускаем пока)
2) Short learning curve.
3) Набор готовых средств для его создания.
4) Прверенность временем и много еще всякого.

В Harmonia HTML это скорее XHTML так как допускает только well-formed XML.
И еще одно "но" и принципиальное весьма — Проценты.
Проценты здесь это "проценты от свободного места" т.е. скажем нам надо
чтобы фраза

<P>Please input amount of money: <INPUT id=amount width=70% /> and select currency <INPUT type=select width=30%/></P>

занимала всю строку и размеры input устанавливались исходя из соотношения 7/3 — так и пишем (width attribute).
В живую как это "пружинится" можно посмотерть в Demo (закладка Basic Control Test — первые два edit box)

То же справедливо и для вертикальных контейнеров типа DIV.

Ну и потом HTML позволяет хорошо и естесвенно разделить оформительскую часть
от собсвенно логики UI.

Вот примерно так.

Да, еще...я не стал нагружать HTML функциями обработки событий как в XUL/XAML потому как
так считаю эти функции больше кода приложения чем деклараций. В коде оброботку событий
и логику *всегда* делать удобнее и эффективнее.
Но ничего не мешает приделать к Harmonia тот же DMDScript или LUA если задача того требует...

От:	c-smile	http://terrainformatica.com
Дата:	01.05.05 06:23
Оценка:	234 (21)

От:	LCR	lj://_lcr_
Дата:	01.05.05 06:28
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	01.05.05 06:47
Оценка:

От:	LCR	lj://_lcr_
Дата:	01.05.05 07:15
Оценка:

От:	LCR	lj://_lcr_
Дата:	01.05.05 07:20
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	01.05.05 15:48
Оценка:

	От:	Зверёк Харьковский
	Дата:	01.05.05 18:14
	Оценка:	29 (4)

От:	IT	linq2db.com
Дата:	02.05.05 03:48
Оценка:	+2

От:	eao197	http://eao197.blogspot.com
Дата:	02.05.05 07:45
Оценка:	+2

	От:	Воронков Василий
	Дата:	03.05.05 00:02
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	05.05.05 03:31
Оценка:

От:	achmed	https://www.linkedin.com/in/nail-achmedzhanov-9907188/
Дата:	05.05.05 06:57
Оценка:	+1 -1

	От:	Кодёнок
	Дата:	16.05.05 06:10
	Оценка:	18 (1)