А как у вас с БАГАМИ?
Вот такой вопросик на сегодня образовался - А как у вас с БАГАМИ?
Бо, полез... ну надо было... сегодня в код, сделанный под нехилым тайм-прешуре месяца три назад... а там... Не, ну я конечно знал, что там есть проблемные места, но чтобы они были настолько просто спрямляемыми... ндаа... еще разок убедился, что не пром.код надо просматривать после того как он отлежится...
Так как у вас с багами?
Попутно (упрощено).
interface I1
{
object Add(MyArg aMyArg);
}
interface I2
{
object Add(MyArg aMyArg);
}
class T1 : SortedList, I1
{
protected object Add(MyArg aMyArg)
{
return base.Add(aMyArg);
}
object I1.Add(MyArg aMyArg)
{
return this.Add(aMyArg) ;
}
}
class T2 : T1, I2
{
object I2.Add(MyArg aMyArg)
{
return base.Add( // как вы думаете, что тут в списке выбора?
// я, по наивности, рассчитывал на две версии Add()
// тем не мение - компилируется и работает правильно - вызывается protected Add() из T1
}
}
И тут билли что-то недолепил... Ну совсем как я в том коде, что сегодня просматривал... но у меня хоть работало как заданно...

object I1.Add(MyArg aMyArg)
может вызываться только через ссылку на интерфейс, поэтому в строке:
return base.Add( // как вы думаете, что тут в списке выбора?
оно и не должно было предлагаться. RTFM.

оно и не должно было предлагаться. RTFM.
-------
protected object Add(MyArg aMyArg) - ??? - насколько я понимаю - этот метод должен быть видимым в интерфейсе потомка. Компилятор C# со мною в этом согласен. Не согласны - поделка билли под названием .Net Studio 2002 (ну это понятно) и voxel3d [/nick] (а тут - непонятно)

Может стоило кроме BNF ещё и стандарт вкурить? Короче говоря, я тоже не понял, что тебе непонятно. Я кроме того не понял, зачем тебе два одинаковых интерфейса.

>> оно и не должно было предлагаться.
> protected object Add(MyArg aMyArg) - ???
Нет, я говорил про:
object I1.Add(MyArg aMyArg)
- оно не должно было предлагаться. А это:
protected object Add(MyArg aMyArg)
должно было как раз предлагаться.

Короче говоря, я тоже не понял, что тебе непонятно.
-------
Мне непонятно, почему защищенный, но не интерфейсный, метод предка (T1) не предлагается к выбору при при написании кода в интерфейсе потомка (T2). При этом, если написать руками то, что должно быть, то все работает как должно быть. Т.е. стандарт не соблюдается либо Студией, или компилятором.
Я кроме того не понял, зачем тебе два одинаковых интерфейса.
------
Это из той задачи что я пишу. Там есть одно общее место хранения данных, плюс, в сишной нотации, массивы для хранения подвыборок ссылок. Интерфейс нижнего уровня просто добавляет ссылку в свой список, верхнего - проверяет наличие уже имеющегося в общей куче вхождения и, если есть, добавляет ссылку на него, если нет - добавляет сначала в общую кучу, потом локально. Можно было в принципе сделать и на одном уровне - разруливая типами, но я решил перестраховаться - раскидал по уровням. Как оказалось - сделал правильно.
Я тут как-то постил до чего мы в конторе договорились по поводу реализации:
field1 = Cashe.Network["netName"].Server["servName"].Database["dbName"].Table["tblName"].Field["fldName"];
field2 = Cashe.Field["fldName"];
тут свойства (расширенные, нестандатрные, например: string Property("имя типа используемого для отображения компонента") ) field1 равны такому же для field2 только в том случае, если не задано специальное значение для комбинации [tblName].[fldName] (потенциально может быть задана вся предшествующая строка). При этом field1 и field2 реально ссылаются на один и тот же элемент в общей куче... Я бы наверное уже бы умер на кодинге, пытаясь разобраться чего, куда и когда писать, если бы не изоляция по уровням и отдельные интерфейсы...
Хммм... только что осознал, что для трекированя навигации надо было вводить еще один уровень - все было бы еще немножко проще... Ну да ладно - оно и так почти изолировано...

> Мне непонятно, почему защищенный, но не интерфейсный, метод предка (T1) не предлагается к выбору при при написании кода в интерфейсе потомка (T2).
В 2005 предлагается.

class T1 : SortedList, I1
{
  protected object Add(MyArg aMyArg)
  {
    return base.Add(aMyArg);
  }
...
}

Пример, кстати, некорректен. base.Add() - вызoв методa из SortedList, который принимает два аргумента. Если попытаться base.метод_из_интерфейса - будет ошибка.

protected object Add(MyArg aMyArg)
должно было как раз предлагаться.
-------
Должно. Но не предлагается. Предлагается только базовый Add() от SortedList'а.

А в 2005 предлагается. Обновляйте паделие.

0. 2002 версия глючна.
1. В 2005 предлагается T1.Аdd, как и должно быть. I1.Add доступен как уже сказано только через интерфейс I1. Я не вижу несоответствия со стандартом:

2. Как ты запутанно мыслишь...

Пример, кстати, некорректен. base.Add() - вызoв методa из SortedList, который принимает два аргумента.
------
base.Add() - это вызов метода предка. Какого именно - определяется именем и набором параметров (полное совпадение опускаем).
В I2 мне нужен был именно protected object Add(MyArg aMyArg) из Т1 и он вызывается, если написать руками корректный вызов.
В написании вызова SortedList::Add() в T1 - там, да, описался. Должно было быть return base.Add(aMyArg.Key,aMyArg); для SortedList, но у меня там случается и ArrayList... так что надеюсь на прощение...
Если попытаться base.метод_из_интерфейса - будет ошибка.
-------
Разумеется. Только она отловится при компиляции.

Не, главное въехать в то, что хотел сказать Мурр. Интерфейсный он не хотел, он не понимал, почему SortedList.Add один предлагается, без T1.Add, который protected.

Обновляйте паделие.
------
Это не ко мне, бо, я использую либо СБилдер, либо то что дают...

Да я уже понял. Просто, посмотрите, Томассон тоже подумал, что Вам надо, чтобы был доступен интерфейсный метод. Надо что-то исправлять в программе, которая занимается изложением мыслей.

2. Как ты запутанно мыслишь...
------
Не запутанно, а нестандартно...
Эээ... можешь предложить более приемлемую модель для описанной выше задачи?

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

Я честно говоря в проблему не въехал. Если вопрос стоит в прозрачной имплементации кеширования, то для этого шаблоны типа прокси неплохо годятся.

А где тут Томассон? Или это как с сусликом?

Гы, приплыли. Мне пора спать. Меня переклинило, на этот аватар твой, у Томассона был похожий - пъющий чай, у меня со слепу прочная ассоциация в моске всплыла.

то для этого шаблоны типа прокси неплохо годятся.
------
В С#??? (выбор инструмента для реализации - не мой, что дали - на том и играю)
Хммм... Шилда и еще кучку книг я слил - буду осиливать на выходных...
Я честно говоря в проблему не въехал.
------
Кеширование - это часть. Я ее уже сделал. Работает и используется. Смена приведет к нежелательному пересмотру остального кода, а там довольно много... Так что чтобы я не делал, внешне ничего меняться не должно. Может быть это и есть наибольшая проблема в задаче...
Сейчас добиваю проблемку навигации. field1 и field2 (смотри выше) это ссылки на один и тот же инстансе TField'a. Они могут сохранятся неопределенное время и их может быть не две и не три. Но вот расширенные свойства должны возвращаться правильные, приписанные к контексту получения ссылки, независимо от порядка получения и использования ссылок... Набдо бы посмотреть перегрузку операции "."(точка), но что-то мне говорит, что она или не будет перегружаться, или одна только перегрузка не решит проблемы... Ну да это я добью в ближайшие день-два...
Вот потом - начнется настоящий мрак. XML & XSLT. То, что я сейчас получаю используя С#, нужно будет выгрузить в XML... ну это не проблема - классы умеют сериализоватся и десериализоватся нужным мне способом... а выгруженный XML надо будет трансформировать (XSLT) в код - SQL, С#, С++, Паскаль - с заданной функциональностью... при этом выгруженный документ не содержит полной информации - она должна браться со сторонних файлов... Нее, пойду-ка я спать, а то завтра навигацию не добью...