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

Z>Здравствуйте, Saidai no, Вы писали:

Z>А почему бы куски реализации не писать прямо в класс? А сам класс пометить макроатрибутом, который допишет то, что нужно.
В основном, чтобы меньше писать руками :) Но в принципе и так можно.

SN>>2. Макрос для метода ImplementInterface, который пытается с помощью изменения регистра и добавления/удаления префиксов найти подходящий метод в исходном классе и подключить его. Если метод не найден, выводит warning и подставляет throw NotImplementedException.
Z>Можно просто эти методы пометить как абстрактные, а макроатрибут их перепишет.
Мм, это как раз то, от чего хотелось бы уйти. Поясню проблему: DOM-интерфейсы большие, страшные и сильно связанные между собой (к тому же, генерируются сторонней утилитой). Например, интерфейс Window содержит больше 100 членов. Мне, на данном этапе, из них нужно хорошо если штук 5, а про остальные хотелось бы чтобы позаботился макрос, и мне пока неважно будут они к чему-то подключены или будут кидать NotImplemented.

SN>>3. Макрос уровня выражения proxy, который подставляет конструктор нужного типа в тех местах, где нужно вернуть DOM-интерфейсы в другую сборку.
Z>Если английский позволяет, пообщайся с @philiplaureano в твиттере, он думал насчет такого макроса (для DI), возможно у него даже есть готовое решение.
Ок, спасибо, пообщаюсь

SN>>2. Если это так, то каким образом вообще можно получить информацию о том, какие интерфейсы требует реализовать заданный, какие у них требуемые методы и как предоставленные пользователем реализации, например, свойств сопоставлять интерфейсу, чтобы сообразить, какие методы дописывать?
Z>Насколько я понял, если все это делать в классе, вопрос отпадает.
Ну, на самом деле не совсем отпадает — не хочется прописывать руками сотни свойств и методов. Но я пока копаю в сторону плана Б (думаю, код зря не пропадет) и по этому вопросу, мне кажется, можно поступить так: требовать, чтобы все реализации методов интерфейса были explicit и сверять ParsedImplemented со списком членов всех требуемых интерфейсов. Если пользователь что-то не так напишет, стандартной ошибки компилятора, по идее, должно быть достаточно.

SN>>4. Некоторые методы интерфейсов требуют возвращать другие интерфейсы, для которых хорошо бы уметь автоматически подставлять proxy. Как можно это реализовать? Все интерфейсы лежать в отдельной от прокси-объектов сборке в своем неймспейсе.
Z>Не до конца понял задачу.
Минимальный пример в идеальном случае:

// интерфейсы
namespace Interface.Dom {
  interface Document {
    Element getElementById(elementId : string )
  }
  interface Element { ... }
}

// реализация
namespace Monobjc.Webkit.DOM {
  class DOMDocument {
    DOMElement GetElementById(elementId : NSString);  
  }
  class DOMElement { ... }
}

// вызов макроса
namespace Cocoa.Dom {
  [assembly: ImplementInterface(Document, DOMDocument)]
  [assembly: ImplementInterface(Element, DOMElement)]
}

// обертка, которая должна сгенерироваться макросами
namespace Cocoa.Dom {
  class DocumentProxy : Interface.Dom.Document {
    _document : DOMDocument;
    this (_document : DOMDocument) { this._document = _document }
    Element getElementById(string elementId) {
      ElementProxy(_document.GetElementById(NSString.op_Implicit(elementId) : NSString)) // или proxy(Element)(...)
    }
  }
  class ElementProxy : Interface.Dom.Element { ... }  
}

Причем про NSString макрос "догадывается" по наличию op_Implicit, а про DOMElement — т.к. он упоминается в таком же макросе.

Z>Можно в переменных, но это криво и не будет дружить с интеграцией (она несколько раз запускает компиляцию). Трувей это использование хеша UserData в компиляторе. Желательно по ключу который гарантированно не пересечется с другими макросами.
Ок, не знал, спасибо :) Главное чтобы какой-то способ был. А в компиляторе нет стандартных средств для генерации такого уникального ключа?)


SN>>P.S. Кстати, на тему моего предыдущего вопроса: компилятор собирается Mono с патчем, который был предложен в моновской багзилле еще давно, но дальше, уже при работе компилятора, mono начинает падать в каких-то странных местах. Так что если у кого-то есть необходимость собирать компилятор с mono, можно держать отдельно локальную версию mono "для сборки" :)

Z>А падает ли в тех же местех моно на компиляторе собранном под .net?
Сейчас почему-то не могу воспроизвести; тогда то ли сборка какая-то была недоступна и на этапе ее поиска все падало, или что-то вроде того. Причем компилятор как раз был с сайта, а не самособранный.
И собирал я им какой-то свой небольшой проект.