| Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 09:12 | |
| Оценка: | +1 -8 ![]() | |
| Никогда раньше не работал с .NET, но слышал что она является компонентной/модульной. Вчера решил проверить так ли это на самом деле. Основным принципом модульной расширяемой системы является то, что она состоит из динамически {загружаемых, выгружаемых, линкуемых} модулей, причем каждый модуль может быть загружен и слинкован с остальными модулями, естественно, только один раз (зачем в модульной системе загружать и линковать 2 экземпляра одного и того же модуля???); а также то что она обладает одним единственным сборщиком мусора на всю систему. Например, модуль M1:
будучи один раз загруженным в память предоставляет переменную M1.X (в одном единственном экземпляре) всем остальным модулям всей модульной расширяемой операционной системы. В .NET это не так! Каждый якобы модуль системы .NET (будем писать его в кавычках: "модуль"), оказывается вовсе не является модулем всей системы .NET. А он является модулем лишь каждого конкретного приложения которое его импортировало. Сколько приложений импортировало этот "модуль" столько экземпляров его и будет создано. Вот пример: Исходный код "модуля" M1.dll:
Исходный код "модуля" A1.exe:
Исходный код "модуля" A2.exe:
Скомпилировал M1.dll, A1.exe, A2.exe и положил их троих в один и тот же каталог. Запустил A1.exe и A2.exe, каждый из них вывел один и тот же ответ M1.Var.X = 1. То есть каждый из "модулей" A1 и A2 работает со своим экземпляром "модуля" M1, а вовсе не с одним единственным как это должно быть в модульной расширяемой системе. Выводы 1) Сама .NET не является модульной системой. Модульной системой является каждое конкретное .NET приложение, в рамках которого модули загружены/слинкованы в единственном экземпляре. 2) Вот вам и объяснение того почему минимальные .NET приложения типа "Здравствуй Мир!" используют так много памяти (3.8 мегабайтов для минимального консольного и 8 мегабайтов для минимального оконного) — они просто содержат в себе копии всех системных/библиотечных модулей, чего не было бы если бы сама .NET была модульной! А что если системные/библиотечные модули будут требовать не 4-8 мегабайтов, а 100-200 мегабайтов? Расширяемой модульной системе это безразлично, так как она каждый модуль загружает лишь однажды, а .NET создаст их столько раз сколько приложений их использует! 3) Раз так, то, думается, что и сборщик мусора присутсвует в .NET не в единственном экземпляре (как это должно быть в модульной расширяемой системе), а опять же, во множественном. 11.12.04 02:01: Перенесено из 'Философия программирования' |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Flamer rsdn | http://users.livejournal.com/_flamer_/ |
| Дата: | 02.12.04 09:21 | |
| Оценка: | 17 (6) +5 ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: [] До конца не дочитал, силы не хватило. Налицо полный бред и полное непонимание принципов и организации работы Dynamic Link Library. |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 02.12.04 09:28 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Скомпилировал M1.dll, A1.exe, A2.exe и положил их троих в один и тот же каталог. Запустил A1.exe и A2.exe, каждый из них вывел один и тот же ответ M1.Var.X = 1. То есть каждый из "модулей" A1 и A2 работает со своим экземпляром "модуля" M1, а вовсе не с одним единственным как это должно быть в модульной расширяемой системе. Вы бы хоть Дж. Рихтера на досуге почитали. Познали бы очень много относительно принципов работы Dynamic Link Library. Например, вот такое откровение: 1) любая dll разделяется всеми использующими её процессами, таким образом её код в физической памяти присутсвует в единственном экземпляре; 2) память, используемая dll для чтения и записи по-умолчанию управляется по принципу Copy-on-write, пока dll только читает из памяти, она (память) разделяется всеми процессами, как только dll пытается записать в память, процесс получает свою копию данных (НЕ КОДА DLL!!!); 3) если надо, то можно расшарить память dll между всеми процессами... Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 09:31 | |
| Оценка: | -8 ![]() | |
| Здравствуйте, Flamer, Вы писали: F>До конца не дочитал, силы не хватило. Налицо полный бред и полное непонимание принципов и организации работы Dynamic Link Library. Коротко, чтобы хватило сил дочитать: В модульной расширяемой системе переменная M1.X существует в единственном экземпляре, в то время как в .NET экземпляров этой переменной будет столько сколько приложений, отсюда вывод — сама по себе .NET не является модульной расширяемой системой. И где же бред? |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 02.12.04 09:32 | |
| Оценка: | 1 (1) -2 ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: Сударь, кончайте позорить нижегородцев регулярно неся какую-то околесицу на форуме! Я вам говорю это на тех правах, что я сам родился и вырос в Нижнем Новгороде, но волею судеб живу в Новосибирске... Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 02.12.04 09:34 |
| Здравствуйте, Сергей Губанов, Вы писали: F>>До конца не дочитал, силы не хватило. Налицо полный бред и полное непонимание принципов и организации работы Dynamic Link Library. СГ>Коротко, чтобы хватило сил дочитать: СГ>В модульной расширяемой системе переменная M1.X существует в единственном экземпляре, в то время как в .NET экземпляров этой переменной будет столько сколько приложений, отсюда вывод — сама по себе .NET не является модульной расширяемой системой. СГ>И где же бред? В непонимании... можно сделать так, чтобы M1.X существовало в единственном экземпляре, но поскольку обычно это нафиг не нужно, по умолчанию сделано наоборот. Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 09:36 | |
| Оценка: | ![]() | |
| Здравствуйте, Mr. None, Вы писали: MN> ...если надо, то можно расшарить память dll между всеми процессами... Естественно надо! Почему же этого не сделано в .NET? Почему каждый экземпляр минимального оконного приложения отъедает по 8 мегабайтов памяти? Запустил десяток минимальных приложений "Зравстуй Мир!", а память то и кончилась... |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 02.12.04 09:39 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Mr. None, Вы писали: MN>> ...если надо, то можно расшарить память dll между всеми процессами... СГ>Естественно надо! Почему же этого не сделано в .NET? Почему каждый экземпляр минимального оконного приложения отъедает по 8 мегабайтов памяти? Запустил десяток минимальных приложений "Зравстуй Мир!", а память то и кончилась... Если вам это надо, то берёте и компилируете со специальными параметрами — какие навскидку не вспомню, потому что за всю мою практику мне это было нужно один раз — чисто из спортивного интереса. Если интересно почитайте в Рихтере что где и как надо выставить. Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Lloyd | |
| Дата: | 02.12.04 09:39 | |
| Оценка: | ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: Ты гений!!! ![]() Lloyd |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 02.12.04 09:43 | |
| Оценка: | +1 | |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Kh_Oleg | http://kholeg.spaces.live.com |
| Дата: | 02.12.04 09:54 | |
| Оценка: | 19 (2) ![]() | |
| Здравствуйте, Mr. None, Вы писали: СГ>>Скомпилировал M1.dll, A1.exe, A2.exe и положил их троих в один и тот же каталог. Запустил A1.exe и A2.exe, каждый из них вывел один и тот же ответ M1.Var.X = 1. То есть каждый из "модулей" A1 и A2 работает со своим экземпляром "модуля" M1, а вовсе не с одним единственным как это должно быть в модульной расширяемой системе. MN>Вы бы хоть Дж. Рихтера на досуге почитали. Познали бы очень много относительно принципов работы Dynamic Link Library. Например, вот такое откровение: MN>1) любая dll разделяется всеми использующими её процессами, таким образом её код в физической памяти присутсвует в единственном экземпляре; MN>2) память, используемая dll для чтения и записи по-умолчанию управляется по принципу Copy-on-write, пока dll только читает из памяти, она (память) разделяется всеми процессами, как только dll пытается записать в память, процесс получает свою копию данных (НЕ КОДА DLL!!!); MN>3) если надо, то можно расшарить память dll между всеми процессами... Принципы работы Dynamic Link Library здесь ни при чем. Сергей просто не понимает, что при старте каждого нового .NET приложения для него создается своя .NET Environment. Вот внутри нее и разделяются все сборки (но только для одного приложения Так что это не .NET немодульная, а Windows. Олег. | |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 10:23 |
| Здравствуйте, Sinclair, Вы писали: S> ..нет никакой "всей системы .Net". Каждое приложение .Net и представляет собой независимую систему. О как! Я всего лишь сказал, что сама система .Net не является расширяемой модульной системой, а оказывается она никакой не является потому что ее нет. Сурово, однако... На такой исход даже не расчитывал... |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 10:28 | |
| Оценка: | ![]() | |
| Здравствуйте, Kh_Oleg, Вы писали: K_O> Сергей просто не понимает, что при старте каждого нового .NET приложения для него создается своя .NET Environment. K_O>Так что это не .NET немодульная, а Windows. А, теперь ясно. Я-то думал .NET Environment сделана по взрослому — одна на всех, а оказывается у каждого своя... |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 02.12.04 10:41 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Выводы СГ>1) Сама .NET не является модульной системой. Модульной системой является каждое конкретное .NET приложение, в рамках которого модули загружены/слинкованы в единственном экземпляре. Ну начнем с того, что нет никакой "самой .НЕТ". Каждое приложение запущенное под .нет имеет свою отдельную песочницу и само собой что между этими приложениями длл-на не разделяется по данным. Но мне вот просто интересно как Компонентная Система Сергея Губанова отработала бы такую ситуаху. Есть компоенент, который может обладать некоторыми сложными состояниями (например компилятор). И есть апликуха — например среда разработки — которая этот компонент использует. Запустили одну среду открыли прожект и запустили на длительную компиляцию, в ходе которой ясен перец состояние компонента постоянно меняется. Потом мы замахались ждадть покатам все скомпилится и параллельно запустили второй экземпляр среды и запустили на компиляцию второй прожект. И вот тут возникает вопрос — в каком состоянии компонент-компилятор начнет обрабатывать данные из второго прожекта? А из первого после обработки некоторой части второго? Удачи тебе, браток! | |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 02.12.04 10:50 | |
| Оценка: | ![]() | |
| Здравствуйте, Glоbus, Вы писали: G>Но мне вот просто интересно как Компонентная Система Сергея Губанова отработала бы такую ситуаху. Есть компоенент, который может обладать некоторыми сложными состояниями (например компилятор). И есть апликуха — например среда разработки — которая этот компонент использует. Запустили одну среду открыли прожект и запустили на длительную компиляцию, в ходе которой ясен перец состояние компонента постоянно меняется. Потом мы замахались ждадть покатам все скомпилится и параллельно запустили второй экземпляр среды и запустили на компиляцию второй прожект. И вот тут возникает вопрос — в каком состоянии компонент-компилятор начнет обрабатывать данные из второго прожекта? А из первого после обработки некоторой части второго? Да какая разница... Главное что это будет КОМПОНЕНТНЫЙ КОМПИЛЯТОР!!! Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 02.12.04 11:03 | |
| Оценка: | 17 (3) +3 ![]() | |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | a | |
| Дата: | 02.12.04 11:04 | |
| Оценка: | 3 (1) ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Никогда раньше не работал с .NET, но слышал что она является компонентной/модульной. Вчера решил проверить В свою очередь, со всей ответственностью исследователя сферическо-кубических коней в вакууме и в прочих средах с нелинейными характеристиками, заявляю — не только компонентность .NET шита белыми нитками — но и факт существования меня с Вами — также является шитьём белыми нитками. А теперь, пожалуйста — пройдёмте в палату... |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 11:09 |
| Здравствуйте, Glоbus, Вы писали: G> Есть компоенент, который может обладать некоторыми сложными состояниями (например компилятор). И есть апликуха — например среда разработки — которая этот компонент использует. Запустили одну среду открыли прожект и запустили на длительную компиляцию, в ходе которой ясен перец состояние компонента постоянно меняется. Потом мы замахались ждадть покатам все скомпилится и параллельно запустили второй экземпляр среды и запустили на компиляцию второй прожект. И вот тут возникает вопрос — в каком состоянии компонент-компилятор начнет обрабатывать данные из второго прожекта? А из первого после обработки некоторой части второго?
Переменная Compillers.dir — существует в единственном экземпляре (и доступна только для чтения "-") на всю модульную расширяемую операционную систему. Когда какому-то другому модулю понадобился еще один компилятор, то он делает так:
compiller — локальная объектная переменная текущего модуля. Переменная Compillers.dir играет роль фабрики объектов Compillers.Compiller. |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 02.12.04 11:16 |
| Здравствуйте, Сергей Губанов, Вы писали: [skipped] А на кой ляд программе знать что есть список компиляторов и создавать свой компилятор? В чём крутость "единственности" этого списка? |
| Re[4]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 11:29 | |
| Оценка: | -1 ![]() | |
| Здравствуйте, Курилка, Вы писали: К>Здравствуйте, Сергей Губанов, Вы писали: К>[skipped] К>А на кой ляд программе знать что есть список компиляторов и создавать свой компилятор? К>В чём крутость "единственности" этого списка? Есть такой паттерн проектирования, Фабрика называется. Например, есть участок кода, который хочет самостоятельно создавать объекты Compillers.Compiller в неограниченном количестве, но сам их делать не умеет, поэтому ему нужно дать фабрику
Но фабрику ему можно дать как стандартную
так и самодельную
где MyCompillers.myDir — переменная типа являющегося расширением типа Compillers.Directory (то бишь класс-потомок). |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 02.12.04 12:15 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Курилка, Вы писали: К>>Здравствуйте, Сергей Губанов, Вы писали: К>>[skipped] Андрей, ты за кого меня держишь? Про фабрики думаешь я в перв. раз слышу? Ты на вопросы отвечать теперь принципиально не будешь? Как синклер сказал — тебя посылать также как тех с библиями? |
| Re[6]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 12:34 |
| Здравствуйте, Курилка, Вы писали: К>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Здравствуйте, Курилка, Вы писали: К>>>Здравствуйте, Сергей Губанов, Вы писали: К>>>[skipped] К>Андрей, ты за кого меня держишь? К>Про фабрики думаешь я в перв. раз слышу? К>Ты на вопросы отвечать теперь принципиально не будешь? К>Как синклер сказал — тебя посылать также как тех с библиями? Я не Андрей, а Сергей. К> А на кой ляд программе знать что есть список компиляторов и создавать свой компилятор? Переменная dir — это фабрика стандартных компиляторов из примера Globus, единственный способ создавать компиляторы. Зачем нужны именно компиляторы я понятия не имею, их, в качестве примера, привел Globus. > В чём крутость "единственности" этого списка? Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. Мне эти компиляторы тоже как-то не особо..., лучше вот такой пример:
Переменная Models.factory, будучи синглетоном, существует в единственном экземпляре на всю модульную расширяемую операционную систему. |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 02.12.04 12:42 | |
| Оценка: | 2 (2) | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. Угу — один на весь процесс, использующий этот модуль... И снова один, но другой один, на другой процесс, снова использующий этот же модуль... и они оба одни, из одного модуля, но другие, потому что в разных процессах. Вы уж извините, но как программист-практик (а не физик-теоретик) я не вижу большой практической ценности в том, чтобы синглтон был один на все процессы, использующие его... то есть настолько большой, чтобы это поведение было по-умолчанию... я конечно могу ошибаться, я не к.ф-м.н, а всего лишь маааленький такой магистр прикладной математики, но думаю со мной согласиться большинство участников этого форума, или по крайней мере этой дискуссии... так что вы очень сильно не обижайтесь... ок? Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 02.12.04 12:44 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Я не Андрей, а Сергей. Извини СГ>Переменная Models.factory, будучи синглетоном, существует в единственном экземпляре на всю модульную расширяемую операционную систему. Блин, ну дак ты о модульности чего говоришь-то? Тебе уже не один раз объяснили, что .нет сейчас не есть ОС, так что не надо говорить о противоположном |
| Re[4]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 12:44 |
| Здравствуйте, Sinclair, Вы писали: S> А на вопросы ты принципиально не отвечаешь? Специально отвечаю на вопросы. S> Ты что думаешь, что каждый процесс в Windows держит свою отдельную копию kernel32.dll? Нет не думаю. S> Во-вторых, нет никакой "всей системы .Net". Каждое приложение .Net и представляет собой независимую систему. И нет никакой причины критиковать такую организацию. Если я запущу несколько копий черного коробка на своей машине, то его модульность тоже станет шитой белыми нитками? Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям Оберон систем запущенных независимо друг от друга. |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 12:48 |
| Здравствуйте, Mr. None, Вы писали: MN>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. MN>Угу — один на весь процесс, использующий этот модуль... И снова один, но другой один, на другой процесс, снова использующий этот же модуль... и они оба одни, из одного модуля, но другие, потому что в разных процессах. Вот из-за этого и получается, что каждое минимальное .NET приложение имеет размер в несколько мегабайтов. Не экономно, однако... |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 02.12.04 13:15 | |
| Оценка: | ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: >> В чём крутость "единственности" этого списка? СГ>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. А как насчёт неожиданных эффектов влияния процессов друг на друга? ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 02.12.04 13:22 | |
| Оценка: | ![]() | |
| Здравствуйте, Геннадий Васильев, Вы писали: ГВ>Здравствуйте, Сергей Губанов, Вы писали: >>> В чём крутость "единственности" этого списка? СГ>>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. ГВ>А как насчёт неожиданных эффектов влияния процессов друг на друга? Какие эффекты, ген? Код на Обероне не может быть ошибочным он работает всегда идеально |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Геннадий Васильев | http://www.livejournal.com/users/gesha_x |
| Дата: | 02.12.04 13:29 | |
| Оценка: | +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>>>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. MN>>Угу — один на весь процесс, использующий этот модуль... И снова один, но другой один, на другой процесс, снова использующий этот же модуль... и они оба одни, из одного модуля, но другие, потому что в разных процессах. СГ>Вот из-за этого и получается, что каждое минимальное .NET приложение имеет размер в несколько мегабайтов. Не экономно, однако... Ну ты нашёл где это сказать! Сейчас тебе быстро докажут, что проще добавить 512M памяти, чем переделвать софт. И кстати, будут правы... ... << RSDN@Home 1.1.3 stable >> Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн | P.S.: Винодельческие провинции — это есть рулез! |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 02.12.04 14:00 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Переменная Compillers.dir играет роль фабрики объектов Compillers.Compiller. Волшебно. А вот теперь зацени, что в обычной длл-не всей этой порнографии не надо делать. То ест ькак минимум не нужно плоджить такую сущность как фабрика классов. Удачи тебе, браток! | |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 02.12.04 14:02 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Есть такой паттерн проектирования, Фабрика называется. [ботва порезана] Старик Я не понимаю — то есть это что — ради того чтобы просто применить фабрику классов? Ты вроде как бы путаешь цели и средства Удачи тебе, браток! | |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 02.12.04 14:06 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Mr. None, Вы писали: MN>>Здравствуйте, Сергей Губанов, Вы писали: СГ>>>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. MN>>Угу — один на весь процесс, использующий этот модуль... И снова один, но другой один, на другой процесс, снова использующий этот же модуль... и они оба одни, из одного модуля, но другие, потому что в разных процессах. СГ>Вот из-за этого и получается, что каждое минимальное .NET приложение имеет размер в несколько мегабайтов. Не экономно, однако... Да щас много чего неэкономичного — сама идея вирт. машины как прослойки между байт-кодом и целевой машиной это уже есть потеря в памяти и скорости. Но за универсальность, ради которой эти вирт. машины делаются, надо чем-то платить. Но то что ты тут пишешь про компонентность — это извини просто ботва Удачи тебе, браток! | |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 02.12.04 14:28 | |
| Оценка: | +2 | |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | eugals | http://inffront.com/ |
| Дата: | 02.12.04 14:31 | |
| Оценка: | ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям Оберон систем запущенных независимо друг от друга. 1. Ага, и из всего этого каким-то образом следует, что "Компонентность .NET шита белыми нитками". Железная логика. 2. Я вот тоже раньше думал, что Оберон-система в каком-то смысле эквивалентна .NET приложению, а теперь оказалось, что она эквивалентна вообще всем виндовым приложениям запущенным зависимо друг от друга (если упадет одно — упадёт всё). И наступило мне прозрение, что это есть хорошо и хорошо весьма ... << RSDN@Home 1.1.4 beta 3 rev. 215>> |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 14:43 |
| Здравствуйте, Mr. None, Вы писали: MN>...я конечно могу ошибаться, я не к.ф-м.н, а всего лишь маааленький такой магистр прикладной математики... Я тоже могу ошибаться. Тем более что степень к.ф-м.н по теоретической физике тут, как бы, в пролете. В программисты я переквалифицировался всего немногим более двух лет назад, так что сейчас нахожусь, быть может где-то на уровне третьекурсника по информатике. |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 02.12.04 14:50 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. Кстати, мне было интересно в свое время почитать вот этот топик Автор: A_Gura . Там есть пара мыслей насчет "крутости" singleton-ов.Дата: 04.10.04 RSDN@Home 1.1.4 beta 3 r233, играет silent |
| Re[6]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 14:53 |
| Здравствуйте, Glоbus, Вы писали: G>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Есть такой паттерн проектирования, Фабрика называется. G>[ботва порезана] G>Старик G>Я не понимаю — то есть это что — ради того чтобы просто применить фабрику классов? Ты вроде как бы путаешь цели и средства Во-первых, фабрику я привел просто в качестве примера (т.е. не для нее одной это надо). Во-вторых, почему Вы думаете что я путаю цели и средства? Мне кажется, что вполне логично/понятно/дешевле/экономнее иметь переменные каждого модуля в единственном экземпляре вместо того чтобы клонировать эти переменные для каждого процесса. Аналогично, логично/понятно/дешевле иметь всего одно адресное пространство на всю операционку, один сборщик мусора и одну среду исполнения программ. Вместо того чтобы создавать копии всего этого добра для каждой отдельной программы. Эффективность такой системы будет в разы больше чем системы использующей процессы. |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | SchweinDeBurg | http://zarezky.spb.ru/ |
| Дата: | 02.12.04 14:55 | |
| Оценка: | +2 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Аналогично, логично/понятно/дешевле иметь всего одно адресное пространство на всю операционку, один сборщик мусора и одну среду исполнения программ. Вместо того чтобы создавать копии всего этого добра для каждой отдельной программы. Эффективность такой системы будет в разы больше чем системы использующей процессы. А мы-то, грешные, как радовались полноценному Win32 в NT... [ posted via RSDN@Home 1.1.4 beta 3 r240 ] - Искренне ваш, Поросенок Пафнутий ~ ICQ#116846877 | In Windows, there’s always a catch… © Paul DiLascia |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 02.12.04 15:11 | |
| Оценка: | ![]() | |
| Здравствуйте, WFrag, Вы писали: WF>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. WF>Кстати, мне было интересно в свое время почитать вот этот топик Автор: A_Gura . Там есть пара мыслей насчет "крутости" singleton-ов.Дата: 04.10.04 Да, все верно, синглетоны есть зло, но в то же самое время фабрика есть синглетон. Тут действует простое логическое рассуждение: 1. Допустим фабрика не синглетон. 2. Тогда как мы будем создавать саму фабрику? 3. Саму фабрику мы, в таком случае, будем создавать с помощью другой фабрики. Эдакой фабрики фабрик. 4. А откуда мы возьмем фабрику фабрик? 5. Фабрику фабрик мы создадим на фабрике всех фабрик-фабрик. 6. А дальше???????? Фабрика-фабрик-фабрик-фабрик... 7. Нет уж, пускай изначальная фабрика (ну или, на худой конец, фабрика-фабрик) все-таки будет синглетоном. Кстати, пример с фабрикой:
как я понимаю, злом не является. Это потому, что реальный (динамический) тип переменной VAR factory: Factory; модулем Models не экспортируется! Factory — абстрактный тип, а о конкретном типе глобальной переменной factory: Factory никто кроме самого модуля Models не знает! |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 02.12.04 15:51 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Аналогично, логично/понятно/дешевле иметь всего одно адресное пространство на всю операционку, один сборщик мусора и одну среду исполнения программ. Вместо того чтобы создавать копии всего этого добра для каждой отдельной программы. Эффективность такой системы будет в разы больше чем системы использующей процессы. А стабильность? По принципу — "Раз уж помирать, то всем вместе"? ... << RSDN@Home 1.1.4 beta 3 rev. 231>> |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | bkat | |
| Дата: | 02.12.04 21:18 | |
| Оценка: | ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Glоbus, Вы писали: G>>Здравствуйте, Сергей Губанов, Вы писали: СГ>>>Есть такой паттерн проектирования, Фабрика называется. G>>[ботва порезана] G>>Старик G>>Я не понимаю — то есть это что — ради того чтобы просто применить фабрику классов? Ты вроде как бы путаешь цели и средства СГ>Во-первых, фабрику я привел просто в качестве примера (т.е. не для нее одной это надо). СГ>Во-вторых, почему Вы думаете что я путаю цели и средства? Мне кажется, что вполне логично/понятно/дешевле/экономнее иметь переменные каждого модуля в единственном экземпляре вместо того чтобы клонировать эти переменные для каждого процесса. СГ>Аналогично, логично/понятно/дешевле иметь всего одно адресное пространство на всю операционку, один сборщик мусора и одну среду исполнения программ. Вместо того чтобы создавать копии всего этого добра для каждой отдельной программы. Эффективность такой системы будет в разы больше чем системы использующей процессы. Дак чего уж там мелочиться. Надо твои принципы модульности вообще на все компьютеры распространить. Есть же еще и всякие распределенные приложения, в которых разные куски на разных машинах крутятся. И везде все копируется и дублируется. Неэкономно блин. А вот был бы .NET истинно модульной системой, то было бы достаточно ОДНОЙ копии на одном компьютере и этой единственной копией все бы пользовались. Представляешь какие перспективы открываются |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | hrg | |
| Дата: | 02.12.04 22:57 |
| Сергей Губанов -> Компонентность .NET шита белыми нитками <skipped with inexpressible brutality> "Товарищи! Тигру в клетке не додают мяса!"(с) сами знаете кто И что следует из этих выводов? Что Оберон — единственно идеологическое верное решение для истиных арийцев? <!-- Yury Kopyl aka hrg | Гордость мешает доходам! --> Posted via RSDN NNTP Server 1.9 delta |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | hrg | |
| Дата: | 02.12.04 23:14 | |
| Оценка: | ![]() | |
| Геннадий Васильев -> Re[9]: Компонентность .NET шита белыми нитками СГ>>Вот из-за этого и получается, что каждое минимальное .NET приложение СГ>>имеет размер в несколько мегабайтов. Не экономно, однако... ГВ> Ну ты нашёл где это сказать! Сейчас тебе быстро докажут, что проще ГВ> добавить 512M памяти, чем переделвать софт. И кстати, будут правы... Йа, йа! Герр офицерр понимает толк в извращениях! <!-- Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист --> Posted via RSDN NNTP Server 1.9 delta |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 01:17 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Да, все верно, синглетоны есть зло, но в то же самое время фабрика есть синглетон. Тут действует простое логическое рассуждение: СГ>1. Допустим фабрика не синглетон. СГ>2. Тогда как мы будем создавать саму фабрику? СГ>3. Саму фабрику мы, в таком случае, будем создавать с помощью другой фабрики. Эдакой фабрики фабрик. СГ>4. А откуда мы возьмем фабрику фабрик? СГ>5. Фабрику фабрик мы создадим на фабрике всех фабрик-фабрик. СГ>6. А дальше???????? Фабрика-фабрик-фабрик-фабрик... СГ>7. Нет уж, пускай изначальная фабрика (ну или, на худой конец, фабрика-фабрик) все-таки будет синглетоном. Я же не зря ссылку-то дал СГ>как я понимаю, злом не является. Это потому, что реальный (динамический) тип переменной VAR factory: Factory; модулем Models не экспортируется! Factory — абстрактный тип, а о конкретном типе глобальной переменной factory: Factory никто кроме самого модуля Models не знает! Нет. Является. Привязываясь к фабрике твой компонент ты привязываешься к конкретному способу получения сервиса. Если же этот сервис впоследствии нужно будет получать другим способом, то придется переписывать клиентский код. RSDN@Home 1.1.4 beta 3 r233, играет silent |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 03:46 |
| Здравствуйте, WFrag, Мы писали: WF>Нет. Является. Привязываясь к фабрике твой компонент ты привязываешься к конкретному способу получения сервиса. Если же этот сервис впоследствии нужно будет получать другим способом, то придется переписывать клиентский код. Вот, кстати, ровно сейчас натолкнулся на такие грабли. Есть некий компонент. Использует сервис локализации (ResourceBundle в Java). Проблема в том, что получает он этот сервис через синглетон, и все бы хорошо, но я хочу использовать его в другом контексте, где этот синглетон работает неправильно. Получается, компонент жестко забит на один контекст и переиспользовать его в новом контексте уже не получается. А заменить синглетон своим тоже нельзя. Он уже есть, просто работает в новом контексте неправильно. Если бы этот компонент использовал технику IoC или хотя бы ServiceLocator, проблем бы не было вообще. Я бы его сконфигурировал нужным сервисом или механизмом получения сервиса (фабрикой) и все бы замечательно работало. Ан нет. Вывод: Singleton-ы зло |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 04:26 |
| Здравствуйте, Mamut, Вы писали: К>>Какие эффекты, ген? К>>Код на Обероне не может быть ошибочным он работает всегда идеально M>Надо добавить, что и программисты, пишущие на Обероне, тоже никогда не ошибаются Им великий и ужасный Оберон не даёт ошибаться! Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 04:50 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Во-вторых, почему Вы думаете что я путаю цели и средства? Мне кажется, что вполне логично/понятно/дешевле/экономнее иметь переменные каждого модуля в единственном экземпляре вместо того чтобы клонировать эти переменные для каждого процесса. Всё уходим от правил спаривания сферических коней в вакууме. Спускаемся на землю... Вот есть в стандартной библиотеки C++ такая функция strtok — замечательная функция, она разбивает строку на токены, и ей очень многие пользуются (оставим в стороне полемику о том, что есть другие средства и что ей лучше не пользоваться — всё равно пользуются, потому что она есть и проста в использовании). И всё бы хорошо, но есть у неё одно "свойство", чтобы разобрать одну строку на токены эту функцию надо вызывать несколько раз, и в своей работе она использует глобальную переменную для сохранения промежуточного результата (эта функция появилась ещё в pure C, поэтому так коряво). И вот если эту функцию вызвать одновременно из 2 потоков одного процесса — придёт к вам абзац, потому как глобальная переменная одна и её одновременно осчастливливают разными значениями. Но этой проблемы можно избежать, если жётско контролировать вызовы данной функции из разных потоков — синхронизировать доступ или посто запрещать вызов из 2-ух и более потоков. А теперь представьте себе, что эта переменная будет одна на все процессы... То есть запускаем 2 разные программы от разных поизводителей, которые одновременно вызывают эту функцию... и опа! Тут даже проконтролировать ничего не удасться, разве что договориться всем разработчикам, что только кто-то один их них может использовать эту функцию... Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Дарней | |
| Дата: | 03.12.04 05:14 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>2) Вот вам и объяснение того почему минимальные .NET приложения типа "Здравствуй Мир!" используют так много памяти (3.8 мегабайтов для минимального консольного и 8 мегабайтов для минимального оконного) И пусть себе используют. Если тебе так сильно приспичит запустить много-много процессов одновременно — вместо этого сделай лучше один процесс и множество доменов приложений внутри. Благо, использование управляемого кода это позволяет. И будет тебе щастье Всех излечит, исцелит | добрый Ctrl+Alt+Delete |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 07:03 | |
| Оценка: | ![]() | |
| Здравствуйте, Mr. None, Вы писали: MN>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Во-вторых, почему Вы думаете что я путаю цели и средства? Мне кажется, что вполне логично/понятно/дешевле/экономнее иметь переменные каждого модуля в единственном экземпляре вместо того чтобы клонировать эти переменные для каждого процесса. MN> ... эта функция появилась ещё в pure C, поэтому так коряво ... И вместо того, чтобы исправить эту ошибку, Вы предлагаете использовать эту функцию только на таких операционых системах, которые для каждого приложения создают его собственное адресное пространство. Вот уж тут точно цели и средства несопоставимы! |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 07:04 |
| Здравствуйте, Сантехник, Вы писали: С>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Аналогично, логично/понятно/дешевле иметь всего одно адресное пространство на всю операционку, один сборщик мусора и одну среду исполнения программ. Вместо того чтобы создавать копии всего этого добра для каждой отдельной программы. Эффективность такой системы будет в разы больше чем системы использующей процессы. С>А стабильность? По принципу — "Раз уж помирать, то всем вместе"? В смысле? |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 03.12.04 07:09 |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 07:15 | |
| Оценка: | +2 | |
| Здравствуйте, Сергей Губанов, Вы писали: MN>> ... эта функция появилась ещё в pure C, поэтому так коряво ... СГ>И вместо того, чтобы исправить эту ошибку, Вы предлагаете использовать эту функцию только на таких операционых системах, которые для каждого приложения создают его собственное адресное пространство. Вот уж тут точно цели и средства несопоставимы! То есть вы предлагаете исправить эту ошибку и переписать и протестировать все приложения которые её используют? Ну что же, если это с вашей точки зрения проще — флаг вам в руки... а я пас... Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 07:20 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Сантехник, Вы писали: С>>Здравствуйте, Сергей Губанов, Вы писали: СГ>>>Аналогично, логично/понятно/дешевле иметь всего одно адресное пространство на всю операционку, один сборщик мусора и одну среду исполнения программ. Вместо того чтобы создавать копии всего этого добра для каждой отдельной программы. Эффективность такой системы будет в разы больше чем системы использующей процессы. С>>А стабильность? По принципу — "Раз уж помирать, то всем вместе"? СГ>В смысле? В том смысле, что мы уже имели логичное/понятное/дешевое одно АП на всю операционку в win9x. Что из этого получалось, всем прекрасно известно. Какой-нибудь кривой взглюкнувший модуль, вместо того, чтобы тихо подохнуть у себя в песочнице, разлаживал всю систему. ... << RSDN@Home 1.1.4 beta 3 rev. 231>> |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 07:26 |
| Здравствуйте, WFrag, Вы писали: WF>Нет. Является. Привязываясь к фабрике твой компонент ты привязываешься к конкретному способу получения сервиса. Если же этот сервис впоследствии нужно будет получать другим способом, то придется переписывать клиентский код. Я все это понимаю. Клиентский код должен быть привязан не к глобальной переменной Models.factory, а к самому (абстрактному) типу Models.Factory.
такой код потом можно вызывать либо используя фабрику по умолчанию того же модуля Models:
либо используя какую-либо другую фабрику:
где тип переменной MyModels.myFactory есть расширение типа Models.Factory (потомок). |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 07:42 | |
| Оценка: | +1 | |
| Здравствуйте, WFrag, Вы писали: WF>Вывод: Singleton-ы зло Нет, их просто нужно уметь готовить ... << RSDN@Home 1.1.4 beta 3 rev. 231>> |
| Re[12]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | dshe | |
| Дата: | 03.12.04 07:56 |
| Здравствуйте, Сантехник, Вы писали: С>Здравствуйте, WFrag, Вы писали: WF>>Вывод: Singleton-ы зло С>Нет, их просто нужно уметь готовить К сожалению, их вкусом наслаждаются не только те, кто их готовит. -- | Дмитро |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 07:59 | |
| Оценка: | -1 | |
| Здравствуйте, Сантехник, Вы писали: С>Какой-нибудь кривой взглюкнувший модуль, вместо того, чтобы тихо подохнуть у себя в песочнице, разлаживал всю систему. Дык, сейчас речь идет об "управляемом" коде который не умеет переполнять буфер, неправильно приводить типы, и вообще не знает что такое адрес/адресная арифметика/адресное пространство, а так же работает сборщик мусора... Максимум что может сделать дурной модуль — это испортить свои собственные данные, но испортить чужие данные такой код не может. Так что вся система в целом стабильна. |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Kh_Oleg | http://kholeg.spaces.live.com |
| Дата: | 03.12.04 07:59 |
| Здравствуйте, Mr. None, Вы писали: MN>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Во-вторых, почему Вы думаете что я путаю цели и средства? Мне кажется, что вполне логично/понятно/дешевле/экономнее иметь переменные каждого модуля в единственном экземпляре вместо того чтобы клонировать эти переменные для каждого процесса. MN>Всё уходим от правил спаривания сферических коней в вакууме. Спускаемся на землю... MN>Вот есть в стандартной библиотеки C++ такая функция strtok — замечательная функция, она разбивает строку на токены, и ей очень многие пользуются (оставим в стороне полемику о том, что есть другие средства и что ей лучше не пользоваться — всё равно пользуются, потому что она есть и проста в использовании). И всё бы хорошо, но есть у неё одно "свойство", чтобы разобрать одну строку на токены эту функцию надо вызывать несколько раз, и в своей работе она использует глобальную переменную для сохранения промежуточного результата (эта функция появилась ещё в pure C, поэтому так коряво). И вот если эту функцию вызвать одновременно из 2 потоков одного процесса — придёт к вам абзац, потому как глобальная переменная одна и её одновременно осчастливливают разными значениями. Но этой проблемы можно избежать, если жётско контролировать вызовы данной функции из разных потоков — синхронизировать доступ или посто запрещать вызов из 2-ух и более потоков. А теперь представьте себе, что эта переменная будет одна на все процессы... То есть запускаем 2 разные программы от разных поизводителей, которые одновременно вызывают эту функцию... и опа! Тут даже проконтролировать ничего не удасться, разве что договориться всем разработчикам, что только кто-то один их них может использовать эту функцию... Пример крайне неудачный — про такую функцию надо сразу же забыть и запретить ею пользоваться. Потому как при ТАКОМ side-эффекте этой функцией вообще нельзя пользоваться, если используешь хоть какие-то дополнительные библиотеки (Qt, например). Где гарантия, что эта библиотека в своем коде не использует эту же функцию? Получается, что использование такой функции — это гарантия потенциальной нестабильности программы. Таперь насчет сути дискуссии — тут надо понимать, что вообще без глобальных объектов, которые разделяются всеми процессами, обойтись невозможно, в Windows, между прочим, их тоже полным-полно (я имею в виду объекты ядра, например, или те же файлы). Только надо понимать, любой глобальный объект — штука очень опасная и работать с ней надо аккуратно, через синхронизации. В случае с объектами ядра за этим следит операционная система. А вот как в Оберонах — не знаю. В связи с этим, мне бы хотелось спросить Сергея, а как в Оберон-системах решается вопрос синхронизации при обращении к глобальным переменным модулей из разных потоков? Да и как вообще там обстоит дело с многозадачностью и многопоточностью? Может и не все так плохо... Олег. | |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | bkat | |
| Дата: | 03.12.04 08:19 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Сантехник, Вы писали: С>>Какой-нибудь кривой взглюкнувший модуль, вместо того, чтобы тихо подохнуть у себя в песочнице, разлаживал всю систему. СГ>Дык, сейчас речь идет об "управляемом" коде который не умеет переполнять буфер, неправильно приводить типы, и вообще не знает что такое адрес/адресная арифметика/адресное пространство, а так же работает сборщик мусора... Максимум что может сделать дурной модуль — это испортить свои собственные данные, но испортить чужие данные такой код не может. Так что вся система в целом стабильна. Он может просто неверно функционировать с точки зрения спецификаций. Т.е. спецификациями заявлено одно, а он делает немного иное (ошибка в модуле). Предсказать последствия использования такого модуля будет затруднительно. Побочные эффекты предсказать будет непросто. Ты просто постоянно забываешь, что ошибки — это не только переполнения, некоректная работа с указателями и прочие подобные вещи. В конце концов спецификации модуля могут быть ошибочными. Ошибки в спецификациях — это вообще самые тяжелые ошибки. |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 08:22 |
| Здравствуйте, Kh_Oleg, Вы писали: K_O> В связи с этим, мне бы хотелось спросить Сергея, а как в Оберон-системах решается вопрос синхронизации при обращении к глобальным переменным модулей из разных потоков? Да и как вообще там обстоит дело с многозадачностью и многопоточностью? Может и не все так плохо... В Aos BlueBotle написанной на Active Oberon весь контроль за синхронизацией возложен на runtime system. 1) Есть железо. 2) Поверх железа работает runtime system языка Active Oberon. Система времени исполнения языка Active Oberon включает в себя управление активными объектами (т.е. процессами/потоками), менеджер памяти — сборщик мусора... 3) Вся операционная система целиком написана на Active Oberon и является с головы до пят объектно ориентированной. То есть операционка находится поверх runtime system языка Active Oberon, в то время как, например, в традиционных операционках типа UNIX, Windows все наоборот — там поверх железа работает ядро операционки, а уже поверх ядра работают всякие runtime systems для разных языков программирования... В оригианльном первом Обероне (от 1985), на сколько я знаю, никаких средств для параллельного исполнения предусмотрено не было (может я ошибаюсь?). В BlackBox, поскольку он работает поверх Windows, средства для параллельных вычислений надо получать самому через Win API. А как же еще-то, по другому никак! Как обстоят дела в других Оберон системах/языках я не знаю. Наверное так же как и в других системах/языках — все реализуется через внешние системные библиотеки. |
| Re[13]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 08:22 |
| Здравствуйте, dshe, Вы писали: D>К сожалению, их вкусом наслаждаются не только те, кто их готовит. Если использовать синглтоны в том контексте, в котором описал WFrag Автор: WFrag , то это естественно не есть гут. Но для в определенных случаях, вроде получения сервиса, единого для приложения, типа логгера или экземпляра главного окна, то синглтоны рулят.Дата: 03.12.04 ... << RSDN@Home 1.1.4 beta 3 rev. 231>> |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 08:22 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Дык, сейчас речь идет об "управляемом" коде который не умеет переполнять буфер, неправильно приводить типы, и вообще не знает что такое адрес/адресная арифметика/адресное пространство, а так же работает сборщик мусора... Максимум что может сделать дурной модуль — это испортить свои собственные данные, но испортить чужие данные такой код не может. Так что вся система в целом стабильна. А если код-потребитель зависит от данных дурного модуля? ... << RSDN@Home 1.1.4 beta 3 rev. 231>> |
| Re[12]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 08:24 |
| Здравствуйте, Сантехник, Вы писали: С>А если код-потребитель зависит от данных дурного модуля? Ну, а что Вы предлагаете делать в таком случае? |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 03.12.04 08:42 | |
| Оценка: | ![]() | |
| Здравствуйте, Mr. None, Вы писали: MN>Им великий и ужасный Оберон не даёт ошибаться! А каждого кто ошибся развоплощает на месте! Именно по этому последователей Оберона так мало и они так круты и никогда не ошибаются. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[13]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 08:42 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Ну, а что Вы предлагаете делать в таком случае? Собственно, использовать отдельную копию компонента для каждого модуля. off: Когда у вас в квартире прорывает толчок, соседям снизу плевать почему это произошло, они хотят иметь незалитый потолок. Надеюсь, аналогия понятна? ... << RSDN@Home 1.1.4 beta 3 rev. 231>> |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 08:45 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Я все это понимаю. Клиентский код должен быть привязан не к глобальной переменной Models.factory, а к самому (абстрактному) типу Models.Factory. СГ>
СГ>такой код потом можно вызывать либо используя фабрику по умолчанию того же модуля Models: СГ>
СГ>либо используя какую-либо другую фабрику: СГ>
СГ>где тип переменной MyModels.myFactory есть расширение типа Models.Factory (потомок). О чем и речь. Получаем, что singleton-ы в общем-то и не нужны |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 08:50 |
| Здравствуйте, Сантехник, Вы писали: С>Но для в определенных случаях, вроде получения сервиса, единого для приложения, типа логгера или экземпляра главного окна, то синглтоны рулят. Нет. Как раз про такой случай я и говорю. Логгер — это сервис. Компонент использующий его как правило не заинтересован в способе его получения, ему просто нужен этот сервис. Тогда зачем в этот компонент искусственно вводить эту информацию, информацию о нахождении сервиса (т.е привязывать его к конкретному контексту)? Не лучше ли предоставить эту заботу внешнему компоненту (сборщику, контейнеру, и.т.д)? Но этот как бы идеал. Singleton — некрасивое, но практичное решение. Например, как в случае с тем же логгером. |
| Re[12]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 08:52 |
| Здравствуйте, WolfHound, Вы писали: WH>А каждого кто ошибся развоплощает на месте! Именно по этому последователей Оберона так мало и они так круты и никогда не ошибаются. Оберонистый маг развоплощается на месте не от того что ошибся (все ошибаются), а от того что помыслил намеренно написать стремный код, а потом наплевать на него. |
| Re[12]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 09:07 |
| Здравствуйте, WFrag, Вы писали: WF> Зачем в таком случае делать фабрику с глобальной областью видимости, если мы ее все равно параметром передаем? Или я что-то не так понял (не силен в понятиях Оберона)? А затем, что откуда ее взять-то тогда? Внутри модуля Models определен экспортируемый (публичный) тип абстрактной фабрики, а также не экспортируемый (приватный) тип конкретной фабрики. Кроме модуля Models об этом приватном типе конкретной фабрики никто не знает. Как модуль Models должен выдать внешнему миру экземпляр конкретной фабрики? Он может это сделать либо так:
либо так:
Если объект factory большой и редко используется, то второй вариант предпочтительнее. Если объект factory гарантированно кем-то используется, то предпочтительнее первый вариант, так как более эффективен по скорости исполнения. |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 03.12.04 09:07 | |
| Оценка: | 6 (1) | |
| Здравствуйте, Сергей Губанов, Вы писали: С>>Какой-нибудь кривой взглюкнувший модуль, вместо того, чтобы тихо подохнуть у себя в песочнице, разлаживал всю систему. СГ>Дык, сейчас речь идет об "управляемом" коде который не умеет переполнять буфер, неправильно приводить типы, и вообще не знает что такое адрес/адресная арифметика/адресное пространство, а так же работает сборщик мусора... Максимум что может сделать дурной модуль — это испортить свои собственные данные, но испортить чужие данные такой код не может. Так что вся система в целом стабильна. Фатальное поведение — это не только расстрел памяти. Пусть, например, у тебя есть модуль, которым пользуются много клиентов. И в нём — редкая логическая ошибка, блокирующая его наглухо...
Перекуём баги на фичи! |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 09:08 |
| Здравствуйте, Сантехник, Вы писали: С>Собственно, использовать отдельную копию компонента для каждого модуля. А смысл? Каждая копия тоже будет дурная. |
| Re[13]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 03.12.04 09:09 | |
| Оценка: | +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: С>>А если код-потребитель зависит от данных дурного модуля? СГ>Ну, а что Вы предлагаете делать в таком случае? Как что? Изоляция процессов. Перекуём баги на фичи! |
| Re[13]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 03.12.04 09:11 |
| Здравствуйте, Сергей Губанов, Вы писали: Ну вот ты и попался... СГ>Оберонистый маг развоплощается на месте не от того что ошибся (все ошибаются), Те в программах написаных на обероне есть ошибки... А как следствие нет никакой сверхнадежности... СГ>а от того что помыслил намеренно написать стремный код, а потом наплевать на него. Я думаю это должно было звучать так "а от того что намерено написал стремный код, и оставил его в программе" поверь мне это замучает любого хорошего программиста вне зависимости от языка на котором он пишет. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 09:24 |
| Здравствуйте, WFrag, Вы писали: WF>Нет. Как раз про такой случай я и говорю. Логгер — это сервис. Компонент использующий его как правило не заинтересован в способе его получения, ему просто нужен этот сервис. Тогда зачем в этот компонент искусственно вводить эту информацию, информацию о нахождении сервиса (т.е привязывать его к конкретному контексту)? Не лучше ли предоставить эту заботу внешнему компоненту (сборщику, контейнеру, и.т.д)? Ок, может я не так выразился. Есть сервис логгера, который должен быть доступен из любой точки моего приложения. Сам сервис синглтоном не является ни в коем случае. Но для доступа к нему есть враппер-синглтон, посредством которого и обеспечивается доступ к логгеру. ... << RSDN@Home 1.1.4 beta 3 rev. 240>> |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 09:24 | |
| Оценка: | +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>А смысл? Каждая копия тоже будет дурная. Компонент может валится только при определенных обстоятельствах. И очень много клиентов могут юзать его, ни разу не создав условий для его падения. А один или несколько клиентов, например, эту ситуацию регулярно создают. И в случае раздельных копий компонента первые продолжают "работать, работать и работать", тогда как при общей копии отдыхают все. ... << RSDN@Home 1.1.4 beta 3 rev. 240>> |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 09:26 |
| Здравствуйте, Kh_Oleg, Вы писали: K_O>Пример крайне неудачный — про такую функцию надо сразу же забыть и запретить ею пользоваться. Потому как при ТАКОМ side-эффекте этой функцией вообще нельзя пользоваться, если используешь хоть какие-то дополнительные библиотеки (Qt, например). Где гарантия, что эта библиотека в своем коде не использует эту же функцию? Получается, что использование такой функции — это гарантия потенциальной нестабильности программы. Отвечу повторным цитированием самого себя: MN>>оставим в стороне полемику о том, что есть другие средства и что ей лучше не пользоваться — всё равно пользуются, потому что она есть и проста в использовании Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 09:38 | |
| Оценка: | +1 | |
| Здравствуйте, Сантехник, Вы писали: D>>К сожалению, их вкусом наслаждаются не только те, кто их готовит. С>Если использовать синглтоны в том контексте, в котором описал WFrag Автор: WFrag , то это естественно не есть гут.Дата: 03.12.04 Абсолютно согласен... Даже молотком надо уметь пользоваться. Синглтон — это не только объект с глобальным доступом, это в первую очередь объект, присутствующий в системе в единственном экземпляре. Например, объект User, выдываемый процессу, когда он регистрируется в системе. Да и объекты с глобальным доступом иногда просто необходимы... Менеджер памяти, например. Вы же не передаёте в new указатель на кучу в которой хотите выделить память? Значит он его где-то берёт — синглтон... Просто так удобнее. Проблема описанная господином WFrag сводится к тому, что тип синглтона определяется жётско один раз и изменить его нельзя. Вот это действительно плохо. Но кто мешает использовать настраиваемые синглтоны? Тип синглтона можно задавать динамически с помощью регистрации Create-функций или статически через параметры шаблона. Или кто мешает вызывающему модулю самому определять тип необходимого синглтона:
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[16]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 09:39 |
| Здравствуйте, Сантехник, Вы писали: С>Ок, может я не так выразился. Есть сервис логгера, который должен быть доступен из любой точки моего приложения. Сам сервис синглтоном не является ни в коем случае. Но для доступа к нему есть враппер-синглтон, посредством которого и обеспечивается доступ к логгеру. Я про это и говорю. Если я правильно понял, используется логгер вот так:
А потом мне захочется раздавать логгер другим способом? Заменить синглетон? А как же другие его пользователи? Если им нужно старое поведение? |
| Re[17]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 09:49 |
| Здравствуйте, WFrag, Вы писали: WF>Здравствуйте, Сантехник, Вы писали: С>>Ок, может я не так выразился. Есть сервис логгера, который должен быть доступен из любой точки моего приложения. Сам сервис синглтоном не является ни в коем случае. Но для доступа к нему есть враппер-синглтон, посредством которого и обеспечивается доступ к логгеру. WF>Я про это и говорю. Если я правильно понял, используется логгер вот так: WF>
WF>А потом мне захочется раздавать логгер другим способом? Заменить синглетон? А как же другие его пользователи? Если им нужно старое поведение? Как раз занят переделыванием логера у себя в проекте, поэтому примкну к дискуссии. 1) Если не сложно опишите пример другого способа раздачи логгера, который бы делал абсолютно невозможным сохранения старого? 2) Чисто философическое рассуждение, в рамках одного модуля нафиг не нужно 2 или 3 логера с разным поведением, поэтому можно смело менять синглтон. Но в любом случае изначально делать его настраиваемым, чтобы в другом модуле можно было прикрутить другое поведение. 3) Если вам так притит вариант с прямым получением логгера от синглтона, то пожалуйста такой вариант:
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[17]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 03.12.04 09:54 | |
| Оценка: | +1 | |
| Здравствуйте, WFrag, Вы писали: WF>Я про это и говорю. Если я правильно понял, используется логгер вот так: WF>
да WF>А потом мне захочется раздавать логгер другим способом? Заменить синглетон? А как же другие его пользователи? Если им нужно старое поведение? Естественно в контексте, например библиотеки компонентов, использование синглтонов чревато граблями, которые ты описал, потому как ты как автор библитеки не знаешь, кто и каким образом будет использовать ее компоненты. А я имел в виду конечное приложение-потребитель сервиса, исходники которого у тебя на руках, и поведение которого ты можешь свободно изменять. В таком случае синглтоны оправданы, имхо. ... << RSDN@Home 1.1.4 beta 3 rev. 240>> |
| Re[18]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 09:59 |
| Здравствуйте, Mr. None, Вы писали: MN>Как раз занят переделыванием логера у себя в проекте, поэтому примкну к дискуссии. MN>1) Если не сложно опишите пример другого способа раздачи логгера, который бы делал абсолютно невозможным сохранения старого? Эм-м-м. Не совсем понял, но в статье рассматривается один из механизмов (Inversion of Control) + упоминается другой механизм (ServiceLocator). MN>2) Чисто философическое рассуждение, в рамках одного модуля нафиг не нужно 2 или 3 логера с разным поведением, поэтому можно смело менять синглтон. Но в любом случае изначально делать его настраиваемым, чтобы в другом модуле можно было прикрутить другое поведение. Ну вот о том и речь. Чтоб все было гибко и настриваемо. MN>3) Если вам так притит вариант с прямым получением логгера от синглтона, то пожалуйста такой вариант: MN>
Дело не в том, что претит. Дело в том что не хотелось бы привязываться к механизму обнаружения (discovery, что-ли) логгера. Этот вариант так же плох — механизм обнаружения жестко забит. |
| Re[19]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 10:14 | |
| Оценка: | +1 | |
| Здравствуйте, WFrag, Вы писали: MN>>Как раз занят переделыванием логера у себя в проекте, поэтому примкну к дискуссии. MN>>1) Если не сложно опишите пример другого способа раздачи логгера, который бы делал абсолютно невозможным сохранения старого? WF>Эм-м-м. Не совсем понял, но в статье рассматривается один из механизмов (Inversion of Control) + упоминается другой механизм (ServiceLocator). Ок согласен не совсем удачный вопрос. Просто я хотел развить дискуссию и придти к известному тезису: Любая проблема проектирования решается введением ещё одного уровня асбтракции, за исключением проблемы большого числа уровней абстракции. Это я к тому, что если у вас меняется способ раздачи логера, никто не мешает вам оставить старый, но превратить его в фасад для доступа к новому механизму. MN>>2) Чисто философическое рассуждение, в рамках одного модуля нафиг не нужно 2 или 3 логера с разным поведением, поэтому можно смело менять синглтон. Но в любом случае изначально делать его настраиваемым, чтобы в другом модуле можно было прикрутить другое поведение. WF>Ну вот о том и речь. Чтоб все было гибко и настриваемо. Да запросто может быть синглтон гибким и настраиваемым:
Есть ещё вариант без шаблонов с регистрацией Create-функций — динамическое определение типа синглтона, его не описываю, любой студент 5-ого курса специализированного факультета может его сообразить MN>>3) Если вам так притит вариант с прямым получением логгера от синглтона, то пожалуйста такой вариант: MN>>
WF>Дело не в том, что претит. Дело в том что не хотелось бы привязываться к механизму обнаружения (discovery, что-ли) логгера. Этот вариант так же плох — механизм обнаружения жестко забит. А что ещё вы предлагаете? Всегда передавать дополнительный параметр? Рука не устанет Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[4]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Tom rsdn | http://www.RSDN.ru |
| Дата: | 03.12.04 10:24 | |
| Оценка: | +1 ![]() | |
| СГ>А, теперь ясно. Я-то думал .NET Environment сделана по взрослому — одна на всех, а оказывается у каждого своя... Нееее. Совсем не повзрослому. По детски я бы даже сказал. Народная мудрось | всем все никому ничего(с). |
| Re[20]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 10:42 |
| Здравствуйте, Mr. None, Вы писали: MN>Ок согласен не совсем удачный вопрос. Просто я хотел развить дискуссию и придти к известному тезису: MN>Любая проблема проектирования решается введением ещё одного уровня асбтракции, за исключением проблемы большого числа уровней абстракции. MN>Это я к тому, что если у вас меняется способ раздачи логера, никто не мешает вам оставить старый, но превратить его в фасад для доступа к новому механизму. Хм. Тут немного другой вопрос. Проблема не в уровнях абстракции, а в том, что компонент несет лишнюю ответственность (обнаружение сервиса), которая мешает при переносе компонента в другой контекст. Причем еще раз повторяю, эта функциональность компоненту несущественна — ему в общем-то пофиг, откуда взялся сервис. Вот собственно и хочется выразить этот "пофигизм" явно — убрать зависимость компонента от механизма получения сервиса. WF>>Ну вот о том и речь. Чтоб все было гибко и настриваемо. MN>Да запросто может быть синглтон гибким и настраиваемым: MN>
Да, но если у нас уже есть готовый бинарный компонент, тут-то проблема и возникнет. Это первый момент. Во вторых, все кто получают одним образом так и будут получать этим образом, потому как синглетон отличить-то не может, кто у него сервис запрашивает. Собственно, IoC — это вынос механиза получения сервиса наружу. Сам синглетон-то будет настраиваемым, а вот компонент так и останется привязанным к синглетону (т.е к механизму получения сервиса MN>А что ещё вы предлагаете? Всегда передавать дополнительный параметр? Рука не устанет Да, это как раз один из вариантов. Статью читал? |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 03.12.04 11:35 | |
| Оценка: | 10 (2) +3 | |
| Здравствуйте, Mr. None, Вы писали: MN>Здравствуйте, Сергей Губанов, Вы писали: MN>>> ... эта функция появилась ещё в pure C, поэтому так коряво ... СГ>>И вместо того, чтобы исправить эту ошибку, Вы предлагаете использовать эту функцию только на таких операционых системах, которые для каждого приложения создают его собственное адресное пространство. Вот уж тут точно цели и средства несопоставимы! MN>То есть вы предлагаете исправить эту ошибку и переписать и протестировать все приложения которые её используют? Ну что же, если это с вашей точки зрения проще — флаг вам в руки... а я пас... ЗЫ. Еще много дней тому назад я высказал Автор: Mamut гениальную Дата: 11.11.04
и еще Автор: Mamut :Дата: 09.11.04
Во всей системе, насколько бы она ни была модульной, мусоросборочной, процессоразделенной и т.д., обязательно найдется какой-нибудь элемент, ошибка в котором нафиг своротит всю систему. Об этом уже столько раз говорилось! А в ответ — нет, ничего подобного, Оберон (или обероноподобная система) такого не допустит. Причем в ответ на приводимые куски кода обычно отвечается "нет, это неправильные куски кода, никто так не пишет." Так пишут. Так писали. Так будут писать. Причина — в цитатах выше. Ладно, дам еще один пример. Ваша супер-пупер навороченная графическая система зависит от разрешения 800х600 и выше. Ваш же видеодрайвер некорректно определил видеокарточку и выдает только разрешение 115х234, считая себя установленным на хитрый PDA. Ваша система тихо умрет и не сможет даже сообщение никакое вывести на экран. Это — тоже ошибка. Ошибка в драйвере, ошибка в проектировании системы, но — ошибка. Если от этой системы зависят другие приложения, они тоже умрут и даже не пикнут. И никакой Оберон в этом не поможет. Думаете, такие системы никто не пишет? Пишут. Это — поведение некоторых игр для PC (по-моему, таким грешила NFS). Так что давно пора спуститься с небес на землю и понять, что Оберон и модульность — не панацея, а программисты-оберонщики — не безгрешные ангелы, пишущие только правильный код. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> ![]() |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 03.12.04 11:36 |
| Здравствуйте, Дарней, Вы писали: Д>И пусть себе используют. Если тебе так сильно приспичит запустить много-много процессов одновременно — вместо этого сделай лучше один процесс и множество доменов приложений внутри. Благо, использование управляемого кода это позволяет. И будет тебе щастье Не будет. Статические переменные у каждого домена собственные. ... << RSDN@Home 1.1.4 beta 3 rev. 240>> AVK Blog | |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 11:44 | |
| Оценка: | ![]() | |
| Здравствуйте, Mamut, Вы писали: M>Во всей системе, насколько бы она ни была модульной, мусоросборочной, процессоразделенной и т.д., обязательно найдется какой-нибудь элемент, ошибка в котором нафиг своротит всю систему. Об этом уже столько раз говорилось! А в ответ — нет, ничего подобного, Оберон (или обероноподобная система) такого не допустит. Причем в ответ на приводимые куски кода обычно отвечается "нет, это неправильные куски кода, никто так не пишет." Да нет, всё очень просто, я только что понял... Поскольку обще-известно, что любая программа содержит ошибки, а если программа работает правильно, следовательно она содержит чётное число ошибок. Исходя из этого получается, что когда Оберон натыкается на ошибку программиста он добавляет ещё одну ошибку от себя — условие чётности числа ошибок соблюдено и программа работает корректно!!!! УРАА!!!!! Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[21]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 11:52 |
| Здравствуйте, WFrag, Вы писали: MN>>Да запросто может быть синглтон гибким и настраиваемым: MN>>
WF>Да, но если у нас уже есть готовый бинарный компонент, тут-то проблема и возникнет. Это первый момент. Во вторых, все кто получают одним образом так и будут получать этим образом, потому как синглетон отличить-то не может, кто у него сервис запрашивает. Собственно, IoC — это вынос механиза получения сервиса наружу. WF>Сам синглетон-то будет настраиваемым, а вот компонент так и останется привязанным к синглетону (т.е к механизму получения сервиса Это уже проблема криво спроектированного внешнего компонента. На будущее запомните — так проектировать нельзя, а если вам попался такой чужой компонент, вооружитесь паттерном PROXY или FACADE и переделайте его правильно... MN>>А что ещё вы предлагаете? Всегда передавать дополнительный параметр? Рука не устанет WF>Да, это как раз один из вариантов. Статью читал? До конца не дочитал. Но могу сказать по поводу передачи параметров следующее. В системе, в разработке которой я сейчас участвую, порядка 80 разных модулей, порядка 60 мегабайт исходных текстов, число функций не поддаётся исчислению. Если бы указатель на логер передавался в каждую функцию, потому как не известно где он может понадобиться, это был бы полный аут — код был бы так загромождён. И в итоге где-нибудь всё равно забыли бы передать, но в конце концов на самом дне этой иерархии (без указателя) логер понадобился и всё в итоге переделали бы к синглтону... Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[22]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WFrag | |
| Дата: | 03.12.04 12:08 |
| Здравствуйте, Mr. None, Вы писали: MN>Это уже проблема криво спроектированного внешнего компонента. На будущее запомните — так проектировать нельзя, а если вам попался такой чужой компонент, вооружитесь паттерном PROXY или FACADE и переделайте его правильно... Нет. Проблема именно в самом компоненте, а не во внешнем. MN>До конца не дочитал. Но могу сказать по поводу передачи параметров следующее. В системе, в разработке которой я сейчас участвую, порядка 80 разных модулей, порядка 60 мегабайт исходных текстов, число функций не поддаётся исчислению. Если бы указатель на логер передавался в каждую функцию, потому как не известно где он может понадобиться, это был бы полный аут — код был бы так загромождён. И в итоге где-нибудь всё равно забыли бы передать, но в конце концов на самом дне этой иерархии (без указателя) логер понадобился и всё в итоге переделали бы к синглтону... В общем-то да, это и есть ситуация когда синглетон банально более практичен. В статье как часть решения предлагалось использовать "легковесные" контейнеры. На самом деле, интересно было бы посмотреть на решение с помощью IoC при таком объеме кода. |
| Re[22]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 12:29 |
| Здравствуйте, Mr. None, Вы писали: MN>До конца не дочитал. Но могу сказать по поводу передачи параметров следующее. В системе, в разработке которой я сейчас участвую, порядка 80 разных модулей, порядка 60 мегабайт исходных текстов, число функций не поддаётся исчислению. Если бы указатель на логер передавался в каждую функцию, потому как не известно где он может понадобиться, это был бы полный аут — код был бы так загромождён. И в итоге где-нибудь всё равно забыли бы передать, но в конце концов на самом дне этой иерархии (без указателя) логер понадобился и всё в итоге переделали бы к синглтону... Не надо явно передавать!!! Количество таких передач, вообще говоря, может расти квадратично с ростом уровня вложенности — это почти что смерть для программиста. Пусть она сама об этом спросит у своего контекста исполнения! У меня на Дельфи 143 юнита ( ~ 50 тысяч строчек кода) и всего ОДНА единственная глобальная переменная MainForm, но даже о ней никто кроме нее самой не знает. Чистой архитектуры добился за счет механизма агрегирования. MainForm агрегирует Factory, та агрегирует Environment, та агрегирует Log, DocumentContainer, ***Environment и т.д. Всего в дереве агрегации около сотни разных элементов. Когда какому-то объекту что-то нужно такое что он сам делать не умеет, то он запрашивает соответсвующую услугу у своего агрегата — агрегаты есть у всех, кроме MainForm — корневой агрегат. Кстати, сам агрегированный объект понятия не имеет кто конкретно его в данный момент агрегирует, для него он просто IAggregate. Например, захотелось создать новый объект типа INodeView
и известно что его можно создать имея фабрику INodeViewFactory
тогда надо запросить у своего агрегата услугу по интерфейсу INodeViewFactory
Все-все-все объекты у меня реализуют интерфейс IAggregate, вот такой:
Вот вся суть в этой единственной процедуре:
Сначала интерфейс ищется у самого агрегата. Если запрошенный интерфейс самим агрегатом не реализован, то запрос пересылается вверх по уровням агрегации. |
| Re[6]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 12:39 |
| Здравствуйте, Sinclair, Вы писали: S>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям Оберон систем запущенных независимо друг от друга. S>Еще раз, задам основной вопрос: S>Если я запущу несколько копий черного коробка на своей машине, то его компонентность тоже станет шитой белыми нитками? Я же ответил: "Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям..." нескольким копиям запущенных черных коробок. А это просто несколько разных обычных приложений, между собой у них компонентности нет и не было никогда. |
| Re[23]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 13:05 | |
| Оценка: | 1 (1) | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Все-все-все объекты у меня реализуют интерфейс IAggregate, вот такой: СГ>Вот вся суть в этой единственной процедуре: СГ>FUNCTION TAggregate.GetAscentInterface(CONST IID: TGUID; OUT Obj): BOOLEAN; И называется всё это модель COM СГ>Чистой архитектуры добился за счет механизма агрегирования. MainForm агрегирует Factory, та агрегирует Environment, та агрегирует Log, DocumentContainer, ***Environment и т.д. Всего в дереве агрегации около сотни разных элементов. Когда какому-то объекту что-то нужно такое что он сам делать не умеет, то он запрашивает соответсвующую услугу у своего агрегата — агрегаты есть у всех, кроме MainForm — корневой агрегат. Кстати, сам агрегированный объект понятия не имеет кто конкретно его в данный момент агрегирует, для него он просто IAggregate. А ещё я кажись понял, почему вы пару месяцев назад возмущались, почему классы не преобразуются к интерфейсам только на основании сигнатур функций... Не устали часом в этой иерархии агрегирования наследоваться от соответствующих интерфейсов?... Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[24]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 03.12.04 13:27 | |
| Оценка: | ![]() | |
| Здравствуйте, Mr. None, Вы писали: MN>И называется всё это модель COM MN>А ещё я кажись понял, почему вы пару месяцев назад возмущались, почему классы не преобразуются к интерфейсам только на основании сигнатур функций... Не устали часом в этой иерархии агрегирования наследоваться от соответствующих интерфейсов?... Никаким СОМ-ом я не пользовался. Все работает в рамках одного EXE-шника на чисто Дельфийской реализации интерфейсов, которая, кстати и в Kylix такая же, хотя, как известно под Linux COM-а нету. Реализовывать интерфейсы я не устал. А дерево наследования у них, в моем случае, очень короткое:
Наследование классов мне оказалось не нужным (за исключением наследования от класса TAggregate) вместо него мне хватило агрегации. Основная идея заключается не в том что я использовал интерфейсы, а в том что 1) Все-все-все объекты выстроены в дерево агрегации, стало быть у каждого объекта есть 1 агрегат. 2) Когда объекту что-то нужно такое чего он сам не умеет делать, то он спрашивает об этом у своего агрегата. Вместо интерфейсов я с тем же самым успехом мог бы использовать обычную посылку сообщения
|
| Re[25]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 03.12.04 13:31 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Mr. None, Вы писали: MN>>И называется всё это модель COM MN>>А ещё я кажись понял, почему вы пару месяцев назад возмущались, почему классы не преобразуются к интерфейсам только на основании сигнатур функций... Не устали часом в этой иерархии агрегирования наследоваться от соответствующих интерфейсов?... СГ>Никаким СОМ-ом я не пользовался. Не сомневаюсь, иначе у вас как раз и были-бы IUnknown и QueryInterface... Я имел в виду, что то, что вы описали есть не что иное как спецификация COM, примерно как она есть у Microsoft... СГ>Все работает в рамках одного EXE-шника на чисто Дельфийской реализации интерфейсов, которая, кстати и в Kylix такая же, хотя, как известно под Linux COM-а нету. Ну не совсем верно... Конкретно под Linux может и нет, но под некоторые из версий Unix очень даже есть, но это так для информации. Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Дарней | |
| Дата: | 03.12.04 13:36 |
| Здравствуйте, AndrewVK, Вы писали: AVK>Не будет. Статические переменные у каждого домена собственные. ну и что? Я говорил только про минимизацию затрат памяти. Всех излечит, исцелит | добрый Ctrl+Alt+Delete |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 03.12.04 13:45 |
| Здравствуйте, Геннадий Васильев, Вы писали: СГ>>Каждая фабрика всегда singleton. Крутость singleton-а в том что он всегда один. ГВ>А как насчёт неожиданных эффектов влияния процессов друг на друга? Насколько могу судить по литературе (в данном случае, по книгам Вирта), чтобы избежать таких эффектов, в Модуле-2 (и, вероятно, в Оберон-системах) используются модули-мониторы. Хоар |
| Re[4]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 03.12.04 14:04 |
| Здравствуйте, Дарней, Вы писали: Д>ну и что? Я говорил только про минимизацию затрат памяти. GC тоже у каждого домена собственный. Единственное что иногда шарится это результаты работы JIT. ... << RSDN@Home 1.1.4 beta 3 rev. 240>> AVK Blog | |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 03.12.04 14:09 |
| Здравствуйте, Mamut, Вы писали: M>Во всей системе, насколько бы она ни была модульной, мусоросборочной, процессоразделенной и т.д., обязательно найдется какой-нибудь элемент, ошибка в котором нафиг своротит всю систему. Об этом уже столько раз говорилось! А в ответ — нет, ничего подобного, Оберон (или обероноподобная система) такого не допустит. Причем в ответ на приводимые куски кода обычно отвечается "нет, это неправильные куски кода, никто так не пишет." Проблема не только в том, что "какой-нибудь элемент своротит систему". Представим себе, что процесс, прошу прощения, "испортил память" в своем собственном адресном пространстве. Последствия могут быть самые разные: от забавных до ужасных. Решается ли эта проблема с помощью защиты памяти (memory protection)? Хоар |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | gloomy rocker | |
| Дата: | 03.12.04 16:17 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Да, все верно, синглетоны есть зло Синглетон — это зло, если он в кривых руках. И он очень даже не злой, если не хранит состояния. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Скука — двигатель прогресса. | |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VladD2 rsdn | www.k-press.ru/cs |
| Дата: | 04.12.04 08:36 | |
| Оценка: | +2 ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям Оберон систем запущенных независимо друг от друга. Ну, что же... Приятно, что ты такие начал изучать новые технологии. Вот тебе для дальнейшего разваитя http://gzip.rsdn.ru/article/dotnet/appdomains.xml Автор(ы): Андрей Корявченко почитай на досуге. Может еще одну нетленку раодишь. Дата: 12.06.2003 Статья рассказывает о доменах приложений (Application Domains) в .NET Framework. Приводятся примеры работы с доменами приложений, а также сравнение производительности и потребляемых ресурсов приложений, загружаемых в отдельные процессы и отдельные домены приложений, находящиеся в одном процессе. ... << RSDN@Home 1.1.4 beta 3 rev. 207>> |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VladD2 rsdn | www.k-press.ru/cs |
| Дата: | 04.12.04 08:36 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Я же ответил: "Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям..." нескольким копиям запущенных черных коробок. А это просто несколько разных обычных приложений, между собой у них компонентности нет и не было никогда. Продолжаем избавляться от заблуждений http://gzip.rsdn.ru/article/dotnet/inside_remoting1.xml Автор(ы): Игорь Ткачев Дата: 11.07.2003 Первая часть статьи, рассказывающая о новой технологии межпроцессной коммуникации — Remoting. Это "родная" для .NET Framework технология, использующая все преимущества платформы. В статье разбираются такие тонкие моменты, как работа с контекстом и перехват создания объектов и вызова методов. ... << RSDN@Home 1.1.4 beta 3 rev. 207>> |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VladD2 rsdn | www.k-press.ru/cs |
| Дата: | 04.12.04 08:36 | |
| Оценка: | ![]() | |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | VladD2 rsdn | www.k-press.ru/cs |
| Дата: | 04.12.04 09:14 |
| Re[24]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 04.12.04 13:29 | |
| Оценка: | +1 ![]() | |
| Здравствуйте, Mr. None, Вы писали: MN>И называется всё это модель COM Если бы он еще узнал про IServiceProvider, то было бы совсем хорошо ... << RSDN@Home 1.1.4 beta 3 rev. 241>> AVK Blog | |
| А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | SilverCloud | http://rodonist.wordpress.com |
| Дата: | 05.12.04 18:49 | |
| Оценка: | 16 (1) ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям Оберон систем запущенных независимо друг от друга. А как ты думаешь, почему так сделано? На всякий случай напомню, что операционная система, в которой у всех приложений была общая память, у Microsoft уже была в начале 90-х. Да, там ещё многозадачность была кооперативная Who needs information? |
| Re: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 06.12.04 08:32 | |
| Оценка: | +1 ![]() | |
| Здравствуйте, SilverCloud, Вы писали: SC>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Я думал что .NET в каком-то смысле эквивалентна Оберон системе. Оказалось, что это не так. .NET оказывается в каком-то смысле эквивалентна нескольким копиям Оберон систем запущенных независимо друг от друга. SC>А как ты думаешь, почему так сделано? На всякий случай напомню, что операционная система, в которой у всех приложений была общая память, у Microsoft уже была в начале 90-х. Да, там ещё многозадачность была кооперативная Не надо приводить Microsoft в качестве примера. Сейчас объясню почему. Та система была написана на Си (Си++), а эти языки: 1) ничего не имеют против переполнения буфера, можно читать и писать по любому адресу. 2) не обладают сборщиком мусора, т. е. система не является модульной расширяемой... 3) В Си возможны любые трюки с преобразованием типов (опять же произвольный доступ к памяти) Поэтому та микрософтовская система с самого начала была обречена на провал. Однако, как раз в этоже время в ETH была однопользовательская операционная система с единым адресным пространством и кооперативной многозадачностью. Разрабатывалась она с 1985 года и называлась Оберон (Native Oberon). Эта система является образцом для подражания. Ее стабильность гарантировалась самим языком программирования Оберон, в нем отсутсвует адресная арифметика, постоянно включена проверка индексов массивов и арифметических переполнений, с типами можно обращаться только "по честному", встроен сборщик мусора. Отдельным вопросом является то, почему Microsoft в 90-ых занималась написанием заведомо обреченных на провал систем, когда она могла бы просто перенять опыт ETH? Кто знает, быть может Microsoft не потеряла бы 10 лет почем зря, не была бы заклеймена ярлыком Windows=Глюк, а платформа — аналог ".NET" появилась бы еще, например, в 1992 году? А так ожидаемая Windows-2006/2007 целиком написанная на "управляемом коде" появилась бы, например, в 1996/1997 годах? Нет, Microsoft вместо этого 10 лет ходила по граблям, ходила и ходила... А в это время ETH на месте не стоял, в 2000-2002 впервые в отрасли ПО там была создана операционная система Aos BlueBottle, в которой поверх железа работает вовсе не ядро операционки, а runtime system языка Active Oberon, а сама операционка целиком написана на Active Oberon, который основан на парадигме активных объектов. То есть не операционка управляет процессами/потоками, а этим занимается рантайм языка программирования. Спрашивается когда у Microsoft появится аналог? Опять только через 10 лет в 2012/2014 году? Microsoft не является компанией создателем новых технологий, она только шумит по этому поводу громко. Равняться на нее или приводить в качестве положительного примера не надо. |
| от модератора | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | _MarlboroMan_ модератор | ICQ #49811480 |
| Дата: | 06.12.04 08:45 |
Здравствуйте, Сергей Губанов. Огрормная просьба: либо изменить стиль сообщений (и общения), либо переместиться вместе с дискуссией в "Священные войны" — там вам адекватно ответят. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> ![]() — сколько программистов надо чтобы заменить сгоревшую лампочку? — сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается... |
| Re: от модератора | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 06.12.04 08:53 |
| Хорошо |
| Re[2]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 06.12.04 09:14 | |
| Оценка: | +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Не надо приводить Microsoft в качестве примера. Сейчас объясню почему. 1)Где Microsoft с его глючными операционками и где твой ETH с его мегаправильными операционками... 2)Как свалить .НЕТ тебе уже показывали. Оберон роняется аналогично. Достаточно граф объектов гденибудь зацепить за стек или статическую переменную и приплыли... А это может произойти в результате банальной ошибки. А как извесно ошибаются все... Автор: Сергей Губанов Но в случае с .НЕТ прибиваем ОДНО приложение, а в случае с Обероном медным тазом накроется вся операционка.Дата: 03.12.04 ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[2]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 06.12.04 11:18 | |
| Оценка: | +1 ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Не надо приводить Microsoft в качестве примера. Сейчас объясню почему. СГ>Та система была написана на Си (Си++), а эти языки: СГ>1) ничего не имеют против переполнения буфера, можно читать и писать по любому адресу. СГ>2) не обладают сборщиком мусора, т. е. система не является модульной расширяемой... СГ>3) В Си возможны любые трюки с преобразованием типов (опять же произвольный доступ к памяти) СГ>Поэтому та микрософтовская система с самого начала была обречена на провал. СГ>Однако, как раз в этоже время в ETH была однопользовательская операционная система с единым адресным пространством и кооперативной многозадачностью. Разрабатывалась она с 1985 года и называлась Оберон (Native Oberon). Эта система является образцом для подражания. Ее стабильность гарантировалась самим языком программирования Оберон, в нем отсутсвует адресная арифметика, постоянно включена проверка индексов массивов и арифметических переполнений, с типами можно обращаться только "по честному", встроен сборщик мусора. Как говорил Ата-Тюрк, "one shot — one body"... пардон, "одна страна — одна нация — одна религия". Это плохо тем, что систему очень, очень трудно масштабировать. Особенно — прикручивать что-то, написанное на другом языке. Межпрограммный интерфейс на голом Паскале или Си — пара пустяков. На С++ — уже гораздо сложнее (требуется обоюдная совместимость компиляторов по широкому спектру вопросов). Дотнет-программы пересекаются на довольно низком уровне — в MSIL-машине. Но заметь, MSIL — это всего лишь удобный ассемблер, абстрагированный от железа. Если бы Оберон-системы представляли такой же слоёный пирог, как .NET — т.е. абстрактный ассемблер, избавляющий от смертных грехов типа указателей-куда-попало, шлюзы к железу, шлюзы к сторонним программам (на родном коде процессора — чтобы можно было драйверы и всякую всячину писать)... Тогда можно было бы и подмножество Си прикрутить, и ещё всякую всячину. А пока что, получается несовместимость даже между разными ответвлениями Оберона, КомпонентПаскаля... Перекуём баги на фичи! |
| О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | SilverCloud | http://rodonist.wordpress.com |
| Дата: | 06.12.04 18:01 | |
| Оценка: | ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>... та микрософтовская система <Win3.x> с самого начала была обречена на провал. СГ>Отдельным вопросом является то, почему Microsoft в 90-ых занималась написанием заведомо обреченных на провал систем, СГ> не была бы заклеймена ярлыком Windows=Глюк, Ну, это по-моему, из журнала "Хакер" аналитика СГ>была создана операционная система Aos BlueBottle, в которой поверх железа работает вовсе не ядро операционки, а runtime system языка Active Oberon В чём разница, кроме названия? СГ>а сама операционка целиком написана на Active Oberon, который основан на парадигме активных объектов. См. предыдущий абзац СГ> стабильность гарантировалась самим языком программирования Оберон, в нем отсутсвует адресная арифметика, постоянно включена проверка индексов массивов и арифметических переполнений, с типами можно обращаться только "по честному", встроен сборщик мусора. То есть устойчивость такой системы обеспечивается только надёжностью выполняемого в ней кода. Это очень похоже на идеологию Win16, с той только разницей, что Windows не была привязана к какому-то одному языку программирования. Достоинсво у такой архитектуры только одно — скорость, недостатки же всем известны. Именно поэтому в Windows от этого уходят (в NT полностью ушли от идеи доверия к коду для user-mode программ, в Longhorn эту же идею переносят уже на драйвера). MacOS, кстати, эволюционировала в том же направлении. СГ>Microsoft не является компанией создателем новых технологий, Создателем — не является, а вот интегратором и внедренцем — охрененным СГ>она шумит по этому поводу громко. А вот с этим согласен на все 100. Я бы сказал даже, слишком громко. Who needs information? |
| Re[3]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 06.12.04 18:10 |
| Здравствуйте, Кодт, Вы писали: К>Если бы Оберон-системы представляли такой же слоёный пирог, как .NET — т.е. абстрактный ассемблер, избавляющий от смертных грехов типа указателей-куда-попало, шлюзы к железу, шлюзы к сторонним программам (на родном коде процессора — чтобы можно было драйверы и всякую всячину писать)... К>Тогда можно было бы и подмножество Си прикрутить, и ещё всякую всячину. К>А пока что, получается несовместимость даже между разными ответвлениями Оберона, КомпонентПаскаля... Кстати, в Университете Сан-Диего тыщщу лет назад разрабатывали виртуальную машину для паскаля — знаменитый UCSD Pascal. Но по каким-то причинам забили на неё... Перекуём баги на фичи! |
| Re[26]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Fantasist | |
| Дата: | 07.12.04 00:45 |
| Здравствуйте, Mr. None, Вы писали: MN>Не сомневаюсь, иначе у вас как раз и были-бы IUnknown и QueryInterface... Эта вещь уже встроенна в Делфи. Все интерфейсы Делфи наследуются от IUnknown, по-другому никак. Соответсвенно, если ты снабжаешь объект интерфейсами, то, будь добр, реализуй все методы IUnknown, или наследуй объект от TInterfacedObject, в котором эти методы уже реализованны. Так что все объекты Делфи снабженные интерфейсами автоматически совместимы с COM. |
| Re[25]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Fantasist | |
| Дата: | 07.12.04 00:50 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Наследование классов мне оказалось не нужным (за исключением наследования от класса TAggregate) вместо него мне хватило агрегации. Наследовение это на самом деле скрытая и прозрачная агрегация. Единственно, что агрегацию можно осуществить в ран-тайм, тогда как наследование делает ее в compile-time. А так, с такой же легкостью можно сказать — агрегация мне оказалось не нужна, хватило наследования. Чаще всего именно так и оказывается. |
| Re[2]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 07.12.04 00:57 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Та система была написана на Си (Си++), а эти языки: СГ>1) ничего не имеют против переполнения буфера, можно читать и писать по любому адресу. СГ>2) не обладают сборщиком мусора, т. е. система не является модульной расширяемой... СГ>3) В Си возможны любые трюки с преобразованием типов (опять же произвольный доступ к памяти) СГ>Поэтому та микрософтовская система с самого начала была обречена на провал. Не хочу сказать ничего плохого, но помимо мелкософта с виндой есть еще куча юниксов, а таки unix != глюк, хоть и написан на С. А по поводу компонентности в том виде, в каком ты ее пропогандируешь: вот у меня раз в 5 минут виснет или отваливается Word. Слава Богу, что он не является компонентом в твоем понимании встраивания в ось и я могу его спокойно убить и продолжать работать дальше. Далее, ты сам себе проиворечишь и строишь костыли по ходу изменения аргументации. Вначале ты говоришь: компонент должен быть один. Вот тебе возражение сразу — Word. Он не должен быть один, их должно быть столько, сколько у меня одновременно открыто документов. Ты говоришь: нет-нет, я ошибся, должен быть не один Word (соответственно, он уже не компонент), а должен быть один список вордов (и вот список-то и будет компонентом). А если бы я перед этим сказал, что мне нужен в ворде сплит (т.е. когда один и тот же документ в одном вроде показывается несколько раз) — однодокументные ворды тоже сразу перестали бы быть компонентами и стали бы активными объектами? Понимаешь, к чему я клоню? У тебя получается, что компонент — это просто объект-синглтон, причем будет он таковым или нет — это наше волюнтаристское решение. Так зачем огород городить? Давай остановимся на объектах. Далее. Что там было про сборку мусора? Можно подробнее, почему если нет сборки мусора, то система сразу некомпонентная? Вот у меня на компе работает очень даже компонентная винда, посмотри сам: есть компоненты (драйверы, например, в одном экземпляре), есть компоненты-фабрики (например, DLL, которые копируются в адресные пространства процессов, в таком случае скопированные DLL — это уже не компоненты, а объекты), есть глобальная фабрика объектов-процессов, есть компонент, управляющий объектами-процессами (планировщик), он же их при необходимости и прибивает и заодно осуществляет сборку мусора, возвращая системе ресурсы, которые использовал объект-процесс. При чем тут Оберон, .НЕТ и иже с ними? Более того, если Винда является компонентной, зачем .НЕТ быть компонентным, если он может положиться на сборщик мусора высшего уровня? .НЕТ ведь все равно без винды работать не будет. Рассматривай систему в целом, будь конструктивным. а то получается (раз уж ты физик) "Закон сохранения энергии — профанация, шитая белыми нитками: мячик не может оказаться по ту сторону стены, хотя з.с.э. это позволяет — высота ведь одинаковая"
|
| Re[26]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mr. None | |
| Дата: | 07.12.04 05:00 |
| Здравствуйте, Fantasist, Вы писали: F> Наследовение это на самом деле скрытая и прозрачная агрегация. Единственно, что агрегацию можно осуществить в ран-тайм, тогда как наследование делает ее в compile-time. F> А так, с такой же легкостью можно сказать — агрегация мне оказалось не нужна, хватило наследования. Чаще всего именно так и оказывается. Совершенно неправильно. Наследование не есть агрегация, а агрегация не есть наследование. И то и другое есть совершенно различные техники разделения ресурсов между потомком и предком, что в свою очередь (разделение ресурсов) является одним из основных столпов объектно-ориентированной парадигмы (Энтони Элиенс). Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду. | |
| Re[3]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 10:02 |
| Здравствуйте, jazzer, Вы писали: J>а то получается (раз уж ты физик) "Закон сохранения энергии — профанация, шитая белыми нитками: мячик не может оказаться по ту сторону стены, хотя з.с.э. это позволяет — высота ведь одинаковая" Последний пассаж — не в кассу. Именно так и объясняется туннельный эффект: с некоторой вероятностью объект окажется по ту сторону потенциального барьера. Просто для волновой функции мячика эта вероятность... маловата будет. Перекуём баги на фичи! |
| Re[3]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 10:06 | |
| Оценка: | -2 | |
| Здравствуйте, jazzer, Вы писали: J> unix != глюк, хоть и написан на С. Не согласен, абсолютно. Коменнтировать здесь не буду. Т.к. это должно происходить в разделе "священные войны". J>Далее. Что там было про сборку мусора? Можно подробнее, почему если нет сборки мусора, то система сразу некомпонентная? Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только в момент выполнения программы можно принять решение об освобождении памяти. В момент написания исходного кода каждого отдельного модуля невозможно принять решение о расставлении на каждый new соответсвующий delete — эта задача статически неразрешима, ее надо решать динамически в рантайме, а это как раз и называется термином "сборка мусора". Сборка мусора — это не роскошь, а суровая необходимость для построения модульных расширяемых систем. http://www.rsdn.ru/Forum/Message.aspx?mid=743372&only=1 Автор: S.Yu.Gubanov Дата: 30.07.04 J>...У тебя получается, что компонент — это просто объект-синглтон, причем будет он таковым или нет — это наше волюнтаристское решение......Так зачем огород городить? Давай остановимся на объектах... Компонент или модуль, грубо говоря просто есть DLL-ка. Объект — есть некая абстракция живущая в памяти. Как можно перепутать DLL и объект, извините, ума не приложу! J>...Вот у меня на компе работает очень даже компонентная винда... Виндос не компонентная. Компоненты о которых говорите Вы живут ПОВЕРХ виндозы. Именно поверх виндозы работают различные компонентные среды исполнения, будь-то среда COM или среда NET. Это тоже уже обсуждалось. http://www.rsdn.ru/Forum/Message.aspx?mid=777078&only=1 Автор: S.Yu.Gubanov Дата: 24.08.04 J> Более того, если Винда является компонентной, зачем .НЕТ быть компонентным .НЕТ, вообще говоря, тоже не компонентная (хоть у некоторых эта фраза вызывает бурный взрыв эмоций), компонетность о которой говорят применительно к .НЕТ на самом деле находится внутри каждого процесса, но не всего .НЕТ целиком. Каждый отдельный процесс работает в своем собственном .НЕТ окружении, оно, конечно, компонентно, но в целом .НЕТ ни в коем случае не компонентен. Об этом я написал там (почему-то над этим многие смеялись): http://www.rsdn.ru/Forum/Message.aspx?mid=927544&only=1 Автор: Сергей Губанов Дата: 02.12.04 J>....При чем тут Оберон....? Оберон системы это единственный известный мне пример модульных расширяемых систем. Других примеров я просто не знаю, вот и привожу только его. Так как я постоянно привожу в пример только Оберон системы, то меня тут некоторые товарищи стали считать религиозным фанатиком этого Оберона. Простите, но я просто еще других подобных систем не видел, вот и все объяснение. Знал бы, привел бы другие примеры тоже... |
| Re: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 10:20 |
| Здравствуйте, SilverCloud, Вы писали: СГ>>была создана операционная система Aos BlueBottle, в которой поверх железа работает вовсе не ядро операционки, а runtime system языка Active Oberon SC>В чём разница, кроме названия? Разница между кем и кем? SC>То есть устойчивость такой системы обеспечивается только надёжностью выполняемого в ней кода. Нет. Любой код может содержать ошибки. Стабильность гарантирует рантайм система языка программирования. Рантайм не дает ошибочному коду переполнить буфер и изгадить память, он не дает изгадить данные и любыми другими способами, скажем, с помощью "незаконного" приведения типов. К приведению типов, также относятся операции вида a_integer := b_real, которые запрещены еще на уровне компиляции. Если пользовательская программа пытается совершить запрещенное действие она просто останавливается самим рантаймом. Естественно, что сама система продолжает работать дальше как ни в чем не бывало. |
| Re[4]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 07.12.04 11:12 |
| Hello, Сергей! You wrote on Tue, 07 Dec 2004 10:06:21 GMT: J>> Далее. Что там было про сборку мусора? Можно подробнее, почему если нет J>> сборки мусора, то система сразу некомпонентная? СГ> Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только СГ> в момент выполнения программы можно принять решение об освобождении СГ> памяти. В момент написания исходного кода каждого отдельного модуля СГ> невозможно принять решение о расставлении на каждый new соответсвующий СГ> delete — эта задача статически неразрешима, ее надо решать динамически СГ> в рантайме, а это как раз и называется термином "сборка мусора". Сборка СГ> мусора — это не роскошь, а суровая необходимость для построения СГ> модульных расширяемых систем. Передергиваете, уважаемый. Задача о выделении памяти иногда тоже статически неразрешима, как и задача об освобождении памяти, но из этого не следует, что кому-то непонятно, где писать new With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[5]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 11:34 | |
| Оценка: | -1 | |
| Здравствуйте, Sergey, Вы писали: S>Задача о выделении памяти иногда тоже статически S>неразрешима, как и задача об освобождении памяти, но из этого не следует, S>что кому-то непонятно, где писать new Пример когда неизвестно где писать delete Процедура возвращает список файлов находящихся в каталоге.
где
Кто должен удалить цепочку объектов FileInfo? Сам модуль с процедурой FileList не может нести ответсвенность за удаление созданной им цепочки объектов, так как не знает пользуются ими кто-то или нет. Пользовательский модуль тоже не может удалить полученную цепочку так как не знает скольким еще другим модулям была выдана эта же самая цепочка объектов и пользуются ли они ею. Итак, ни один из модулей не может принять решение об удалении этой цепочки. Остается только рантайм среда — вот она и удалит, только она знает все обо всех объектах! |
| Re[4]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 07.12.04 11:44 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, jazzer, Вы писали: J>>а то получается (раз уж ты физик) "Закон сохранения энергии — профанация, шитая белыми нитками: мячик не может оказаться по ту сторону стены, хотя з.с.э. это позволяет — высота ведь одинаковая" К>Последний пассаж — не в кассу. Именно так и объясняется туннельный эффект: с некоторой вероятностью объект окажется по ту сторону потенциального барьера. Просто для волновой функции мячика эта вероятность... маловата будет. Именно это я и имел в виду: Сергей рассматривает только один маленький аспект, упуская из виду остальные. Можно и без привлечения квантов: что мешает перевести внутреннюю энергию мячика в кинетическую, чтобы он перелетел через стену, упал с той стороны и энергия снова перешла во внутреннюю? Точно не з.с.э, но ведь это не значит, что з.с.э — профанация.
|
| Re[6]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 07.12.04 11:45 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Sergey, Вы писали: S>>Задача о выделении памяти иногда тоже статически S>>неразрешима, как и задача об освобождении памяти, но из этого не следует, S>>что кому-то непонятно, где писать new :) СГ>Пример когда неизвестно где писать delete СГ>Процедура возвращает список файлов находящихся в каталоге. СГ>
СГ>где СГ>
СГ>Кто должен удалить цепочку объектов FileInfo? Сам модуль с процедурой FileList не может нести ответсвенность за удаление созданной им цепочки объектов, так как не знает пользуются ими кто-то или нет. Пользовательский модуль тоже не может удалить полученную цепочку так как не знает скольким еще другим модулям была выдана эта же самая цепочка объектов и пользуются ли они ею. Итак, ни один из модулей не может принять решение об удалении этой цепочки. Остается только рантайм среда — вот она и удалит, только она знает все обо всех объектах! Для таких случаев отлично работает стратегия самоуничножения с привлечением счетчика ссылок. Никакого ГЦ не нужно.
|
| Re[6]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 07.12.04 12:03 |
| Hello, Сергей! You wrote on Tue, 07 Dec 2004 11:34:25 GMT: S>> Задача о выделении памяти иногда тоже статически S>> неразрешима, как и задача об освобождении памяти, но из этого не S>> следует, что кому-то непонятно, где писать new СГ> Пример когда неизвестно где писать delete СГ> Процедура возвращает список файлов находящихся в каталоге. СГ>
СГ> где СГ>
Я вашей мовы толком не разумею. Но насколько разумею, для этой хрени с полпинка пишется обертка, аналогичная смарт-пойнтеру с рефкаунтом. После чего задачу можно считать решенной — в рантайме и без GC. СГ> Кто должен удалить цепочку объектов FileInfo? Кто последний пользовался, естественно. СГ> Сам модуль с процедурой FileList не может нести ответсвенность за СГ> удаление созданной им цепочки объектов, так как не знает пользуются ими СГ> кто-то или нет. Ага. СГ> Пользовательский модуль тоже не может удалить СГ> полученную цепочку так как не знает скольким еще другим модулям была СГ> выдана эта же самая цепочка объектов и пользуются ли они ею. Неа. Пользовательскому модулю можно выдавать не голый указатель на память, а некий объект, семантика присваивания, создания и уничтожения которого изменена так, чтобы по уничтожении последнего такого объекта был уничтожен твой FileInfo. Только не надо этот объект обзывать сборщиком мусора СГ> Итак, ни СГ> один из модулей не может принять решение об удалении этой цепочки. СГ> Остается только рантайм среда — вот она и удалит, только она знает все СГ> обо всех объектах! Ты стрелки на освобождение памяти не переводи — ты ответь на поставленный вопрос: как по твоему, задача выделения памяти (не освобождения, а выделения) статически разрешима? With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[4]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 07.12.04 12:13 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, jazzer, Вы писали: J>> unix != глюк, хоть и написан на С. СГ>Не согласен, абсолютно. Коменнтировать здесь не буду. Т.к. это должно происходить в разделе "священные войны". ну так не надо было начинать про винду и про то, что она обречена на провал. Время показывает, что не обречена, равно как и юникс. Не буду ничего говорить про оберон — время покажет. J>>Далее. Что там было про сборку мусора? Можно подробнее, почему если нет сборки мусора, то система сразу некомпонентная? СГ>Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только в момент выполнения программы можно принять решение об освобождении памяти. В момент написания исходного кода каждого отдельного модуля невозможно принять решение о расставлении на каждый new соответсвующий delete — эта задача статически неразрешима, ее надо решать динамически в рантайме, а это как раз и называется термином "сборка мусора". Сборка мусора — это не роскошь, а суровая необходимость для построения модульных расширяемых систем. СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=743372&only=1 Автор: S.Yu.Gubanov Дата: 30.07.04 необходимость сборщика мусора сильно преувеличена. В подавляющем большинстве случаев объекты способны сами убирать за собой. J>>...У тебя получается, что компонент — это просто объект-синглтон, причем будет он таковым или нет — это наше волюнтаристское решение......Так зачем огород городить? Давай остановимся на объектах... СГ>Компонент или модуль, грубо говоря просто есть DLL-ка. Объект — есть некая абстракция живущая в памяти. Как можно перепутать DLL и объект, извините, ума не приложу! А я и не путаю. DLL сам по себе является объектом, т.е. обладает поведением и содержанием. Даже если ее поведение сводится к рожанию или хранению других объектов. J>>...Вот у меня на компе работает очень даже компонентная винда... СГ>Виндос не компонентная. Компоненты о которых говорите Вы живут ПОВЕРХ виндозы. Именно поверх виндозы работают различные компонентные среды исполнения, будь-то среда COM или среда NET. Это тоже уже обсуждалось. СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=777078&only=1 Автор: S.Yu.Gubanov Дата: 24.08.04 Я это читал и с аргументацией не согласен. Взять хотя бы требование гомогенности: я прошу прощения, но оберон не гомогенен — над ним висит рантайм и ГЦ, которые также являются компонентами/объектами, с которыми взаимодействуют остальные объекты. А если мы допускаем гетерогенность такого рода, то я не понимаю, почему мы не можем допустить многоуровневую гетерогенность без потери системой статуса компонентной. Да и вообще, гомогенности в природе не существует, всегда возникают иерархии, так или иначе. Более того, в винде есть рантайм в виде планировщика задач и ГЦ в виде менеджера памяти, который работает с объектами типа "страница памяти", являющимися контейнерами других объектов. Ты же физик, смотри на вещи обобщенно. Вспомни обобщенные координаты, что ли... J>> Более того, если Винда является компонентной, зачем .НЕТ быть компонентным СГ>.НЕТ, вообще говоря, тоже не компонентная (хоть у некоторых эта фраза вызывает бурный взрыв эмоций), компонетность о которой говорят применительно к .НЕТ на самом деле находится внутри каждого процесса, но не всего .НЕТ целиком. Каждый отдельный процесс работает в своем собственном .НЕТ окружении, оно, конечно, компонентно, но в целом .НЕТ ни в коем случае не компонентен. Об этом я написал там (почему-то над этим многие смеялись): СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=927544&only=1 Автор: Сергей Губанов Дата: 02.12.04 тебе никто не мешает сделать такую же архитектуру в рамках .НЕТ. твои выводы можно обратить против оберона и черонящика: возьмем и запустим несколько ящиков и в каждом из них — hello world. Как ты программу (классы, объекты, компоненты) напишешь, так они и будут работать. Напишешь их гибкими — будут работать в одном .НЕТ-окружении и гомогенно, раз уж для тебя это так критично. J>>....При чем тут Оберон....? СГ>Оберон системы это единственный известный мне пример модульных расширяемых систем. Других примеров я просто не знаю, вот и привожу только его. Так как я постоянно привожу в пример только Оберон системы, то меня тут некоторые товарищи стали считать религиозным фанатиком этого Оберона. Простите, но я просто еще других подобных систем не видел, вот и все объяснение. Знал бы, привел бы другие примеры тоже... Smalltalk
|
| Re[5]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 07.12.04 12:19 |
| Здравствуйте, jazzer, Вы писали: J>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только в момент выполнения программы можно принять решение об освобождении памяти. В момент написания исходного кода каждого отдельного модуля невозможно принять решение о расставлении на каждый new соответсвующий delete — эта задача статически неразрешима, ее надо решать динамически в рантайме, а это как раз и называется термином "сборка мусора". Сборка мусора — это не роскошь, а суровая необходимость для построения модульных расширяемых систем. СГ>>http://www.rsdn.ru/Forum/Message.aspx?mid=743372&only=1 Автор: S.Yu.Gubanov Дата: 30.07.04 J>необходимость сборщика мусора сильно преувеличена. В подавляющем большинстве случаев объекты способны сами убирать за собой. Просто есть куча программистов (многие оберонщики Что ни говори, но C++ приучает к более строгой дисциплине... |
| Re[7]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 12:20 |
| Здравствуйте, jazzer, Вы писали: J>Для таких случаев отлично работает стратегия самоуничножения с привлечением счетчика ссылок. Список двусвязный. Счетчик ссылок не работает когда есть циклические ссылки. |
| Re[12]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 12:26 | |
| Оценка: | 6 (1) | |
| Здравствуйте, Кодт, Вы писали: К>Фатальное поведение — это не только расстрел памяти. К>Пусть, например, у тебя есть модуль, которым пользуются много клиентов. И в нём — редкая логическая ошибка, блокирующая его наглухо... К>
Интересный пример, причем его явная искусственность является достоинством, а не недостатком, т.к. вопрос обсуждается в принципе. Но мне кажется, что данный пример не может быть применен в качестве критики Оберон-систем. Данная проблема является общей для всех систем с несколькими процессами. В Модуле-2 (и, вероятно, в Обероне) для "изоляции процессов" (Ваше выражение из другого поста), использующих общие данные, используются мониторы (понятие монитора было введено Хоаром). В таком случае, вызов другим процессом процедуры BugIt, в то время как исполняется Measure, был бы невозможен. (Конечно, ничто не мешает сначала вызвать BugIt, а затем Measure. Но имеет ли это отношение к изоляции процессов? Ведь осуществить такую последовательность вызовов может один и тот же процесс.) Хочу подчеркнуть мысль, что указанная Вами проблема общая. В любой системе есть объекты (например, жесткий диск), одновременный доступ к которым не разрешается. Если же процессам требуются свои собственные объекты, то модуль может экспортировать тип данных, и каждый процесс создаст свой объект. Таким образом (imho, конечно Хоар |
| Re[7]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 12:30 |
| Здравствуйте, Sergey, Вы писали: S>Я вашей мовы толком не разумею. Но насколько разумею, для этой хрени с S>полпинка пишется обертка, аналогичная смарт-пойнтеру с рефкаунтом. После S>чего задачу можно считать решенной — в рантайме и без GC. Там двусвязный список. Когда объекты циклически ссылаются друг на друга, то подсчет количества ссылок бесполезен, оно никогда не будет равно нулю. СГ>> Кто должен удалить цепочку объектов FileInfo? S>Кто последний пользовался, естественно. А откуда ему знать что он последний? S>Ты стрелки на освобождение памяти не переводи — ты ответь на поставленный S>вопрос: как по твоему, задача выделения памяти (не освобождения, а S>выделения) статически разрешима? Я об этом никогда не задумывался. Наверное, в общем случае нет. Но как Вы сами заметили, не зависимо от ответа на этот вопрос все операторы new расставить можно в момент написания модуля. То есть, я признаю, что задача о принятии решения об удалении объектов на момент написания кода модуля, с одной стороны, и задача расставить delete в нужных местах в коде модуля, с другой стороны, вполне могут оказаться разными задачами. Я сейчас затрудняюсь доказать или опровергнуть что эти две задачи суть одно и тоже, просто мне сильно мерещиться, что это одно и тоже. |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 07.12.04 12:30 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, jazzer, Вы писали: J>>Для таких случаев отлично работает стратегия самоуничножения с привлечением счетчика ссылок. СГ>Список двусвязный. Счетчик ссылок не работает когда есть циклические ссылки. нужно отдавать ссылку на список целиком, а не ссылку на его член. и считать ссылки на весь список. тогда будет абс. пофиг, скольки-направленным этот список является.
|
| Re[9]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 07.12.04 12:33 | |
| Оценка: | +1 | |
| Здравствуйте, jazzer, Вы писали: J>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Здравствуйте, jazzer, Вы писали: J>>>Для таких случаев отлично работает стратегия самоуничножения с привлечением счетчика ссылок. СГ>>Список двусвязный. Счетчик ссылок не работает когда есть циклические ссылки. J>нужно отдавать ссылку на список целиком, а не ссылку на его член. J>и считать ссылки на весь список. J>тогда будет абс. пофиг, скольки-направленным этот список является. просто имеем баги в дизайне, чтож и от этого никто не застрахован |
| Re[4]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 12:37 | |
| Оценка: | 2 (1) +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только в момент выполнения программы можно принять решение об освобождении памяти. В момент написания исходного кода каждого отдельного модуля невозможно принять решение о расставлении на каждый new соответсвующий delete — эта задача статически неразрешима, ее надо решать динамически в рантайме, а это как раз и называется термином "сборка мусора". Сборка мусора — это не роскошь, а суровая необходимость для построения модульных расширяемых систем. Нет, это всего лишь верование. Одна только сборка освободившихся ресурсов (в том числе — блоков памяти) — это половина дела. Собственно освобождение ресурса должно быть так или иначе детерминированным. Например, если между двумя потоками (или фибрами) программы есть конвеер, и один из участников просто "забывает" о ней, то система перейдёт в тупиковое состояние: или приёмник будет безуспешно ждать, или передатчик переполнит конвеер. То есть, они должны совершить рукопожатие, в результате которого конвеер будет освобождён и пригоден к утилизации. Опять же, если в конвеере остались данные, то их уничтожение должно проходить по некому сценарию (самый простой из которых — забыть). Да, самый популярный способ освобождения ресурса — это просто забывание. Но он не единственный! Обрати внимание: я сознательно не говорю "память". Потому что ресурсы могут быть любыми, и даже разноплановыми — уровень физических устройств, уровень объектов-представителей, уровень протокола, уровень смысла... Сборщик мусора решает узкую задачу. Да, с ним удобнее — он автоматизирует "дефолтный" способ освобождения, к которому вручную можно свести нетривиальные (например, вычерпать хитрые данные из конвеера, обработать и позабывать каждое по отдельности). Перекуём баги на фичи! |
| Re[9]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 12:38 |
| Здравствуйте, jazzer, Вы писали: J>нужно отдавать ссылку на список целиком, а не ссылку на его член. J>и считать ссылки на весь список. А нету никакого целикового списка! Есть только вот это:
Или аналог на языке C#:
|
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 07.12.04 12:41 |
| Hello, Сергей! You wrote on Tue, 07 Dec 2004 12:20:14 GMT: СГ> Здравствуйте, jazzer, Вы писали: J>> Для таких случаев отлично работает стратегия самоуничножения с J>> привлечением счетчика ссылок. СГ> Список двусвязный. Счетчик ссылок не работает когда есть циклические СГ> ссылки. Делается объект FileInfoList, который умеет удалять двусвязный список. У метода FileInfoList есть методы AddRef и Release, меняющие его счетчик ссылок. Клиентам выдаются объекты FileInfoPtr, указывающие на произвольный блок FileInfo из FileInfoList и имеющие внутри приватный указатель на сам FileInfoList. При копировании/создании/удалении эти FileInfoPtr'ы дергают AddRef/Release FileInfoList'а. Никаких циклических ссылок, все работает. With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[9]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 07.12.04 12:48 |
| Здравствуйте, Sergey, Вы писали: [skipped] S>With best regards, Sergey. Сергей, ну понимаешь, другой Сергей хочет сборщиком мусора решать баги, которые он в дизайне делает Поэтому объяснять ему по ходу бес толку... |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Privalov | |
| Дата: | 07.12.04 12:48 | |
| Оценка: | ![]() | |
| Здравствуйте, Курилка, Вы писали: К>Код на Обероне не может быть ошибочным он работает всегда идеально Аксиома: В любой программе есть ошибки. Закон пропорциональности: Чем больше программа необходима, тем больше в ней ошибок. Следствие: Ошибок не содержит лишь совершенно ненужная программа. Взято отсюда. |
| Re[10]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 12:53 | |
| Оценка: | +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>А нету никакого целикового списка! Есть только вот это: Если это список ради списка — то можно вообще наплевать. Создали — бросили — утечка — ну и хрен с ней. А если он несёт какую-то смысловую нагрузку, то можно найти решение в соответствии с правилами его применения. Вплоть до локального сборщика.
Перекуём баги на фичи! |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 07.12.04 12:55 |
| Hello, Сергей! You wrote on Tue, 07 Dec 2004 12:30:37 GMT: СГ> Там двусвязный список. Когда объекты циклически ссылаются друг на СГ> друга, то подсчет количества ссылок бесполезен, оно никогда не будет СГ> равно нулю. Я уже ответил в соседней ветке. СГ> А откуда ему знать что он последний? Через рефкаунт, например. S>> Ты стрелки на освобождение памяти не переводи — ты ответь на S>> поставленный вопрос: как по твоему, задача выделения памяти (не S>> освобождения, а выделения) статически разрешима? СГ> Я об этом никогда не задумывался. Наверное, в общем случае нет. Но как СГ> Вы сами заметили, не зависимо от ответа на этот вопрос все операторы СГ> new расставить можно в момент написания модуля. Вот о том и речь — статическая разрешимость или неразрешимость задачи ничего не говорит о возможности описать ее решение на языке программирования (алгоритмической разрешимости). СГ> То есть, я признаю, что задача о принятии решения об удалении объектов СГ> на момент написания кода модуля, с одной стороны, и задача расставить СГ> delete в нужных местах в коде модуля, с другой стороны, вполне могут СГ> оказаться разными задачами. Я сейчас затрудняюсь доказать или СГ> опровергнуть что эти две задачи суть одно и тоже, просто мне сильно СГ> мерещиться, что это одно и тоже. Я немножко о другом — совершенно очевидно, что решение об удалении объектов через рефкаунт позволяет решать "статически неразрешимые" в твоей терминологии задачи, при этом совершенно очевидно, где надо писать new и delete. Т.е. твое доказательство необходимости использования GC в компонентных системах основываясь только на стаитческой неразрешимости задачи удаления памяти является неверным. При этом я не оспариваю саму необходимость применения GC (а только данное доказательство ее необходимости) — мне просто неизвестно, всегда ли можно найти подходящий алгоритм удаления памяти, не являющийся GC, или не всегда. With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[10]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 07.12.04 12:59 |
| Hello, Курилка! You wrote on Tue, 07 Dec 2004 12:48:04 GMT: К> Сергей, ну понимаешь, другой Сергей хочет сборщиком мусора решать баги, К> которые он в дизайне делает К> толку... Да мне собственно баги эти и сборщики мусора не интересны. Тут, по ходу, его оппоненты тоже часто не понимают о чем он говорит. Я просто увидел дырку в доказательстве, о чем и заявил. А о компонентных системах у меня вообще особое мнение With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[11]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 07.12.04 13:05 |
| Здравствуйте, Sergey, Вы писали: S>Да мне собственно баги эти и сборщики мусора не интересны. Тут, по ходу, его S>оппоненты тоже часто не понимают о чем он говорит. Я просто увидел дырку в S>доказательстве, о чем и заявил. А о компонентных системах у меня вообще S>особое мнение Частное и недоступное широкой публике? |
| Re[5]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 07.12.04 13:13 |
| Здравствуйте, Sergey, Вы писали: S>Передергиваете, уважаемый. Задача о выделении памяти иногда тоже статически S>неразрешима, как и задача об освобождении памяти, но из этого не следует, S>что кому-то непонятно, где писать new Если всем понятно, где писать new, то задачу о выделении следует признать статически разрешимой. |
| Re[12]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 07.12.04 13:21 | |
| Оценка: | +1 | |
| Hello, Курилка! You wrote on Tue, 07 Dec 2004 13:05:51 GMT: S>> Да мне собственно баги эти и сборщики мусора не интересны. Тут, по S>> ходу, его оппоненты тоже часто не понимают о чем он говорит. Я просто S>> увидел дырку в доказательстве, о чем и заявил. А о компонентных S>> системах у меня вообще особое мнение К> Частное и недоступное широкой публике? Да нет, почему недоступное. Если вкратце, то лучший компонент — это компилируемый исходник, а все остальное от лукавого и заявленные для компонентной парадигмы задачи решать может лишь частично. Только вот доказывать, почему это так мне совершенно лениво. Хотя ведь щас навалятся, гнилыми помидорами закидают With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[13]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 13:22 |
| Здравствуйте, AVC, Вы писали: AVC>Таким образом (imho, конечно У систем с разделением процессов есть преимущества перед системами без разделения процессов: в случае сбоя можно сравнительно безболезненно прибить/перезапустить отдельный процесс. У систем с контролем владения ресурсами есть преимущества перед системами без контроля: забытый хэндл монопольно открытого файла будет отпущен при уничтожении объекта-владельца (т.е. процесса). У систем со сборкой мусора есть преимущества перед системами без сборки: задача утилизации памяти уже решена в рантайме, нет нужды создавать свои велосипеды (хотя, как я уже говорил, нетривиальные случаи придётся воплощать руками). Ну и так далее. Задача управления ресурсами (в том числе — памятью) содержит ряд типовых подзадач — выделение, защита, освобождение, восстановление после аварии (это касается дисков, каналов связи, сервисов). Естественно, чем больше из них автоматизировано, тем легче жить. Оберон эффективно решил две задачи: защита и освобождение памяти. А всё остальное осталось за кадром. К примеру, перезапуск сервиса мог бы выглядеть следующим образом
Это — ручная реализация. Вполне возможно её автоматизировать; однако она встречается не так часто, как работа с памятью, поэтому дешевле реализовать вручную в тех местах, где она возникла, чем заставлять все объекты системы поддерживать этот аспект. Перекуём баги на фичи! |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 13:54 |
| Здравствуйте, Кодт, Вы писали: К>Оберон эффективно решил две задачи: защита и освобождение памяти. А всё остальное осталось за кадром. Однако, замечу, что Оберон-системы реализованы именно на Обероне. Следовательно, все уаказанные Вами задачи как-то на Обероне решаются. Согласен, что нет ясности (по крайней мере, у меня), используются ли унифицированные способы решения этих проблем, или же в каждом отдельном случае — свои собственные. Здесь у меня в знаниях пробел (доступной информации по Оберону недостаточно), который я вынужден компенсировать объединением моих сведений о Модуле-2 и Обероне в одно воображаемое целое. К>К примеру, перезапуск сервиса мог бы выглядеть следующим образом К>
Подозреваю, что имелось в виду
Хоар |
| Re[13]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 07.12.04 14:03 |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 07.12.04 14:21 |
| Здравствуйте, Sinclair, Вы писали: S>Ничего подобного. В монолитной Оберон-системе нет возможности изолировать "зациклившийся" объект и административными мерами его уничтожить. 1) Оберон системы не монолитные, а модульные. 2) Почему вдруг нельзя уничтожить "зациклившийся" объект, что в этом такого сложного? obj := NIL; — все дела.... |
| Re[2]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | fddima | |
| Дата: | 07.12.04 14:26 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Нет. Любой код может содержать ошибки. Стабильность гарантирует рантайм система языка программирования. Рантайм не дает ошибочному коду переполнить буфер и изгадить память, он не дает изгадить данные и любыми другими способами, скажем, с помощью "незаконного" приведения типов. К приведению типов, также относятся операции вида a_integer := b_real, которые запрещены еще на уровне компиляции. Если пользовательская программа пытается совершить запрещенное действие она просто останавливается самим рантаймом. Естественно, что сама система продолжает работать дальше как ни в чем не бывало. Это самые простые ошибки. А если программа начнет "взаимодействовать" по сети весьма "ошибочным" способом? Что делает рантайм? Отдыхает. Всю ответственность — он взять никогда не сможет. А то сделаем серебрянную пулю. ... << RSDN@Home 1.1.4 beta 3 rev. 241>> |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 14:26 |
| Здравствуйте, AVC, Вы писали: К>>Оберон эффективно решил две задачи: защита и освобождение памяти. А всё остальное осталось за кадром. AVC>Однако, замечу, что Оберон-системы реализованы именно на Обероне. AVC>Следовательно, все уаказанные Вами задачи как-то на Обероне решаются. Не совсем "следовательно". Например, восстановление файловой системы в MS-DOS выполняется отдельной утилитой; а в журналирующих файловых системах эта фича встроена. Управление кучей в Win3.1 и Win95 требует ручной работы, а в WinNT куча принадлежит процессу и автоматически освобождается при его уничтожении. Минимальная автоматизация состоит в предоставлении пользователю достаточного набора инструментов для ручной работы. Но это не решение задачи. AVC>Согласен, что нет ясности (по крайней мере, у меня), используются ли унифицированные способы решения этих проблем, или же в каждом отдельном случае — свои собственные. AVC>Здесь у меня в знаниях пробел (доступной информации по Оберону недостаточно), который я вынужден компенсировать объединением моих сведений о Модуле-2 и Обероне в одно воображаемое целое. К>>К примеру, перезапуск сервиса мог бы выглядеть следующим образом
AVC>Подозреваю, что имелось в виду
AVC> Угу Перекуём баги на фичи! |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 14:34 |
| Здравствуйте, Сергей Губанов, Вы писали: S>>Ничего подобного. В монолитной Оберон-системе нет возможности изолировать "зациклившийся" объект и административными мерами его уничтожить. СГ>1) Оберон системы не монолитные, а модульные. СГ>2) Почему вдруг нельзя уничтожить "зациклившийся" объект, что в этом такого сложного? obj := NIL; — все дела.... Какие такие все дела? 1) Поток зациклился в недрах. И между прочим, подвесил всю цепочку вызовов от самого основания (некоего активного объекта). Потеря ссылок извне на активный объект — должна останавливать поток или не должна? Должна делать это аварийно или есть какой-то механизм мягкого выхода? 1.1) Если на стеке активного объекта есть ссылки на этот объект — что будет делать сборщик мусора? 2) Модуль оказался повреждён. Все активные объекты, взаимодействующие с этим модулем, будут подвешиваться и в будущем, пока модуль не перезагрузится. Когда это случится? 3) Модуль — это объект? Или нужно вручную делать объекты с моделью ПерезагружаемыйСервис? Перекуём баги на фичи! |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 14:37 |
| Здравствуйте, Sinclair, Вы писали: S>Неверно. Судя по всему, ты так и не понял сути проблемы. Заворачивание обеих процедур в монитор ничему не поможет. Потому как проблема возникает не из-за того, что кто-то вызывает BugIt одновременно с вызовом Measure. Здесь хочется обратиться сразу ко многим оппонентам: пожалуйста, формулируйте свою мысль в форме утвердительного предложения по существу вопроса! Даже если я не прав, мне трудно чему-нибудь научиться из загадочных высказываний вроде:
Почитай стандарт Си++. Вы хотя бы Рихтера на досуге почитали. Проблема возникает не из-за того, что кто-то вызывает BugIt одновременно с вызовом Measure. и т.д. Если проблема не в одновременности, то и скажите прямо в чем именно. Я буду только благодарен. AVC>>Таким образом (imho, конечно S>Ничего подобного. В монолитной Оберон-системе нет возможности изолировать "зациклившийся" объект и административными мерами его уничтожить. В NT у нас есть гарантия корректного убийства процесса и освобождения разделяемых ресурсов, которые он использовал. Мне не совсем понятно, как Вы себе представляете монолитность Оберон-систем. Я также не понимаю, что именно в Обероне мешает уничтожить зациклившийся процесс. (По крайней мере, в Модуле-2 этому ничто не мешало.) Когда, например, я критиковал Си (кстати, язык, к которому я сильно привязан), то указал за что: за адресную арифметику и небезопасность указателей. Надеюсь, что и Вы поступите так же. Хоар |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 14:50 | |
| Оценка: | +1 | |
| Здравствуйте, AVC, Вы писали: AVC>Здесь хочется обратиться сразу ко многим оппонентам: AVC>пожалуйста, формулируйте свою мысль в форме утвердительного предложения по существу вопроса! AVC>Даже если я не прав, мне трудно чему-нибудь научиться из загадочных высказываний вроде: AVC>Если проблема не в одновременности, то и скажите прямо в чем именно. AVC>Я буду только благодарен. Мне казалось, что я написал достаточно прозрачный для понимания код. BugIt создаёт ошибку; все последующие вызовы Measure работают ошибочно (более того, катастрофически — вешают потоки). Убийство каждого отдельного потока не спасает, поскольку повреждение модуля сохраняется. Спасти может только перезагрузка модуля. Перекуём баги на фичи! |
| Re[3]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | bkat | |
| Дата: | 07.12.04 14:55 |
| Здравствуйте, fddima, Вы писали: F>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Нет. Любой код может содержать ошибки. Стабильность гарантирует рантайм система языка программирования. Рантайм не дает ошибочному коду переполнить буфер и изгадить память, он не дает изгадить данные и любыми другими способами, скажем, с помощью "незаконного" приведения типов. К приведению типов, также относятся операции вида a_integer := b_real, которые запрещены еще на уровне компиляции. Если пользовательская программа пытается совершить запрещенное действие она просто останавливается самим рантаймом. Естественно, что сама система продолжает работать дальше как ни в чем не бывало. F> Это самые простые ошибки. А если программа начнет "взаимодействовать" по сети весьма "ошибочным" способом? Что делает рантайм? Отдыхает. Я уже несколько раз на это намекал. До сих пор эти намеки остаются без комментариев. |
| Re[16]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 15:13 |
| Здравствуйте, Кодт, Вы писали: К>Мне казалось, что я написал достаточно прозрачный для понимания код. Мое просьба была адресована Sinclair, а также еще некоторым участникам форумов RSDN (они сами себя узнают по приведенным мной цитатам). К>BugIt создаёт ошибку; все последующие вызовы Measure работают ошибочно (более того, катастрофически — вешают потоки). К>Убийство каждого отдельного потока не спасает, поскольку повреждение модуля сохраняется. К>Спасти может только перезагрузка модуля. Я действительно не понимаю, как это может быть критикой Оберона. Ведь именно в Обероне нет отдельных программ, а есть раздельно компилируемые модули. Поэтому именно в Обероне перезагрузка модуля может быть реализована самым простым образом. Возможно, я не до конца понял Вашу мысль? Хоар |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sinclair rsdn | http://www.parallels.com/automation/operations/ |
| Дата: | 07.12.04 15:15 |
| Re[17]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 07.12.04 15:20 |
| Здравствуйте, AVC, Вы писали: AVC>Поэтому именно в Обероне перезагрузка модуля может быть реализована самым простым образом. Кстати, как? Есть встроенное API? Модуль это объект? Есть какой-то рефлекшн? AVC>Возможно, я не до конца понял Вашу мысль? Это я отвечал Сергею Губанову, что не только расстрел памяти может привести к катастрофе. Перекуём баги на фичи! |
| Re[16]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 15:27 |
| Здравствуйте, Sinclair, Вы писали: S>Виноват, действительно неконструктивно получилось. В будущем постараюсь быть аккуратнее. По существу — см. ответ Кодта рядом. Я рад, что Вы не обиделись! Если что Хоар |
| Re[4]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 07.12.04 15:34 |
| F>> Это самые простые ошибки. А если программа начнет "взаимодействовать" по сети весьма "ошибочным" способом? Что делает рантайм? Отдыхает. B>Я уже несколько раз на это намекал. B>До сих пор эти намеки остаются без комментариев. А сколько раз я об этом говорил Автор: Mamut Дата: 03.12.04 ... << RSDN@Home 1.1.4 beta 3 rev. 185>> ![]() |
| Re[18]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 15:47 |
| Здравствуйте, Кодт, Вы писали: К>Кстати, как? Есть встроенное API? Модуль это объект? Есть какой-то рефлекшн? Некий "рефлекшн" у меня есть. Т.е. я могу себе представить решение некоторых таких проблем на Обероне. Например, могу себе представить (как мне кажется Если есть интерес к моим "фантазиям", постараюсь их в ближайшее время сформулировать. В своих представлениях я опираюсь на книги Вирта по Модуле-2 и Оберону, а также на описание ETH Oberon System 3. К сожалению (я уже отмечал это раньше), я не владею информацией о том, насколько унифицированно решаются эти задачи в Оберон-системах в целом. К>Это я отвечал Сергею Губанову, что не только расстрел памяти может привести к катастрофе. Согласен на 100%! Как подумаешь обо всем, что может привести к катастрофе... Хоар |
| Re[19]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 07.12.04 16:23 |
| Не знаю, правильно ли я делаю, но привожу здесь цитату из описания ETH Oberon System 3, развития первоначальной Оберон-системы. Трудно что-либо говорить об Оберон-системах, не имея перед глазами хотя бы краткого описания. Текст я беру не из Интернета, а копирую прямо из окна ETH Oberon. Поэтому и цитирую, а не даю ссылку.
Хоар |
| Re[2]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | SilverCloud | http://rodonist.wordpress.com |
| Дата: | 07.12.04 17:17 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, SilverCloud, Вы писали: СГ>>>была создана операционная система Aos BlueBottle, в которой поверх железа работает вовсе не ядро операционки, а runtime system языка Active Oberon SC>>В чём разница, кроме названия? СГ>Разница между кем и кем? Между "ядро операционной системы" и runtime system языка Active Oberon ЗЫ А Вы о чём подумали? Who needs information? |
| Re[5]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Волк-Призрак | http://ghostwolf.newmail.ru |
| Дата: | 07.12.04 21:40 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только в момент выполнения программы можно [ cut ] К>Нет, это всего лишь верование. Это не верование. Это разные взгляды на пронраммирование. Объекты могут убирать за собой только в том случае, если их об этом попросят. Например, обнулившийся счётчик ссылок, вызов finalize(), или деструктора. Каждый подход является реализацией одной и той же задачи — гарантия освобождения ресурсов (хотя, что я это тиатанм объясяю?..) Вообще, было бы хорошо. если бы Java официально гарантировала вызов финализе. Но в спецификаци гаписано что не обязана jvm это делать. Конечно код наподобие onExitMenuItem
В системе с счётчиком ссылок эта проседура закдючается в присвоении null указателю на обект с счётчиком==1. Его "смерть" вызывает зачистку ссылок. Но всеравно любая стратегия _global cleanup_, как бы я это назвал. требует поддержки хотябы компилятора — например автоматический метвыхов addref и release при присвоениях ссылок, автоматическое присвоение null локальным объектным ссылкам, покидающим область видимости... (локальные объектные ссылки==объектные ссылки, созданные в той области видимости, которую они "покидают". К>Одна только сборка освободившихся ресурсов (в том числе — блоков памяти) — это половина дела. Собственно освобождение ресурса должно быть так или иначе детерминированным. Сейчас это не является детерминантой нигде, имхо. К>Например, если между двумя потоками (или фибрами) программы есть конвеер, и один из участников просто "забывает" о ней, то система перейдёт в тупиковое состояние: или приёмник будет безуспешно ждать, или передатчик переполнит конвеер. К>То есть, они должны совершить рукопожатие, в результате которого конвеер будет освобождён и пригоден к утилизации. К>Опять же, если в конвеере остались данные, то их уничтожение должно проходить по некому сценарию (самый простой из которых — забыть). К>Да, самый популярный способ освобождения ресурса — это просто забывание. Но он не единственный! Может просто изменим семантику оператора ___forgot(thing):? К>Обрати внимание: я сознательно не говорю "память". Потому что ресурсы могут быть любыми, и даже разноплановыми — уровень физических устройств, уровень объектов-представителей, уровень протокола, уровень смысла... Насчёт ресурсов уровня смысла я не вьезжаю (видно я тупой...). Но для осей ещё не существует понятия "харакри системных ресурсных обхектов". Возмём например файл. Программа в него монопольно пишет, пишет, и тут бац — вылетела. Файл считается занятым. Я конечно утрирую, это может в старых виндах (3.11 было Но вот что делать например с ресурсами типа соединения к бд? Это значит, что либо Абсолютно Все Программы, начиная от тетрисов и заканчивая драйверами, от субд до хакерских утилит пиется на основе "харакири ресурсных объектов", либо идея провалится. while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();}; | Скажи .net корпорации Microsoft! (c) ghostwolf 2004 7 раз поищи в стандартной библиотеке, 1 раз накодь своё. |
| Re[5]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | fddima | |
| Дата: | 08.12.04 06:22 |
| Здравствуйте, Mamut, Вы писали: M>А сколько раз я об этом говорил Автор: Mamut Дата: 03.12.04 Ну простите мужики, не сдержался ... << RSDN@Home 1.1.4 beta 3 rev. 241>> |
| Re[18]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 08.12.04 07:15 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, AVC, Вы писали: AVC>>Поэтому именно в Обероне перезагрузка модуля может быть реализована самым простым образом. К>Кстати, как? Есть встроенное API? Модуль это объект? Есть какой-то рефлекшн? System.Free BadModule Впрочем перезагрузка модуля тоже не спасет, ведь BugIt создаст новую ошибку. |
| Re[3]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 08.12.04 09:38 |
| Здравствуйте, SilverCloud, Вы писали: SC>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Здравствуйте, SilverCloud, Вы писали: СГ>>>>была создана операционная система Aos BlueBottle, в которой поверх железа работает вовсе не ядро операционки, а runtime system языка Active Oberon SC>>>В чём разница, кроме названия? СГ>>Разница между кем и кем? SC>Между "ядро операционной системы" и runtime system языка Active Oberon SC>ЗЫ А Вы о чём подумали? А Вы об этом. Я просто не понял вопроса. Вот смотрите. Есть низкоуровневые языки — ассемблеры, есть "не очень" высокоуровневые языки типа Си, Паскаль, Модула. Приставкой "не очень" я обозначил то, что программы на этих языках работают непосредственно поверх железа. На таких языках можно написать операционную систему. Есть "очень" высокоуровневые языки типа Java, C# — они не могут работать поверх обычного железа, а требуют наличия сложной рантайм системы. Традиционно, операционные системы пишут на "не очень" высокоуровневых языках (или вообще на ассемблерах), а уже поверх операционных систем пишут рантайм системы (или виртуальные машины) для "очень" высокоуровневых языков типа Java, C# и т.д. Так вот, я имел ввиду то, что для языка Active Oberon удалось реализовать рантайм систему работающую непосредственно поверх железа. Это наделило программы написанные на "очень" высокоуровневом языке Active Oberon возможностью исполняться поверх железа подобно тому как это происходит с программами написанными на ассемблерах, Си, Паскале, Модуле и т.д. А раз так, то появилась возможность написать саму операционную систему не на "не очень" высокоуровневых языках или ассемблерах, а сразу на "очень" высокоуровневом языке Active Oberon. А так как сам язык Active Oberon — безопасный, то в операционной системе написанной на нем уже не было нужды вводить дополнительные механизмы безопасности навроде виртуальных адресных пространств для каждого процесса и связанных с этим тормозов по переключению контекстов процессов, копирования объектов из разных адресных пространств и т.п. В результате, получившаяся операционка оказалась в несколько раз эффективнее Linux. Например, время минимального системного вызова (в Linux оно связано со временем переключения контекстов процессов) в Aos BlueBottle примерно в 30 раз быстрее чем в Linux. Подробнее об архитектуре Aos BlueBottle написано в докторской диссертации ее главного создателя Питера Мюллера: http://e-collection.ethbib.ethz.ch/cgi-bin/show.pl?type=diss&nr=14755 Сам Питер Мюллер: http://www.cs.inf.ethz.ch/~muller/ |
| Re[6]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 08.12.04 09:52 | |
| Оценка: | 1 (1) +2 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Кто должен удалить цепочку объектов FileInfo? Сам модуль с процедурой FileList не может нести ответсвенность за удаление созданной им цепочки объектов, так как не знает пользуются ими кто-то или нет. Пользовательский модуль тоже не может удалить полученную цепочку так как не знает скольким еще другим модулям была выдана эта же самая цепочка объектов и пользуются ли они ею. Итак, ни один из модулей не может принять решение об удалении этой цепочки. Остается только рантайм среда — вот она и удалит, только она знает все обо всех объектах! А, то есть до того как были написаны сборщики мусора задача реализации двусвязного списка была неразрешима? Ну-ну... P.S. Старик, могу ошибаться, но у тебя тут явный про... в дизигне. как собственно и вообще у теюя про... в области програмиминга и того что щас есть а чего нет. Мой тебе скромный совет — ну почитай книжек, попедаль сам программулины, посмотри что как работает. Вот тогда и посмотрим будут ли от тебя появляться одиозные разоблачительные топики с громкими названиями. А то блин ну я просто в атасе — человек как с другой планеты... Удачи тебе, браток! | |
| Re[16]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 08.12.04 09:53 |
| Здравствуйте, Кодт, Вы писали: К>1) Поток зациклился в недрах. И между прочим, подвесил всю цепочку вызовов от самого основания (некоего активного объекта). К>Потеря ссылок извне на активный объект — должна останавливать поток или не должна? Должна делать это аварийно или есть какой-то механизм мягкого выхода? Простите, я не знаю как это реализовано в Aos BlueBottle, поэтому ответить не могу. К>1.1) Если на стеке активного объекта есть ссылки на этот объект — что будет делать сборщик мусора? Ему все равно где ссылки, главное что они больше никому внешнему недоступны. К>2) Модуль оказался повреждён. Все активные объекты, взаимодействующие с этим модулем, будут подвешиваться и в будущем, пока модуль не перезагрузится. Когда это случится? Это опять технические детали о которых я не могу дать ответа — не знаю. Мне мерещится, что надо будет специльно вызвать системную процедуру выгрузки модуля. К>3) Модуль — это объект? Или нужно вручную делать объекты с моделью ПерезагружаемыйСервис? Модуль — это модуль, его пишут, потом компилируют, потом запускают на выполнение. Объект — некая специфическая абстракция времени исполнения. Модуль — это НЕ объект. Но во время исполнения о некоторых модулях можно думать как об объектах-синглетонах, модули могут исполнять и эту роль. |
| Re[18]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 08.12.04 10:05 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, AVC, Вы писали: AVC>>Поэтому именно в Обероне перезагрузка модуля может быть реализована самым простым образом. К>Кстати, как? Есть встроенное API? Модуль это объект? Есть какой-то рефлекшн? Я не знаю как это в других Оберонах, но в черной коробке так:
Правда есть один трабл. Если в памяти загружены какие-то другие модули использующие этот, то сначала, естественно, надо выгрузить их — это естественно так как они все же динамически слинкованы и надо всю эту линковку разрушить подобно тому как надо разобрать всю верхнюю часть пирамиды из кубиков чтобы добраться до кубика из середины пирамиды. Соответственно, выгрузка модуля из "основания пирамиды импорта модулей" практически подобна перезагрузке всей системы. |
| Re[7]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 08.12.04 10:24 | |
| Оценка: | +1 -1 | |
| Здравствуйте, Glоbus, Вы писали: G>А, то есть до того как были написаны сборщики мусора задача реализации двусвязного списка была неразрешима? Ну-ну... G>P.S. Старик, могу ошибаться, но у тебя тут явный про... в дизигне. Нет не ну-ну, а была разрешима с помощью специального дизайна. Для каждой кучки объектов надо было дополнительно вводить специальный объект-агрегат и т.д. Дерево агрегирования одних объектов другими — вот каков был дизайн программ без сборщика мусора. Вы действительно ошибаетесь на счет про... т.е. "некачественного" дизайна — в языках со сборщиком мусора в старом дизайне больше нет необходимости. Пришло время более эффективных алгоритмов. Хотелось бы почитать книжки с описанием алгоритмов (и паттернов проектирования) ориентированных на эксплуатацию сборщика мусора. Но я таких еще не видел. Наверное ломка сознания при переходе к языкам программирования с ГЦ чрезмерна сильна и люди, на "автопилоте" продолжают использовать старые алгоритмы/паттерны ориентированные на ручное удаление объектов или в крайнем случае на подсчет ссылок. Это же элементарно! При наличии ГЦ, процедура возвращающая цепочку объектов во всех отношениях — более эффективна и удобна чем процедура возвращающая объект-агрегат той цепочки объектов. Кстати этот пример придумал не я, а взял его из системы BlackBox, модуль Files. |
| Re[17]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 08.12.04 10:25 |
| Здравствуйте, Сергей Губанов, Вы писали: К>>1.1) Если на стеке активного объекта есть ссылки на этот объект — что будет делать сборщик мусора? СГ>Ему все равно где ссылки, главное что они больше никому внешнему недоступны. Круто! Т.е. стек активного объекта включён в граф зависимостей этого объекта? Да, тут, похоже, без виртуальной машины не обойтись. Хотя... можно и на native платформе, просто регистрировать каждую переменную-указатель в контексте текущего потока (про который известно, к какому объекту он принадлежит). К>>2) Модуль оказался повреждён. Все активные объекты, взаимодействующие с этим модулем, будут подвешиваться и в будущем, пока модуль не перезагрузится. Когда это случится? СГ>Это опять технические детали о которых я не могу дать ответа — не знаю. Мне мерещится, что надо будет специльно вызвать системную процедуру выгрузки модуля. К>>3) Модуль — это объект? Или нужно вручную делать объекты с моделью ПерезагружаемыйСервис? СГ>Модуль — это модуль, его пишут, потом компилируют, потом запускают на выполнение. Объект — некая специфическая абстракция времени исполнения. Модуль — это НЕ объект. Но во время исполнения о некоторых модулях можно думать как об объектах-синглетонах, модули могут исполнять и эту роль. А почему бы и нет? Ведь что такое модуль: — с т.з. компилятора — это набор типов и сигнатур — с т.з. загрузчика — набор точек привязки (экспортируемые переменные, функции и внутренние структуры) — с т.з. рантайма — набор статических переменных Вполне можно представить как объект-синглетон некоего класса со вложенными классами, методами и т.д. Другое дело, что язык может не поддерживать представление модуля как объекта, или предоставлять минимальные операции над ним (загрузить по имени, выгрузить, и т.п. — как, например, API для работы с DLL — ведь они тоже являются объектами ОС). Перекуём баги на фичи! |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 08.12.04 10:45 | |
| Оценка: | 1 (1) +3 | |
| Здравствуйте, Сергей Губанов, Вы писали: G>>А, то есть до того как были написаны сборщики мусора задача реализации двусвязного списка была неразрешима? Ну-ну... G>>P.S. Старик, могу ошибаться, но у тебя тут явный про... в дизигне. СГ>Нет не ну-ну, а была разрешима с помощью специального дизайна. Для каждой кучки объектов надо было дополнительно вводить специальный объект-агрегат и т.д. Дерево агрегирования одних объектов другими — вот каков был дизайн программ без сборщика мусора. Согласен насчёт этого. Однако. Сам по себе двусвязный список как совокупность узлов и связей — это баловство. В дизайне программы наверняка присутствует более высокоорганизованная сущность — например, двухпортовая очередь. В этом случае пользователю мало интересно, что там у неё внутри. К примеру, дек (список массивов) более эффективно воплощает очередь. Или граф/орграф. В разных ситуациях удобно иметь его представление в виде матрицы смежности, инцедентности, отдельных вершин, отдельных рёбер. Привязываться же к представлению ребра как указателя на вершину — означает здорово осложнить себе жизнь при расширении функциональности. СГ>Вы действительно ошибаетесь на счет про... т.е. "некачественного" дизайна — в языках со сборщиком мусора в старом дизайне больше нет необходимости. Пришло время более эффективных алгоритмов. Хотелось бы почитать книжки с описанием алгоритмов (и паттернов проектирования) ориентированных на эксплуатацию сборщика мусора. Но я таких еще не видел. Наверное ломка сознания при переходе к языкам программирования с ГЦ чрезмерна сильна и люди, на "автопилоте" продолжают использовать старые алгоритмы/паттерны ориентированные на ручное удаление объектов или в крайнем случае на подсчет ссылок. СГ>Это же элементарно! При наличии ГЦ, процедура возвращающая цепочку объектов во всех отношениях — более эффективна и удобна чем процедура возвращающая объект-агрегат той цепочки объектов. Кстати этот пример придумал не я, а взял его из системы BlackBox, модуль Files. Это тоже спорный момент. Если цепочка объектов — это очередь, то обращение к голове/хвосту займёт O(1) при наличии объекта-агрегата и O(N) без него. Подсчёт размера — тоже... Всё зависит от решаемых задач. Мне больше симпатична идея контейнеров и итераторов как способу абстрагирования от внутреннего устройства. Причём, надо заметить — сборка мусора к этому отношения не имеет. Есть реализации этого паттерна на Питоне, например. Перекуём баги на фичи! |
| Re[19]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 08.12.04 11:52 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Правда есть один трабл. Если в памяти загружены какие-то другие модули использующие этот, то сначала, естественно, надо выгрузить их — это естественно так как они все же динамически слинкованы и надо всю эту линковку разрушить подобно тому как надо разобрать всю верхнюю часть пирамиды из кубиков чтобы добраться до кубика из середины пирамиды. Соответственно, выгрузка модуля из "основания пирамиды импорта модулей" практически подобна перезагрузке всей системы. Вот она, беда графа связей в системе с автоматической загрузкой-выгрузкой (сборкой мусора На деле, для решения исходной задачи достаточно предусмотреть процедуру инициализации модуля, и вызывать её не только из BEGIN-END ModuleName, но и извне. А для замены модуля на лету — нужен модуль-прокси, все связи которого с исходным — динамические и могут быть корректно разорваны/восстановлены. Перекуём баги на фичи! |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 08.12.04 13:16 | |
| Оценка: | 1 (1) +4 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Glоbus, Вы писали: G>>А, то есть до того как были написаны сборщики мусора задача реализации двусвязного списка была неразрешима? Ну-ну... G>>P.S. Старик, могу ошибаться, но у тебя тут явный про... в дизигне. СГ>Нет не ну-ну, а была разрешима с помощью специального дизайна. Для каждой кучки объектов надо было дополнительно вводить специальный объект-агрегат и т.д. Дерево агрегирования одних объектов другими — вот каков был дизайн программ без сборщика мусора. Вы действительно ошибаетесь на счет про... т.е. "некачественного" дизайна — в языках со сборщиком мусора в старом дизайне больше нет необходимости. Пришло время более эффективных алгоритмов. Очень хорошее заявление. прямо девиз. Ваще то алгоритмы пораждаются не как результат того, придумали ли новый способ убивать объекты или нет, а как необходимость решить задачу существующими методами. До тех пор, пока существующие алгоритмы будут устраивать — они будут существовать. Далее. Я не совсем понимаю почему алгноритмы со сборщиком мусора будут более эффективны. И каков их кретерий эффективности? Скорость? Вряд ли. Могу ошибаться, но недетерменированность запуска этого самого сборщика мусора затрудняет временную оценку эффективности всего алгоритма. Память? Тоже вряд ли. Все-таки как ни крути а мертвые объекты до запуска гц в памяти висят. То есть единственный реальный плюс — отсутсвие необходимости пристально следить за ресурсами — типа и так все само собой склеится. Но посему могу только сказать (это чисто мое субъективное мнение) что такой подход закладывает плохие тенденции в программинге. Люди отучаются думать и ищут компонент ТПрограммер. Все-таки человек который имеет хороший опыт педалинга в среде с неуправляемыми ресурсами скорее всего быдет иметь более высокую квалификацию нежели человек, который всегад полагался на какие-то внешние средства, которые должны сделать за него некоторую работу (мое мегасубъективное старперское мнение Если немного отвлечся от гц, то можно вспоминть что все те алгоритмы, которые щас используются в програминге были придуманы в прошлом веке, годах в 40-50х когда компы были просто беспредельно тормозные по сравнению с существующими. Сейчас даже такая тачка как первый пень это просто океан в сравнении с тем что было тогда. И на тех машинах алгоритмы показали свою эффективность с точки зрения быстродействия/ресурсов. Поэтому могу скромно сделать вывод (лично мой, субъективный) что при теперешнем развитии железа нет никаких оснований отказываться от тех алгоритмов, которые эффективно работали на более слабых тачках. Их сочитание с существующим железом только поднимет эффективность. А вот алгоритмы с упором на гц — вот тут я лично сомневаюсь, что стоит искать какие-то "новые" аллгоирмы... Буду рад выслушать любого, кто захочет меня переубедить СГ>Хотелось бы почитать книжки с описанием алгоритмов (и паттернов проектирования) ориентированных на эксплуатацию сборщика мусора. Но я таких еще не видел. Наверное ломка сознания при переходе к языкам программирования с ГЦ чрезмерна сильна и люди, на "автопилоте" продолжают использовать старые алгоритмы/паттерны ориентированные на ручное удаление объектов или в крайнем случае на подсчет ссылок. А я думаю их (книжки эти,Ю заточенные под гц ) никто писать и не будет, потому что все те же идиомы прекрасно используются и в системах с гц. Что касатестя паттернов проектирование так это как пить дать — это ваще абстаркции очень высокого уровня и плевать они хотели на то есть гц или нет. СГ>Это же элементарно! При наличии ГЦ, процедура возвращающая цепочку объектов во всех отношениях — более эффективна и удобна чем процедура возвращающая объект-агрегат той цепочки объектов. Кстати этот пример придумал не я, а взял его из системы BlackBox, модуль Files. Что значит процедура возвращает цепочку объектов... Я че-то не врубаюсь — она возвращает указатель на первый объект, или она возвращает некоторую коллекцию..? Если так стоит вопрос, то коллекция а-ля стл будет приятнее — всякие там итераторы и т.п. Да и с логической точки зрения это удобней, чем вспоминать, что это у тебя не прост оуказатель на единичный объект, а за ним тянутся еще о-го-го сколько таких же объектов. Удачи тебе, браток! | |
| Re[4]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 08.12.04 13:29 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Да. Сборщик мусора необходим. Это уже тут обсуждалось. Вкратце: только в момент выполнения программы можно принять решение об освобождении памяти. В момент написания исходного кода каждого отдельного модуля невозможно принять решение о расставлении на каждый new соответсвующий delete — эта задача статически неразрешима, ее надо решать динамически в рантайме, а это как раз и называется термином "сборка мусора". Сборка мусора — это не роскошь, а суровая необходимость для построения модульных расширяемых систем. Да ну ладно... как-то писали 40 лет без сборщика мусора и ничег острашного не случалось. Да, никто не спорит вещь полезная — но то чно он необходим — большой вопрос. Смарт-поинтеры решают ту же задачу весьма элегантно. СГ>Виндос не компонентная. Компоненты о которых говорите Вы живут ПОВЕРХ виндозы. Именно поверх виндозы работают различные компонентные среды исполнения, будь-то среда COM или среда NET. Это тоже уже обсуждалось. СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=777078&only=1 Автор: S.Yu.Gubanov Дата: 24.08.04 А можно дать определение компонента. Чтоб я глядя на нечто смог определить компонент это или нет. J>> Более того, если Винда является компонентной, зачем .НЕТ быть компонентным СГ>.НЕТ, вообще говоря, тоже не компонентная (хоть у некоторых эта фраза вызывает бурный взрыв эмоций), компонетность о которой говорят применительно к .НЕТ на самом деле находится внутри каждого процесса, но не всего .НЕТ целиком. Каждый отдельный процесс работает в своем собственном .НЕТ окружении, оно, конечно, компонентно, но в целом .НЕТ ни в коем случае не компонентен. Об этом я написал там (почему-то над этим многие смеялись): СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=927544&only=1 Автор: Сергей Губанов Дата: 02.12.04 А нет такой твари как ".НЕТ вцелом". Это равносильно тому что сказать типа да, некоторые стулья являются мебелью, но вцелом стул это никак не мебель. Какой-то несрост СГ>Оберон системы это единственный известный мне пример модульных расширяемых систем. Других примеров я просто не знаю, вот и привожу только его. Так как я постоянно привожу в пример только Оберон системы, то меня тут некоторые товарищи стали считать религиозным фанатиком этого Оберона. Простите, но я просто еще других подобных систем не видел, вот и все объяснение. Знал бы, привел бы другие примеры тоже... Дай определение модульной расширяемой системы Удачи тебе, браток! | |
| Re[5]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 08.12.04 14:15 |
| Здравствуйте, Glоbus, Вы писали: СГ>>...Сборка мусора — это не роскошь, а суровая необходимость для построения модульных расширяемых систем. G>Да ну ладно... как-то писали 40 лет без сборщика мусора и ничег острашного не случалось. Да, никто не спорит вещь полезная — но то чно он необходим — большой вопрос. Смарт-поинтеры решают ту же задачу весьма элегантно. Смарт поинтеры живут только внутри одного (бинарного) модуля. А я говорил о модульной системе, т.е. когда много модулей (быть может от разных производителей) взаимодействуют друг с другом. Если мы ограничиваем множество программ программами состоящими всего из одного единственного EXE-шника (модуля), то сборщик мусора не нужен, а вот в модульных системах он нужен, хотя бы для безопасности/стабильности/устойчивости/целостности всей модульной расширяемой системы. СГ>>Виндос не компонентная. Компоненты о которых говорите Вы живут ПОВЕРХ виндозы. Именно поверх виндозы работают различные компонентные среды исполнения, будь-то среда COM или среда NET. Это тоже уже обсуждалось. СГ>>http://www.rsdn.ru/Forum/Message.aspx?mid=777078&only=1 Автор: S.Yu.Gubanov Дата: 24.08.04 G> А можно дать определение компонента. Чтоб я глядя на нечто смог определить компонент это или нет. G> Дай определение модульной расширяемой системы Дык, я же это в указанной ссылке уже как бы пытался дать. Что опять заново все давать? Нет я устал уже. |
| Re[5]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 08.12.04 14:43 | |
| Оценка: | 13 (2) | |
| Здравствуйте, Glоbus, Вы писали: G>А можно дать определение компонента. Чтоб я глядя на нечто смог определить компонент это или нет.
|
| Re[20]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 08.12.04 15:14 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Правда есть один трабл. Если в памяти загружены какие-то другие модули использующие этот, то сначала, естественно, надо выгрузить их — это естественно так как они все же динамически слинкованы и надо всю эту линковку разрушить подобно тому как надо разобрать всю верхнюю часть пирамиды из кубиков чтобы добраться до кубика из середины пирамиды. Соответственно, выгрузка модуля из "основания пирамиды импорта модулей" практически подобна перезагрузке всей системы. К>Вот она, беда графа связей в системе с автоматической загрузкой-выгрузкой (сборкой мусора К>На деле, для решения исходной задачи достаточно предусмотреть процедуру инициализации модуля, и вызывать её не только из BEGIN-END ModuleName, но и извне. К>А для замены модуля на лету — нужен модуль-прокси, все связи которого с исходным — динамические и могут быть корректно разорваны/восстановлены. только такая концепция нарушает гомогенность системы и она поэтому сразу перестает быть компонентной системой в понимании Сергея Губанова.
|
| Re[20]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 08.12.04 17:03 |
| Здравствуйте, Кодт, Вы писали: К>Вот она, беда графа связей в системе с автоматической загрузкой-выгрузкой (сборкой мусора К>На деле, для решения исходной задачи достаточно предусмотреть процедуру инициализации модуля, и вызывать её не только из BEGIN-END ModuleName, но и извне. К>А для замены модуля на лету — нужен модуль-прокси, все связи которого с исходным — динамические и могут быть корректно разорваны/восстановлены. А если нужно перезагрузить сам модуль-прокси? И чем поможет прокси, если данные модуля, которым он "управляет" (например, какая-нибудь таблица), неверны или утрачены в результате перезагрузки? Мне кажется, что модуль-прокси — не всегда выход. Кроме того, как мне кажется, не всегда нужно выгружать модули, использующие перезагружаемый нами модуль. Это только одно из возможных решений (самое простое). При определенных обстоятельствах (например, модуль экспортирует не переменные, а только тип данных) достаточно перезагрузить "испортившийся" модуль на прежнее место. Хоар |
| Re[21]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 08.12.04 17:33 |
| Здравствуйте, Кодт, Вы писали: К>Вот она, беда графа связей в системе с автоматической загрузкой-выгрузкой (сборкой мусора К>На деле, для решения исходной задачи достаточно предусмотреть процедуру инициализации модуля, и вызывать её не только из BEGIN-END ModuleName, но и извне. К>А для замены модуля на лету — нужен модуль-прокси, все связи которого с исходным — динамические и могут быть корректно разорваны/восстановлены. Мне кажется, что мы рассматриваем вопрос о перезагрузке модуля слишком абстрактно. Непонятно, почему его потребовалось перезагружать (обычно это делается после того, как модуль был модифицирован программистом и перекомпилирован), кто (что) определил потребность в перезагрузке, к каким последствиям приведет эта перезагрузка для импортирующих модулей. Например, компилятор (состоящий из разных модулей) использует таблицу имен (модуль). По каким-то неясным причинам модуль требуется перезагрузить. Допустим, мы используем прокси-модуль, управляющий модулем таблицы имен. Даем ему команду: перезагрузить модуль таблицы имен, что он успешно и делает. Но все импортирующие его модули компилятора были "завязаны" на данные таблицы имен. И какой смысл оставлять их не перезагруженными, если данные, которыми они пользовались, уже утрачены? Возможно, я упустил что-то важное из виду? У меня предложение. Давайте рассмотрим эту ситуацию (пусть и вымышленную) поподробнее. Хоар |
| Re[22]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | _vovin | http://www.smalltalk.ru |
| Дата: | 08.12.04 17:42 |
| AVC wrote: > Здравствуйте, Кодт, Вы писали: > > К>Вот она, беда графа связей в системе с автоматической загрузкой-выгрузкой (сборкой мусора > К>На деле, для решения исходной задачи достаточно предусмотреть процедуру инициализации модуля, и вызывать её не только из BEGIN-END ModuleName, но и извне. > К>А для замены модуля на лету — нужен модуль-прокси, все связи которого с исходным — динамические и могут быть корректно разорваны/восстановлены. > > Мне кажется, что мы рассматриваем вопрос о перезагрузке модуля слишком абстрактно. > Непонятно, почему его потребовалось перезагружать (обычно это делается после того, как модуль был модифицирован программистом и перекомпилирован), кто (что) определил потребность в перезагрузке, к каким последствиям приведет эта перезагрузка для импортирующих модулей. > Например, компилятор (состоящий из разных модулей) использует таблицу имен (модуль). По каким-то неясным причинам модуль требуется перезагрузить. Допустим, мы используем прокси-модуль, управляющий модулем таблицы имен. Даем ему команду: перезагрузить модуль таблицы имен, что он успешно и делает. Но все импортирующие его модули компилятора были "завязаны" на данные таблицы имен. И какой смысл оставлять их не перезагруженными, если данные, которыми они пользовались, уже утрачены? > Возможно, я упустил что-то важное из виду? > У меня предложение. Давайте рассмотрим эту ситуацию (пусть и вымышленную) поподробнее. картина станет проще, когда вы хорошо сформулируете, что же вы действительно хотите; именно перезагрузку (т.е. выгрузку-загрузку) или апдейт модуля на лету? Posted via RSDN NNTP Server 1.9 delta |
| Re[23]: Не надо явно передавать! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Волк-Призрак | http://ghostwolf.newmail.ru |
| Дата: | 08.12.04 20:29 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Mr. None, Вы писали: СГ>Чистой архитектуры добился за счет механизма агрегирования. MainForm агрегирует Factory, та агрегирует Environment, та агрегирует Log, DocumentContainer, ***Environment и т.д. Всего в дереве агрегации около сотни разных элементов. Когда какому-то объекту что-то нужно такое что он сам делать не умеет, то он запрашивает соответсвующую услугу у своего агрегата — агрегаты есть у всех, кроме MainForm — корневой агрегат. Кстати, сам агрегированный объект понятия не имеет кто конкретно его в данный момент агрегирует, для него он просто IAggregate. А я (в Java) сделал все объекты базовыми от Logable, у которого статические и персональне методы есть. обращающиеся к экземпляру объекта, реализующего интерфейс Logger. Что касается runtime-мутаций, то я както в попытке написать mutable-движок (в Delphi) применил такую "модель": есть пониятия: *EngineObject — объект, он состоит из динамически изменяемого набора EngineObjectPlug. *EngineObjectPlug — элемент объекта, несуший смысловую/функциональную нагрузку, предоставляя массивы объектов EngineProperty и EngineAction. *EngineObjectProperty — свойство объекта. *EngineObjectAction — пародия типа на методы. *EngineActionParameters -типа "параметры вызова методов". такие объекты используешь, вызывая setProperty,getProperty,useProperty (даёт объект свойства для быстрого неоднократного использования, скаем в инструкции with ... до). Похожая картина для действий: performAction и getAction. Объекты хранят ссылку на свой "класс". "Классы" "помнят", какие объекты они создавали. Когда в "классе" меняется (в рантайме!) сеть множественного наследования, то соответственно он к созданным собой объектам добавляет соответствующие EngineObjectPlug. или удаляет, если класс-предок убрали а не добавили. Причём он просто говорит дереву движковы объектов: "выдерни все штыри типа ClassName" или наоборот: "там где есть plug типа this_class, вставь штырь типа new_ancestor_className. Естественно всё это было сделано поламерски, без расчёта на многопотосность..... Зато множественное наследование в Delphi while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();}; | Скажи .net корпорации Microsoft! (c) ghostwolf 2004 7 раз поищи в стандартной библиотеке, 1 раз накодь своё. |
| Re[21]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 09.12.04 08:13 | |
| Оценка: | +1 | |
| Здравствуйте, jazzer, Вы писали: J>только такая концепция нарушает гомогенность системы и она поэтому сразу перестает быть компонентной системой в понимании Сергея Губанова. Ничего подобного. Прокси-модуль — это такойже модуль как и все остальные модули. Вот тривиальная реализация:
Пусть все пользуются модулем FunctionProxy, а о модуле FunctionImplementer пусть никто не знает. Тогда можно будет на лету перезагрузить модуль FunctionImplementer не выгружая все остальные модули. |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | e-Xecutor | |
| Дата: | 09.12.04 08:23 | |
| Оценка: | -2 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Это же элементарно! При наличии ГЦ, процедура возвращающая цепочку объектов во всех отношениях — более эффективна и удобна чем процедура возвращающая объект-агрегат той цепочки объектов. Кстати этот пример придумал не я, а взял его из системы BlackBox, модуль Files. Сергей.... А ты знаешь, что такое GC? Точнее что он делает. Ты не поверишь, он так или иначе делает подсчёт ссылок!!! |
| Re[9]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 09.12.04 09:53 | |
| Оценка: | +1 | |
| Здравствуйте, e-Xecutor, Вы писали: EX>Сергей.... А ты знаешь, что такое GC? EX>Точнее что он делает. EX>Ты не поверишь, он так или иначе делает подсчёт ссылок!!! Необязательно. Достаточно не считать, а раскрашивать. Перекуём баги на фичи! |
| Re[6]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 09.12.04 10:02 | |
| Оценка: | 17 (2) +2 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Смарт поинтеры живут только внутри одного (бинарного) модуля. А я говорил о модульной системе, т.е. когда много модулей (быть может от разных производителей) взаимодействуют друг с другом. Если мы ограничиваем множество программ программами состоящими всего из одного единственного EXE-шника (модуля), то сборщик мусора не нужен, а вот в модульных системах он нужен, хотя бы для безопасности/стабильности/устойчивости/целостности всей модульной расширяемой системы. Да какая разница ваще где живут смарт поинтеры. Неужто не ясно, что то как управляется память — это ваще вопросы к модульности и расширяемости не относящиеся. Вот сомтри. Есть у тебя набор серваков, которые между собой распределяеют нагрузку (например видеоконференции). Они кстати тоже являются модульной и расширяемой системой, даже несмотря на то что нет некоего единого механизма управления их ресурсами. И проведе теперь паралель с длл-нами, в которых живут смарт-понитеры СГ>Дык, я же это в указанной ссылке уже как бы пытался дать. Что опять заново все давать? Нет я устал уже. Да, сто пуд — там есть И так, здравствуйте, Сеогей Губанов, вы писали
Абсолютно верная аналогия с автомобилем. Колеса и всякая там остальная ботва вроде шаровых и сайлент-блоков есть модули/комопненты. Но в чем же проявлется модульность и компонентность автомобиля? Прав-виль-но! В том что каждая эта часть может быть заменена без изменений в других частях системы. А вот насчет любой части большой программы ты уважаемый промахнулся. Все на самом деле зависит от части. Если например программа юзает ком-объект, то он есть модулем, заменяемым компонентом этой программы. Потому что можно абсолютно ничего не делая с самой программой заменить 1 длл-ну и все будет пахать как и пахало. Расширяемость? Пожалуйста! Если в программе предусмотрено, что может быть подключено некоторое(или неограниченное) число этих самых длл-ин то мы опять получаем расширяемую систему. И не важно кто и как управляет памяью!!! НЕ ВАЖНО! Это к вопросу модульности никак не относится.
Неправильное определение на мой взгляд. Во-первых при чем тут единая среда исполнения. Пример. Есть сервер поддерживающий видеоконференции. В архитектуре этого сревера заложено, что он может быть установлен на нескольких машинах, которые в случае необходимости распределяют между собой нагрузку. Система модульная? Модульная — потому что состоит из частей. Где тут единая среда исполнения? На каждой физической машине есть своя операционка, в среде которой и выполняется отдельный экземпляр приложения. Но логически они связаны меджду собой, и обмениваются данным по специальному протоколу по сетке. И таких серверов ставить можно хоть мильйон. То есть расширяемость налицо. Далее. Вот это полный атас
Нет, дорогой мой друг. Как я уже говорил выше, по моему скромному убеждению модуль это часть, которая может быть заменена или удалена из системы таким образом, что нет необходимости затрагивать или вностиь изменения в другие части. Это отностися на мой взгляд ваще к любой системе — от программы до космического корабля или автомобиля. А вот эт ополная ботва
При чем тут среды исполнения!!!! При чем тут языки. Винда и никсы являются компонентны если можно спокойно удалить или изменить некоторую их часть. Мы же можем ставить драйвера, сносить их, ставить какие-нить примочки плагины и тп не внося изменения в то, что у нас щас есть — все, этого достаточно для модульности. Далее имеем
Могу ошибаться но модуль — это синоним компонента. А утебя выходит что коммунизм это власть советов + электрификация всей старны. ООП это ваще только парадигма программирования. На месте нее могла быть любаая другая. К комопнентности эта парадигма не имеет никакого отношения. Одна длл-на может быть написана на с++ а другая на чистом с. Но от этого они не перестают быть модулями/компонентами. Резюмируем. Дальше писать не стал потому что готов спорить буквально с каждой буквой того что там у тебя написано. Скажу только одно. Во время нашего диспута поймал сбея на мысли что ты не ориентируешся в простых понятиях (даже не из области программинга) — это не наезд ни в коем рази — это просто озвучивание того, что подумалось/взгрустнулось. так вот я не совсем себе представляю, как человек, который дает такие определения модульности/компонентности защитил кандидатскую по физике. То есть мысли конечно есть но они обидные и не хочу говорить тут , чтоб никого не обижать ... — это все мое мегасубъективное мнение Удачи тебе, браток! | |
| Re[6]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 09.12.04 10:33 |
| Здравствуйте, Трурль, Вы писали: Т>Здравствуйте, Glоbus, Вы писали: G>>А можно дать определение компонента. Чтоб я глядя на нечто смог определить компонент это или нет. Т>
Воооооооот! Ни слова о среде исполнения, сборке мусора и тп!!!! Удачи тебе, браток! | |
| Re[7]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 09.12.04 12:05 |
| Здравствуйте, Glоbus, Вы писали: G>Далее имеем G>
G>Могу ошибаться но модуль — это синоним компонента. А утебя выходит что коммунизм это власть советов + электрификация всей старны. G>ООП это ваще только парадигма программирования. На месте нее могла быть любаая другая. К комопнентности эта парадигма не имеет никакого отношения. Одна длл-на может быть написана на с++ а другая на чистом с. Но от этого они не перестают быть модулями/компонентами. Насколько я понимаю, Сергей все время имеет в виду расширяемую систему. Отсюда и ООП. Чтобы тип, определенный в одном модуле, можно было расширить (=наследовать) в другом. ООП самый простой способ это сделать. Поэтому и получается: G>Компонентная система = Модульная система + ООП. Хоар |
| Re[23]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 09.12.04 12:34 |
| Здравствуйте, _vovin, Вы писали: >> У меня предложение. Давайте рассмотрим эту ситуацию (пусть и вымышленную) поподробнее. _>картина станет проще, когда вы хорошо сформулируете, что же вы _>действительно хотите; _>именно перезагрузку (т.е. выгрузку-загрузку) или апдейт модуля на лету? Вот я и хочу, чтобы Кодт, который предложил этот пример с перезагрузкой модуля, немного пояснил эту ситуацию. Хоар |
| Re[10]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | e-Xecutor | |
| Дата: | 09.12.04 12:51 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, e-Xecutor, Вы писали: EX>>Сергей.... А ты знаешь, что такое GC? EX>>Точнее что он делает. EX>>Ты не поверишь, он так или иначе делает подсчёт ссылок!!! К>Необязательно. Достаточно не считать, а раскрашивать. Потому я и написал — "так или иначе" В том смысле, что gc не является каким-то невероятным шаманством, которое магическим образом разом порешает всё проблемы. За всем этим стоят вполне известные алгоритмы, которые можно реализовать и на не-gc-шных языках. |
| Re[24]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 09.12.04 12:56 |
| Здравствуйте, AVC, Вы писали: AVC>Вот я и хочу, чтобы Кодт, который предложил этот пример с перезагрузкой модуля, немного пояснил эту ситуацию. Я имел в виду, в первую очередь, ситуацию, когда модуль перешёл в устойчиво-ошибочное состояние. Хотя и варианты горячей замены тоже интересны (в тот момент я о них не думал). Перекуём баги на фичи! |
| Re[11]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 09.12.04 13:15 |
| Здравствуйте, e-Xecutor, Вы писали: EX>За всем этим стоят вполне известные алгоритмы, EX>которые можно реализовать и на не-gc-шных языках. Вопрос цены, во-первых, и соглашений, во-вторых. О соглашениях: в COM вся работа ведётся с указателями на интерфейсы. Компиляторы С/С++ не мешают работать с голыми указателями и забывать AddRef/Release. Приходится сознательно оборачивать всё что нужно в CComPtr. О цене: Мгновенная сборка, во-первых, спускает лавину — реалтайм идёт нафиг Язык С++ автоматизирует создание и разрушение составных объектов: обход всех членов и под-объектов в конструкторе/деструкторе. Для сборщика мусора с циклическими зависимостями этого недостаточно: необходимо выполнять обход ещё и при раскраске. Т.е. либо мы вручную будем писать метод "обзвонить все члены" для каждого класса, либо будем хранить связи объект-деталь отдельно (в рантайме). Это немного: скажем, односвязный список всех вполне устроит (каждый умный указатель должен держать не только данные, но и указатель на следующий умный указатель агрегата). Но ведь ещё время инициализации такого списка... Перекуём баги на фичи! |
| Re[25]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 09.12.04 13:19 |
| Здравствуйте, Кодт, Вы писали: К>Я имел в виду, в первую очередь, ситуацию, когда модуль перешёл в устойчиво-ошибочное состояние. К>Хотя и варианты горячей замены тоже интересны (в тот момент я о них не думал). Мне же думается, что типов ситуаций, возникающих при переходе какого-нибудь модуля в устойчиво-ошибочное состояние, много, и они требуют разных решений. Иногда допустима и "горячая перезагрузка", надо только точно сформулировать границы применимости такого решения. Кстати, мне понравилась идея Сергея Губанова: не прокси-модуль импортирует "настоящий" модуль, а наоборот. Хоар |
| Re[12]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Serginio1 | http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=2019 |
| Дата: | 09.12.04 13:27 |
| Здравствуйте, Кодт, Вы писали: К>Язык С++ автоматизирует создание и разрушение составных объектов: обход всех членов и под-объектов в конструкторе/деструкторе. Для сборщика мусора с циклическими зависимостями этого недостаточно: необходимо выполнять обход ещё и при раскраске. Т.е. либо мы вручную будем писать метод "обзвонить все члены" для каждого класса, либо будем хранить связи объект-деталь отдельно (в рантайме). Это немного: скажем, односвязный список всех вполне устроит (каждый умный указатель должен держать не только данные, но и указатель на следующий умный указатель агрегата). Но ведь ещё время инициализации такого списка... Все зависит от количества живых объектов. Да и GC совершентствуется. Например write barier в 1.1 и 2.0 по разному срабатывает, особенно при выполнении кода в одной процедуре. Поэтому GC может работать значительно быстрее деструкторов, т.к. при малом количестве живых объектов их дефрагментация займет немного аремени, а при нулевом количестве в молодых поколений просто передвинуть указатель кучи. Проблемы GC начинаются с большого (100 000 ) количества объектов, где он начинает постоянно поддерживать граф объектов, и перестраивать его при изменении ссылок. В общем есть огромное количество премущесв, так и недостатков. |
| Re[12]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 09.12.04 13:32 | |
| Оценка: | 1 (1) | |
| Здравствуйте, Кодт, Вы писали: К>О цене: К>Мгновенная сборка, во-первых, спускает лавину — реалтайм идёт нафиг Real time и с обычной кучей плохо сочетается. Лучше заранее (до работы в real time) отвести память, а указатели сложить в стеки. Тогда отведение памяти будет реализовываться снятием верхнего указателя со стека, а возврат памяти — размещением указателя на вершине стека. Такое решение с real time сочетается лучше. Хоар |
| Re[7]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Волк-Призрак | http://ghostwolf.newmail.ru |
| Дата: | 09.12.04 13:56 |
| Здравствуйте, Glоbus, Вы писали: G>Здравствуйте, Трурль, Вы писали: Т>>Здравствуйте, Glоbus, Вы писали: G>>>А можно дать определение компонента. Чтоб я глядя на нечто смог определить компонент это или нет. Т>>
G>Воооооооот! Ни слова о среде исполнения, сборке мусора и тп!!!! Компонент — всего лишь концепция. Типа алгоритм. Просто некоторые реализации концепции "компонент" могут требовать для своего функционирования определённых свойств среды, но это скорее часть contractually specified interfaces ... Тогда получается, что требование жёсткого контракта становится "мягкой границей" между алгоритмом (понятием "компонента") и реализацией (COM-объекты, DLL, Оберон модули, java-классы...) while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();}; | Скажи .net корпорации Microsoft! (c) ghostwolf 2004 7 раз поищи в стандартной библиотеке, 1 раз накодь своё. |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 09.12.04 14:04 |
| Здравствуйте, AVC, Вы писали: AVC>Насколько я понимаю, Сергей все время имеет в виду расширяемую систему. AVC>Отсюда и ООП. AVC>Чтобы тип, определенный в одном модуле, можно было расширить (=наследовать) в другом. AVC>ООП самый простой способ это сделать. AVC>Поэтому и получается: G>>Компонентная система = Модульная система + ООП. Да, так можно тоже сказать, но все же видется мне что у Сергея слишком узкий взгляд на понятие расширяемости. То есть например и без ооп можно построить расширяемую систему. И больше всего убивает определение этой расширяемой системы. Вот против чего я протестую — против его понятия расширяемости как чего-то со сборщиком мусора. Удачи тебе, браток! | |
| Re[25]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | _vovin | http://www.smalltalk.ru |
| Дата: | 09.12.04 14:10 |
| Кодт wrote: > Здравствуйте, AVC, Вы писали: > > AVC>Вот я и хочу, чтобы Кодт, который предложил этот пример с перезагрузкой модуля, немного пояснил эту ситуацию. > > Я имел в виду, в первую очередь, ситуацию, когда модуль перешёл в устойчиво-ошибочное состояние. > > Хотя и варианты горячей замены тоже интересны (в тот момент я о них не думал). а это уже совершенно другая проблема и решается она другими методами; в частности в Erlang реализована безопасная многозадачность; там процессы являются независимыми единицами, не разделяющими никакие ресурсы; единственный способ обмена данными между процессами является посылка сообщения (в точности так же как в канонической объектной системе посылка сообщения является единственным способом взаимодействия объектов); процесс, вызвавший сбой просто оставляется как есть, вместо него запускается новый процесс; соответствующим образом организовывается и доступ к данным, чтобы новый процесс мог работать как замена старого; вообще любое требование к приложению является проблемой реализации именно этого приложения; другой вопрос как будет поделена ответственность между пользовательским кодом и стандартным рантаймом; в простых случаях рантайм изначально может предоставлять такую поддержку; в сложных, таким как перегрузка модуля, это уже в большей степени задача организации самого приложения; поэтому будет некорректно рассматривать горячую перегрузку модуля применительно к произвольному заранее написанному приложению; Posted via RSDN NNTP Server 1.9 delta |
| Re[22]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 09.12.04 14:37 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, jazzer, Вы писали: J>>только такая концепция нарушает гомогенность системы и она поэтому сразу перестает быть компонентной системой в понимании Сергея Губанова. СГ>Ничего подобного. Прокси-модуль — это такойже модуль как и все остальные модули. СГ>Вот тривиальная реализация: СГ>
СГ>Пусть все пользуются модулем FunctionProxy, а о модуле FunctionImplementer пусть никто не знает. Тогда можно будет на лету перезагрузить модуль FunctionImplementer не выгружая все остальные модули. Но ведь модуль FunctionProxy мы уже не сможем так легко перезагрузить. Это во-первых. А во-вторых, само ограничение других модулей в общении с другим модулем — это нарушение гомогенности. Путем введения проксей ты вводишь в систему иерархичность, и она перестает быть гомогенной. Иначе винда тоже становится компонентной, потому что все общаются с ней через WinAPI и никто не знает о конкретных драйверах, которые загружены в память. И большинство драйверов можно перегрузить на лету (кроме тех, которые вводят жесткие зависимости, но ведь и твой implementer тоже может вводить такие зависимости, котрые потребуют перезагрузки модулей-клиентов несмотря на прокси). Если честно, я не понимаю, почему ты так привязан к этой гомогенности.
|
| Re[9]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 09.12.04 14:57 | |
| Оценка: | 1 (1) | |
| Здравствуйте, Glоbus, Вы писали: G>Здравствуйте, AVC, Вы писали: AVC>>Насколько я понимаю, Сергей все время имеет в виду расширяемую систему. AVC>>Отсюда и ООП. AVC>>Чтобы тип, определенный в одном модуле, можно было расширить (=наследовать) в другом. AVC>>ООП самый простой способ это сделать. AVC>>Поэтому и получается: G>>>Компонентная система = Модульная система + ООП. G>Да, так можно тоже сказать, но все же видется мне что у Сергея слишком узкий взгляд на понятие расширяемости. То есть например и без ооп можно построить расширяемую систему. Возможно, здесь просто терминологическое расхождение? Ведь ООП не привязано именно к ОО языкам. И на Си можно писать объектно-ориентированные программы, и на Обероне (еще самом первом, без type-bound procedures). Мне то как раз кажется (imho, конечно), что расширяемость (как понятие) относится именно к объектной парадигме, является ее специфическим признаком. G>И больше всего убивает определение этой расширяемой системы. Вот против чего я протестую — против его понятия расширяемости как чего-то со сборщиком мусора. Наверное, Сергей имеет в виду, что все компоненты должны соблюдать некие единые "правила игры", иначе система рассыплется. Сборщик мусора (в Обероне) входит в состав этих правил. В других системах, возможно, — нет. Хоар |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 09.12.04 15:01 | |
| Оценка: | 6 (1) | |
| Здравствуйте, AVC, Вы писали: AVC>Насколько я понимаю, Сергей все время имеет в виду расширяемую систему. AVC>Отсюда и ООП. AVC>Чтобы тип, определенный в одном модуле, можно было расширить (=наследовать) в другом. AVC>ООП самый простой способ это сделать. AVC>Поэтому и получается: G>>Компонентная система = Модульная система + ООП. В определении компонена важная часть — "explicit context dependencies only", а наследование зачастую приводит к неявным зависимостям. |
| Re[12]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 09.12.04 15:04 |
| Здравствуйте, Кодт, Вы писали: К>О цене: К>Мгновенная сборка, во-первых, спускает лавину — реалтайм идёт нафиг Это да. Но ведь бывают и более щадящие сборщики мусора. Например, выполняющиеся как фонофый процесс. |
| Re[9]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 09.12.04 15:07 |
| Здравствуйте, Трурль, Вы писали: Т>В определении компонена важная часть — "explicit context dependencies only", а наследование зачастую приводит к неявным зависимостям. В смысле наследования реализации? Или в каком-то ином? Хоар |
| Re[10]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 09.12.04 15:11 |
| Здравствуйте, AVC, Вы писали: AVC>Возможно, здесь просто терминологическое расхождение? AVC>Ведь ООП не привязано именно к ОО языкам. И на Си можно писать объектно-ориентированные программы, и на Обероне (еще самом первом, без type-bound procedures). AVC>Мне то как раз кажется (imho, конечно), что расширяемость (как понятие) относится именно к объектной парадигме, является ее специфическим признаком. Да, тыщу раз прав! G>>И больше всего убивает определение этой расширяемой системы. Вот против чего я протестую — против его понятия расширяемости как чего-то со сборщиком мусора. AVC> AVC>Наверное, Сергей имеет в виду, что все компоненты должны соблюдать некие единые "правила игры", иначе система рассыплется. AVC>Сборщик мусора (в Обероне) входит в состав этих правил. AVC>В других системах, возможно, — нет. Пра! Виль! Но! Сергей просто не видет дальше оберона. Удачи тебе, браток! | |
| Re[13]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 09.12.04 15:19 |
| Здравствуйте, Трурль, Вы писали: К>>Мгновенная сборка, во-первых, спускает лавину — реалтайм идёт нафиг Т>Это да. Но ведь бывают и более щадящие сборщики мусора. Например, выполняющиеся как фонофый процесс. О! Это мысль! Пойду оплодотворю коллектив Перекуём баги на фичи! |
| Re[10]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 10.12.04 08:12 |
| Здравствуйте, AVC, Вы писали: AVC>Здравствуйте, Трурль, Вы писали: Т>>В определении компонена важная часть — "explicit context dependencies only", а наследование зачастую приводит к неявным зависимостям. AVC>В смысле наследования реализации? AVC>Или в каком-то ином? Да, именно наследование реализации. |
| Re[7]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 09:21 | |
| Оценка: | 2 (1) +1 | |
| Здравствуйте, Glоbus, Вы писали: [skip] G> ...Неправильное определение на мой взгляд... [skip] Поскольку понятия "модульность" и "компонентность" можно трактовать очень широко (кто во что горазд), мне, видимо, придется придумать какой нибудь специальный термин для обозначения тех систем, о которых говорю я. Пока я этого термина не придумал, буду пользоваться рабочим термином "по настоящему расширяемая модульная система" сокращенно — ПоНРаМС. Компоненты системы делаются разными производителями. Пользователь собирает из этих компонентов свою систему. Производители физически не могут протестировать свои компоненты на совместимость с компонентами других производителей. Каждый компонент тестируется отдельно. Вся система целиком, собранная конечным пользователем из разных компонентов, НИ КОГДА НЕ ТЕСТИРУЕТСЯ на ЦЕЛОСТНОСТЬ, она ДОЛЖНА РАБОТАТЬ просто по своему определению. Система "по настоящему расширяема" — это когда добавление/удаление/замена компонента (или нескольких компонентов) осуществляется "на лету" (то есть во время ее работы), а также без проверки целостности полученной системы. Каждый компонент тестируется отдельно, а сама система — никогда не тестируется. То есть такого понятия как "фаза финальной интеграции компонентов" просто не существует, хотябы потому, что понрамс никогда не достигает своего финального состояния, а является расширяемой по своему определению. Жизненный опыт подсказывает, что даже если каждый компонент по отдельности работает, то после того как соединить их в систему, то кто же его знает, а вдруг система не заработает, вдруг компоненты несовместимы!!! Так вот, "по настоящему расширяемая модульная система" РАБОТАЕТ ПО ОПРЕДЕЛЕНИЮ. (Если не работает, значит это не она.) Спрашивается, а как этого добиться? Как надо строить "по настоящему расширяемые модульные системы"?????? Дисциплина КОП как раз и изучает вопрос о том как надо строить "по настоящему расширяемые модульные системы". Клеменс Шиперски, в 1995 году предложил следующую формулу для КОП
Без требования "Безопасность" система просто может не заработать, котя каждый компонент в отдельности вроде как исправен. Сборщик мусора — есть техническая деталь необходимая для осуществления безопасности. Шиперски объяснил это в одном абзаце:
Та формула, которую Вы критиковали (КОП = Модульность + ООП) есть в точности тоже самое что предложил Шиперски, с теми оговорками которые я там же и привел. Оригинальная статья Шиперского: Component-Oriented Programming A Refined Variation on Object-Oriented Programming, The Oberon Tribune, Vol 1, No 2, December 1995. |
| Re[23]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 09:30 |
| Здравствуйте, jazzer, Вы писали: J>Путем введения проксей ты вводишь в систему иерархичность, и она перестает быть гомогенной. Ацикличный граф связей между модулями есть иерархия. Все модульные системы иерархические. Я не понимаю что Вы имеете в виду под нарушением гомогенности. Ничего кроме модулей в модульной системе нет — в этом смысле я употребил термин "гомогенная". Это даже похоже на тавтологию: Модульная система состоит из модулей (и ничего кроме модулей в ней нет). |
| Re[8]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 10.12.04 10:51 | |
| Оценка: | +4 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Поскольку понятия "модульность" и "компонентность" можно трактовать очень широко (кто во что горазд), мне, видимо, придется придумать какой нибудь специальный термин для обозначения тех систем, о которых говорю я. Пока я этого термина не придумал, буду пользоваться рабочим термином "по настоящему расширяемая модульная система" сокращенно — ПоНРаМС. О! Новое ругательство. СГ>Жизненный опыт подсказывает, что даже если каждый компонент по отдельности работает, то после того как соединить их в систему, то кто же его знает, а вдруг система не заработает, вдруг компоненты несовместимы!!! Вот именно. СГ>Так вот, "по настоящему расширяемая модульная система" РАБОТАЕТ ПО ОПРЕДЕЛЕНИЮ. (Если не работает, значит это не она.) Ну по определению то она может и работает но вот только не таких... По тому что если ошибка может быть совершена то она будет совершена. А как насажать ошибок в полностью защищенных системах тебе уже показывали не раз. СГ>Спрашивается, а как этого добиться? Как надо строить "по настоящему расширяемые модульные системы"?????? Да накак. Не возможно это. Программ без ошибок не бывает.(я имею в виду программе больше чем "hello world!") СГ>Дисциплина КОП как раз и изучает вопрос о том как надо строить "по настоящему расширяемые модульные системы". Те как строить сферических коней в вакууме? ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[8]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 10.12.04 11:40 |
| Будет ли работать такая система Автор: Mamut :Дата: 03.12.04
Или мы по-разному воспринимаем понятие работающей по умолчанию системы. ЗЫ. Сорри за дублирование сообщений ... << RSDN@Home 1.1.4 beta 3 rev. 185>> ![]() |
| Re[9]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 11:45 |
| Здравствуйте, WolfHound, Вы писали: WH>Да накак. Не возможно это. Программ без ошибок не бывает.(я имею в виду программе больше чем "hello world!") А на сколько больше чем "hello world!"? Я всегда говорил что модули не большие. Неужели нельзя небольшой модуль "вылизать" так чтоб в нем не было ошибок... |
| Re[9]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 11:49 |
| Здравствуйте, Mamut, Вы писали: M>Будет ли работать такая система Автор: Mamut Дата: 03.12.04 Вы же сами ответили: "умрут и даже не пикнут". Ко мне какой вопрос? |
| Re[10]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 10.12.04 11:51 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>А на сколько больше чем "hello world!"? Я всегда говорил что модули не большие. Неужели нельзя небольшой модуль "вылизать" так чтоб в нем не было ошибок... Э! Мечты, мечты. Вот Dinkumware, к примеру, в STL для VC6 — сколько багов насажала на ровном месте. Причём вовсе не из-за коварства языка С++, а из-за шаловливых рук. Например, функция сортировки списка с предикатом — внутри этим предикатом не пользуется. Ну забыли, ну бывает. Перекуём баги на фичи! |
| Re[8]: Понарамос | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 11:54 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>термином "по настоящему расширяемая модульная система" сокращенно — ПоНРаМС. Более благозвучно: ПоНаРаМоС (понарамос, понарамосы, понарамоса, понарамосу) |
| Re[10]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 10.12.04 12:01 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Mamut, Вы писали: M>>Будет ли работать такая система Автор: Mamut Дата: 03.12.04 СГ>Вы же сами ответили: "умрут и даже не пикнут". Ко мне какой вопрос? В свете здесь Автор: Сергей Губанов и здесьДата: 10.12.04 Автор: Сергей Губанов — невозможно создать систему, работающую по определению с мелкими модулями, вылизаными до полного отсутствия ошибок. Ошибки будут. Причем, как тривиальные, вроде деления на ноль (а я так и не получил ответа на то, как поведет себя Оберон в этом случае), так и нетривиальные, связанные с ошибками в дизайне системы, как таковой.Дата: 10.12.04 Причем уже не раз указывалось на то, как модульную, расширяемую, работающую систему можно завалить, внеся ошибки в модуль, от которого многое в системе зависит (тот же видеодрайвер в системе). ... << RSDN@Home 1.1.4 beta 3 rev. 185>> ![]() |
| Re[11]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 12:39 |
| Здравствуйте, Mamut, Вы писали: M> ...вроде деления на ноль (а я так и не получил ответа на то, как поведет себя Оберон в этом случае)... А что же Вам помешало получить ответ??? Например, когда у меня возникает какая-то неясность с той же .NET, с С++ или еще с чем-то подобным, то я сажусь за компьютер, пишу тестовую програмку и экспериментальным путем получаю ответ. M> Причем уже не раз указывалось на то, как модульную, расширяемую, работающую систему можно завалить, внеся ошибки в модуль, от которого многое в системе зависит. Если внести ошибки во что-то от чего многое зависит, то, ЕСТЕСТВЕННО — так можно завалить все что от него зависит! Это утверждение истинно всегда, то есть тавтология. Понарамос — отличается от других систем не тем, что ее вообще нельзя завалить, а тем что после установки/удаления/замены компонента в понарамосе не надо проводить global integrity check. Если все компоненты правильные, то система работать будет. Если какой-то компонент дурной, то он испортит жизнь только себе (и тем кто от него зависит само собой), но саму систему завалить ему будет весьма сложновато, так как в нее встроены механизмы безопасности (например, ГЦ является одним из этих механизмов). |
| Re[12]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 10.12.04 12:58 |
| Re[12]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 10.12.04 13:15 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Понарамос — отличается от других систем не тем, что ее вообще нельзя завалить, а тем что после установки/удаления/замены компонента в понарамосе не надо проводить global integrity check. Если все компоненты правильные, то система работать будет. Если какой-то компонент дурной, то он испортит жизнь только себе (и тем кто от него зависит само собой), но саму систему завалить ему будет весьма сложновато, так как в нее встроены механизмы безопасности (например, ГЦ является одним из этих механизмов). А ну-ну... Тебе напомнить как сожрать всю память при ГЦ? Или как вариант можно уйти в бесконечный цикл сожрав все ресурсы процессора... ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[13]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт rsdn | |
| Дата: | 10.12.04 13:21 |
| Здравствуйте, WolfHound, Вы писали: WH>А ну-ну... Тебе напомнить как сожрать всю память при ГЦ? Или как вариант можно уйти в бесконечный цикл сожрав все ресурсы процессора... Это, кстати, к вопросу о корпоративной многозадачности и едином адресном пространстве. Перекуём баги на фичи! |
| Re[8]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 10.12.04 13:33 | |
| Оценка: | +1 | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Glоbus, Вы писали: СГ>[skip] G>> ...Неправильное определение на мой взгляд... СГ>[skip] СГ>Поскольку понятия "модульность" и "компонентность" можно трактовать очень широко (кто во что горазд), мне, видимо, придется придумать какой нибудь специальный термин для обозначения тех систем, о которых говорю я. Пока я этого термина не придумал, буду пользоваться рабочим термином "по настоящему расширяемая модульная система" сокращенно — ПоНРаМС. ЩасВернус? СГ>Компоненты системы делаются разными производителями. Пользователь собирает из этих компонентов свою систему. Производители физически не могут протестировать свои компоненты на совместимость с компонентами других производителей. Каждый компонент тестируется отдельно. Вся система целиком, собранная конечным пользователем из разных компонентов, НИ КОГДА НЕ ТЕСТИРУЕТСЯ на ЦЕЛОСТНОСТЬ, она ДОЛЖНА РАБОТАТЬ просто по своему определению. Такого не будет никогда в жизни СГ>Система "по настоящему расширяема" — это когда добавление/удаление/замена компонента (или нескольких компонентов) осуществляется "на лету" (то есть во время ее работы), Значит автомобиль, велосипед, да и многое другое — нерасширяемые системы? СГ> а также без проверки целостности полученной системы. Каждый компонент тестируется отдельно, а сама система — никогда не тестируется. То есть такого понятия как "фаза финальной интеграции компонентов" просто не существует, хотябы потому, что понрамс никогда не достигает своего финального состояния, а является расширяемой по своему определению. Я не могу понять — что значит по определению расширяемая система. Система может быть расширяемой в соответствии со своим дизигном. Точка. СГ>Жизненный опыт подсказывает, что даже если каждый компонент по отдельности работает, то после того как соединить их в систему, то кто же его знает, а вдруг система не заработает, вдруг компоненты несовместимы!!! А кто ж спорит СГ>Так вот, "по настоящему расширяемая модульная система" РАБОТАЕТ ПО ОПРЕДЕЛЕНИЮ. (Если не работает, значит это не она.) Агащасблин СГ>Спрашивается, а как этого добиться? Как надо строить "по настоящему расширяемые модульные системы"?????? Ага, как, ы? СГ>Дисциплина КОП как раз и изучает вопрос о том как надо строить "по настоящему расширяемые модульные системы". СГ>Клеменс Шиперски, в 1995 году предложил следующую формулу для КОП СГ>
СГ>Без требования "Безопасность" система просто может не заработать, котя каждый компонент в отдельности вроде как исправен. Ё-мое... какие-то обзщие слова. — это ваще атас. А может и заработать. А может заработать и сломаться. А может и не сломаться. А что такое безопасность? А что такое безопасная система? И безопасная с какой точки зрения? А кто отвечает за безопасность? СГ>Сборщик мусора — есть техническая деталь необходимая для осуществления безопасности. Никак нет, вашвысокродие Шиперски объяснил это в одном абзаце: СГ>
Ну дык я не понимаю — а почему сморт поинтеры не рулят тут? СГ>Та формула, которую Вы критиковали (КОП = Модульность + ООП) есть в точности тоже самое что предложил Шиперски, с теми оговорками которые я там же и привел. СГ>Оригинальная статья Шиперского: Component-Oriented Programming A Refined Variation on Object-Oriented Programming, The Oberon Tribune, Vol 1, No 2, December 1995. А кто такой Шиперски? Удачи тебе, браток! | |
| Re[13]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 13:43 |
| Здравствуйте, WolfHound, Вы писали: WH>А ну-ну... Тебе напомнить как сожрать всю память при ГЦ? Или как вариант можно уйти в бесконечный цикл сожрав все ресурсы процессора... Память можно сожрать и без ГЦ. В бесконечный цикл можно уйти и без ГЦ. |
| Re[9]: Понарамос | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Трурль | http://art.net/~hopkins/Don/lem/Trurl.html |
| Дата: | 10.12.04 13:47 | |
| Оценка: | ![]() | |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Сергей Губанов, Вы писали: СГ>>термином "по настоящему расширяемая модульная система" сокращенно — ПоНРаМС. СГ>Более благозвучно: ПоНаРаМоС (понарамос, понарамосы, понарамоса, понарамосу) Настоящий профи применит термин TEMS Truly Extensible Modular System. |
| Re[9]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 14:04 |
| Здравствуйте, Glоbus, Вы писали: G>Значит автомобиль, велосипед, да и многое другое — нерасширяемые системы? Это не программы. G>Ну дык я не понимаю — а почему сморт поинтеры не рулят тут? Смартпоинтеры живут только внутри одного модуля. А понарамос состоит из нескольких (сотен, тысяч) разных модулей. Модули обмениваются друг с другом объектами. То есть объекты бывают как для внутримодульного использования (вот для них можно использовать смарт поинтеры сколько влезет), так и для межмодульного пользования. Для межмодульного использования смартпоитеры не годятся, в целях безопасности там нужен полноценный сборщик мусора. Внутримодульные объекты контролирует сам модуль, межмодульные объекты никакой конкретный модуль не контролирует — никакой модуль не несет ответсвенности за их утилизацию. При условии, что система может динамически изменяться (загрузка/выгрузка компонентов) управлять жизнью межмодульных объектов может только сама среда исполнения т.е. централизованный ГЦ. На всякий случай, межмодульные объекты — это такие объекты, о существовании которых знают (и используют их) более чем один модуль. G>А кто такой Шиперски? Это тот чел, который КОП продвигает. Он автор книг: Clemens Szyperski Component Software — Beyond Object-Oriented Programming Addison-Wesley / ACM Press, 1998 (411 pages) ISBN 0-201-17888-5 Clemens Szyperski (with Dominik Gruntz and Stephan Murer) Component Software — Beyond Object-Oriented Programming – Second Edition Addison-Wesley / ACM Press, 2002 (608 pages) ISBN 0-201-74572-0 Являлся со-основателем компании Oberon Microsystems. В настоящее время трудится в Microsoft Вот его персональная страница: http://www.research.microsoft.com/users/cszypers/ |
| Re[10]: TEMS | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 14:07 |
| Здравствуйте, Трурль, Вы писали: Т>Здравствуйте, Сергей Губанов, Вы писали: СГ>>Здравствуйте, Сергей Губанов, Вы писали: СГ>>>термином "по настоящему расширяемая модульная система" сокращенно — ПоНРаМС. СГ>>Более благозвучно: ПоНаРаМоС (понарамос, понарамосы, понарамоса, понарамосу) Т>Настоящий профи применит термин TEMS Truly Extensible Modular System. Ну чтож. Кто же будет против заделаться настоящим профи... Раз TEMS значит TEMS... |
| Re[14]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 10.12.04 14:08 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, WolfHound, Вы писали: WH>>А ну-ну... Тебе напомнить как сожрать всю память при ГЦ? Или как вариант можно уйти в бесконечный цикл сожрав все ресурсы процессора... СГ>Память можно сожрать и без ГЦ. В бесконечный цикл можно уйти и без ГЦ. И? Тебе же говорят, что безошибочных расширяемых систем создать невозможно |
| Re[11]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 10.12.04 14:11 |
| Здравствуйте, Mamut, Вы писали: M>В свете здесь Автор: Сергей Губанов и здесьДата: 10.12.04 Автор: Сергей Губанов — невозможно создать систему, работающую по определению с мелкими модулями, вылизаными до полного отсутствия ошибок. Ошибки будут. Причем, как тривиальные, вроде деления на ноль (а я так и не получил ответа на то, как поведет себя Оберон в этом случае), так и нетривиальные, связанные с ошибками в дизайне системы, как таковой.Дата: 10.12.04 По поводу деления на ноль. Поведение Оберон-системы в случае деления на ноль может быть разным, в зависимости от назначения данной конкретной системы. Может вырабатываться исключение. В ETH Oberon просто возвращается INF (infinity) (только что проверил). Кстати, я тоже не дождался ответа на вопрос: что будет, если процесс испортит собственную память и не будет пойман операционной системой? M>Причем уже не раз указывалось на то, как модульную, расширяемую, работающую систему можно завалить, внеся ошибки в модуль, от которого многое в системе зависит (тот же видеодрайвер в системе). Конечно, можно. Но имеет ли это отношение к расширению работающей системы за счет добавления новых модулей? Хоар |
| Re[14]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | WolfHound rsdn | |
| Дата: | 10.12.04 14:11 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Память можно сожрать и без ГЦ. В бесконечный цикл можно уйти и без ГЦ. С этим не кто не спорит. Но и ты не забывай что что ГЦ и тотальный range check не панацея. ... << RSDN@Home 1.1.4 beta 3 rev. 185>> Пусть это будет просто: | просто, как только можно, но не проще. (C) А. Эйнштейн |
| Re[15]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 10.12.04 14:17 |
| Здравствуйте, Курилка, Вы писали: СГ>>Память можно сожрать и без ГЦ. В бесконечный цикл можно уйти и без ГЦ. К>И? Тебе же говорят, что безошибочных расширяемых систем создать невозможно Правильно, вроде бы, говорят. Ведь безошибочную систему создать очень трудно. Да и понятие ошибки довольно растяжимо. Но приводимая при этом критика не связана именно с расширением системы. Говорят больше о внесении ошибок в существующие модули. (А что, если поделить на ноль и т.п.) А Сергея, насколько я понимаю, интересует именно этот ("интеграционный"?) аспект. Хоар |
| Re[15]: TEMS | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 14:19 |
| Здравствуйте, Курилка, Вы писали: К> безошибочных расширяемых систем создать невозможно Это не доказуемо. |
| Re[16]: TEMS | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 14:21 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Курилка, Вы писали: К>> безошибочных расширяемых систем создать невозможно Да и в конце концов, а Вы пробовали? |
| Re[16]: TEMS | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 10.12.04 14:27 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Курилка, Вы писали: К>> безошибочных расширяемых систем создать невозможно СГ>Это не доказуемо. Противоположное также |
| Re[17]: TEMS | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сергей Губанов | http://moikrug.ru/users/P628059486/ |
| Дата: | 10.12.04 15:03 | |
| Оценка: | ![]() | |
| Здравствуйте, Курилка, Вы писали: К>>> безошибочных расширяемых систем создать невозможно СГ>>Это не доказуемо. К>Противоположное также Противоположное доказуемо прямым примером. Чем Вам Оберон-системы не пример? |
| Re[18]: TEMS | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 10.12.04 15:04 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Курилка, Вы писали: К>>>> безошибочных расширяемых систем создать невозможно СГ>>>Это не доказуемо. К>>Противоположное также СГ>Противоположное доказуемо прямым примером. Чем Вам Оберон-системы не пример? Ну докажи её безошибочность, математически |
| Re[24]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | jazzer | |
| Дата: | 10.12.04 16:04 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, jazzer, Вы писали: J>>Путем введения проксей ты вводишь в систему иерархичность, и она перестает быть гомогенной. СГ>Ацикличный граф связей между модулями есть иерархия. Все модульные системы иерархические. Я не понимаю что Вы имеете в виду под нарушением гомогенности. Ничего кроме модулей в модульной системе нет — в этом смысле я употребил термин "гомогенная". Это даже похоже на тавтологию: Модульная система состоит из модулей (и ничего кроме модулей в ней нет). я видел Ваши слова насчет равноправия модулей. А в схеме с прокси никакого равноправия нет. А если мы допускаем такое неравноправие, то что нам мешает вводить неравноправие, изобретая круги защиты, уровни доступа и т.д. и т.п? Получится, что винда — компонентная система :)
|
| Re[13]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Волк-Призрак | http://ghostwolf.newmail.ru |
| Дата: | 10.12.04 19:48 |
| Здравствуйте, WolfHound, Вы писали: WH>А ну-ну... Тебе напомнить как сожрать всю память при ГЦ? Или как вариант можно уйти в бесконечный цикл сожрав все ресурсы процессора... Всю память моя программа одна уже сожрала (вызвала в JVM 1.3.1 OutOfMemoryError). Отсюда вывод: 1. GC не панацея. 2. Всякие там понрамсы требуют соблюдения жесточайшего правил, которые все соблюдать не могут одинаковым предскозуемым способом. Всилу особенностей органических автоматов класса Homo Sapiens. 2.1 Может давайте выведим нновый вид животное — обезьянку-кодера? Или сделаем кодогенератор, входными данными для которого являются вербально сформулированные требования к системе (Грубо говоря, "компилятор спецификаций)? while(Life.getClass().getClassLoader()==Religion.GOD){Life.be();}; | Скажи .net корпорации Microsoft! (c) ghostwolf 2004 7 раз поищи в стандартной библиотеке, 1 раз накодь своё. |
| Re[8]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 10.12.04 20:18 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Вы действительно ошибаетесь на счет про... т.е. "некачественного" дизайна — в языках со сборщиком мусора в старом дизайне больше нет необходимости. Ты знаешь — за подобный код на шарпе надо расстреливать. Readonly-списки это моветон, ровно как моветон связанные списки. Объяснять почему? ... << RSDN@Home 1.1.4 beta 3 rev. 255>> AVK Blog | |
| Re[12]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 10.12.04 20:28 | |
| Оценка: | 1 (1) | |
| Здравствуйте, Кодт, Вы писали: К>Мгновенная сборка, во-первых, спускает лавину — реалтайм идёт нафиг К>Язык С++ автоматизирует создание и разрушение составных объектов: обход всех членов и под-объектов в конструкторе/деструкторе. Для сборщика мусора с циклическими зависимостями этого недостаточно: необходимо выполнять обход ещё и при раскраске. Т.е. либо мы вручную будем писать метод "обзвонить все члены" для каждого класса, либо будем хранить связи объект-деталь отдельно (в рантайме). Это немного: скажем, односвязный список всех вполне устроит (каждый умный указатель должен держать не только данные, но и указатель на следующий умный указатель агрегата). Но ведь ещё время инициализации такого списка... В реальных сборщиках все несколько сложнее и не так печально. Кучу мелких и быстрых выделений мусорщик не обходит (он обходит только живые объекты). А те объекты, которые живут длительное время просто уходят в поколения, которые собираются редко. Так что в основном мусорщик бегает по довольно небольшому графу. Ну еще и JIT немного мусорщику помогает, составляя таблички, в первом приближении сводящие управление ссылками к алгоритмам, похожим на смартпоинтеры. ... << RSDN@Home 1.1.4 beta 3 rev. 255>> AVK Blog | |
| Re[12]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 11.12.04 16:46 |
| Re[13]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 12.12.04 19:42 |
| Здравствуйте, Mamut, Вы писали: AVC>>В ETH Oberon просто возвращается INF (infinity) (только что проверил). M>Ух ты. Мне это нравится. Серьезно. Ребята, а вы плавучку с целочисленным делением не спутали? ... << RSDN@Home 1.1.4 beta 3 rev. 255>> AVK Blog | |
| Re[10]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Glоbus | |
| Дата: | 13.12.04 10:41 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Здравствуйте, Glоbus, Вы писали: G>>Значит автомобиль, велосипед, да и многое другое — нерасширяемые системы? СГ>Это не программы. Но модульные системы G>>Ну дык я не понимаю — а почему сморт поинтеры не рулят тут? (поскипано) СГ>На всякий случай, межмодульные объекты — это такие объекты, о существовании которых знают (и используют их) более чем один модуль. Я не понимаю ваще ... G>>А кто такой Шиперски? СГ>Это тот чел, который КОП продвигает. СГ>Он автор книг: .... СГ>Являлся со-основателем компании Oberon Microsystems. СГ>В настоящее время трудится в Microsoft Извини, не признаю авторитетов (в хорошем смысле этого опнятие) Удачи тебе, браток! | |
| По Фройду!!! | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | SilverCloud | http://rodonist.wordpress.com |
| Дата: | 13.12.04 15:19 |
| Здравствуйте, Кодт, Вы писали: К>Это, кстати, к вопросу о корпоративной многозадачности и едином адресном пространстве. Это в форум о работе Who needs information? |
| Re[14]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Eugeny__ | |
| Дата: | 13.12.04 16:02 | |
| Оценка: | ![]() | |
| Здравствуйте, Сантехник, Вы писали: <skipped> С>off: Когда у вас в квартире прорывает толчок, соседям снизу плевать почему это произошло, они хотят иметь С>незалитый потолок. Надеюсь, аналогия понятна? Хм.. А ты, это, и вправду сантехник? Без обид, но пример знатный Чем больше людям пофиг — тем лучше они живут! Впрочем, обратное тоже верно. | |
| Re[15]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Сантехник | |
| Дата: | 14.12.04 08:07 |
| Здравствуйте, Eugeny__, Вы писали: E__>Хм.. А ты, это, и вправду сантехник? E__>Без обид, но пример знатный Неа, natural born programmer ... << RSDN@Home 1.1.4 beta 3 rev. 250>> |
| Re[13]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт модератор | |
| Дата: | 14.12.04 09:40 |
| Здравствуйте, AndrewVK, Вы писали: AVK>В реальных сборщиках все несколько сложнее и не так печально. Кучу мелких и быстрых выделений мусорщик не обходит (он обходит только живые объекты). А те объекты, которые живут длительное время просто уходят в поколения, которые собираются редко. Так что в основном мусорщик бегает по довольно небольшому графу. Ну еще и JIT немного мусорщику помогает, составляя таблички, в первом приближении сводящие управление ссылками к алгоритмам, похожим на смартпоинтеры. А на литературу не можешь натравить? Я тут побаловался — пробовал родить GC на неуправляемом C++ (естественно, конвенциальный — т.е. нужно пользоваться умными указателями и всё такое), но тяп-ляп-реализация стремительно подохла. Перекуём баги на фичи! |
| Re[14]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 14.12.04 10:00 |
| Здравствуйте, Кодт, Вы писали: К>А на литературу не можешь натравить? Единственная литература на эту тему — ротор и отладчик. ... << RSDN@Home 1.1.4 beta 3 rev. 264>> AVK Blog | |
| Re[14]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 14.12.04 10:25 |
| Здравствуйте, Кодт, Вы писали: К>А на литературу не можешь натравить? К>Я тут побаловался — пробовал родить GC на неуправляемом C++ (естественно, конвенциальный — т.е. нужно пользоваться умными указателями и всё такое), но тяп-ляп-реализация стремительно подохла. Когда-то "натыкался" на книгу Элджера о Си++. Там он, кажется, в одной из последних глав пытался родить сборщик мусора на Си++. Правда, уровень кодирования у Элджера неплохой, а вот его способность адекватно воспринимать реальность вызывет сомнения. Практически всю книгу он посвятил указателям ("умным", "мудрым", даже "гениальным" и пр., и др.), а в конце заявил, что Java — это диалект Си++. Хоар |
| Re[11]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 14.12.04 10:59 |
| Здравствуйте, Трурль, Вы писали: Т>>>В определении компонена важная часть — "explicit context dependencies only", а наследование зачастую приводит к неявным зависимостям. AVC>>В смысле наследования реализации? AVC>>Или в каком-то ином? Т>Да, именно наследование реализации. Сначала я мысленно с Вами согласился. Но сейчас что-то стали меня "грызть" сомнения. Возьмем простую ситуацию программирования под Windows. Чтобы она была еще проще, будем "писать" на API. Допустим, нам потребовалось окно, ну как две капли воды — одно из стандартных окон, за исключением минимальных различий в поведении. Что мы будем делать? Именно. Создадим подкласс, по нашему, по "виндовски". На практике: мы заменим оконную процедуру на свою, которая будет пару сообщений обрабатывать сама, о остальные — переадресовывать прежней оконной процедуре. Разве это не значит, что мы "наследуем реализацию"? Ну так в этом весь и смысл! Кто стал бы программировать под Windows, если бы нельзя было делать это? Возьмем Оберон. Как правило, там та же картина. Базовые типы записей реализуют некоторую общую функциональность. (Это, кроме прочего, способ задать единые "правила" для системы.) К тому же, в Обероне не обязательно перекомпилировать клиентский модуль, если мы изменили реализацию "серверного" модуля. Ведь детали реализации в Обероне можно спрятать, в отличие от Си++. Например, замена списка на дерево, перекомпиляции клиентов не требует (я проверил из любопытства Т.е., наверное, надо уточнить понятие "наследования реализации". Иначе мы "с водой выплеснем и ребенка". Хоар |
| Re[13]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 14.12.04 11:26 |
| Здравствуйте, Mamut, Вы писали: AVC>>По поводу деления на ноль. AVC>>Поведение Оберон-системы в случае деления на ноль может быть разным, в зависимости от назначения данной конкретной системы. AVC>>Может вырабатываться исключение. AVC>>В ETH Oberon просто возвращается INF (infinity) (только что проверил). M>Ух ты. Мне это нравится. Серьезно. Если это ирония, то зря. Все эти INF, NaN и т.п. для того и придуманы, чтобы нельзя было получить некорректный результат и не заметить этого. Т.е. Вы не получите неверного результата. Что же касается перехвата исключения по делению на ноль (или по другим причинам), то оно в ETH Oberon также возможно и не составляет труда. Соответстствующий пример, кстати, приводил Трурль. Его также можно найти в online документации по ETH Oberon для Windows: Oberon for Windows 95/98/NT User's Guide, п.6.7: Zero-Overhead Exception Handling AVC>>Кстати, я тоже не дождался ответа на вопрос: что будет, если процесс испортит собственную память и не будет пойман операционной системой? M>BSOD? [Видимо, Blue Screen Of Death.] Это Вы меня спрашиваете, или я Вас? Тут многие иронизировали над тем, что Oberon не позволяет "портить" не только "чужую", но и "свою" память. Видно, "храбрый" народ "не боится" портить "свою" память. Это, мол, "ничаво". Вот я и спрашиваю: какие могут быть последствия, на Ваш взгляд? M>>>Причем уже не раз указывалось на то, как модульную, расширяемую, работающую систему можно завалить, внеся ошибки в модуль, от которого многое в системе зависит (тот же видеодрайвер в системе). AVC>>Конечно, можно. AVC>>Но имеет ли это отношение к расширению работающей системы за счет добавления новых модулей? M>За счет добавления новых, работающих на основе/за счет уже существующих — вряд ли. Но, опять же, чем это не прикладные приложения в любых других операционных системах (каждое такое приложение можно расматривать, как компонент, состоящий из энного количества модулей). Здесь я не слишком понял, в чем именно состоит Ваше утверждение. (Я вижу, скорее, вопрос. Но это может быть следствием моей недогадливости. Хоар |
| Re[14]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 14.12.04 12:04 |
| Здравствуйте, AndrewVK, Вы писали: AVC>>>В ETH Oberon просто возвращается INF (infinity) (только что проверил). M>>Ух ты. Мне это нравится. Серьезно. AVK>Ребята, а вы плавучку с целочисленным делением не спутали? Увы, перепутали. Точнее, именно я перепутал. Позор на мои седины и т.п. Заметил это только что. (Может быть, причина в том, что все последнее время возился в компиляторе с реализацией операций с плавающей точкой. Так что должен уточнить, что целочисленное деление на ноль и в ETH Oberon вызывает системное исключение, которое программист может перехватить, написав контекстный handler. Хоар |
| Re[14]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Mamut | http://dmitriid.com/ |
| Дата: | 14.12.04 12:26 |
| Re[15]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Кодт модератор | |
| Дата: | 14.12.04 13:01 |
| Здравствуйте, AVC, Вы писали: AVC>Когда-то "натыкался" на книгу Элджера о Си++. AVC>Там он, кажется, в одной из последних глав пытался родить сборщик мусора на Си++. AVC>Правда, уровень кодирования у Элджера неплохой, а вот его способность адекватно воспринимать реальность вызывет сомнения. AVC>Практически всю книгу он посвятил указателям ("умным", "мудрым", даже "гениальным" и пр., и др.), а в конце заявил, что Java — это диалект Си++. Тут не вопрос, как это всё закодировать на С++ (при желании — можно и на Си, и на Паскале, и даже на Обероне поверх ихнего встроенного Перекуём баги на фичи! |
| Re[15]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 14.12.04 13:10 |
| Здравствуйте, Mamut, Вы писали: M>Не, ни в коем случае. Я помню, удивился, когда во Флэше с NaN столкнулся. ИМХО — это вещь полезная. Я тоже так думаю. Хотя, возможно, Вы имели в виду целочисленное деление на ноль, и я отвечал "не на тот вопрос". Это со мной случается... AVC>>Oberon for Windows 95/98/NT User's Guide, п.6.7: Zero-Overhead Exception Handling M>Спасибо, взгляну На всякий случай, последнее обновление ETH Oberon для виндов было сделано 27 октября. Скачать можно с сайта Oberon Home Page: http://www.oberon.ethz.ch/ M>Я уже сам не помню, что хотел сказать Я как раз не считаю Windows немодульной системой, и расширяемость Windows мне нравится. (Хотя не нравится многое другое в Windows. Но вряд ли это "оригинально".) Просто меня (по ряду, как ни странно, практических причин Кстати, между Windows и Обероном есть общее. Достаточно вспомнить обработчики в Обероне. Типичный пример из книги Вирта:
Ну прямо оконная процедура Windows! (Правда, запись Message в Обероне — расширяемая.) P.S. Увы, топик передвинули в "священные войны". Не знаю, зачем. Лично я ни с кем "воевать" не собираюсь. Возможно, здесь сказывается отношение модераторов к Оберону. Хоар |
| Re[16]: А как ты думаешь, почему так сделано? | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 14.12.04 13:32 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, AVC, Вы писали: AVC>>Когда-то "натыкался" на книгу Элджера о Си++. AVC>>Там он, кажется, в одной из последних глав пытался родить сборщик мусора на Си++. AVC>>Правда, уровень кодирования у Элджера неплохой, а вот его способность адекватно воспринимать реальность вызывет сомнения. AVC>>Практически всю книгу он посвятил указателям ("умным", "мудрым", даже "гениальным" и пр., и др.), а в конце заявил, что Java — это диалект Си++. К>Тут не вопрос, как это всё закодировать на С++ (при желании — можно и на Си, и на Паскале, и даже на Обероне поверх ихнего встроенного В последнее время чаще слышно об алгоритме Боэма. Возможно, какую-то информацию можно найти здесь: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ К сожалению, до последнего времени (когда я заинтересовался Обероном), все мои познания о GC ограничивались алгоритмом Дойча-Шорра-Уэйта (?), приведенным в общих чертах в книге Ахо, Ульмана и Хопкрофта "Структуры данных и алгоритмы". Так что, увы, я пока не эксперт. На Си++, естественно, использовал счетчики и "умные" указатели. Хоар |
| Re[16]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | EvilChild | |
| Дата: | 27.12.04 14:41 |
| Здравствуйте, AVC, Вы писали: AVC>Просто меня (по ряду, как ни странно, практических причин А можно о практических причинах, если не секрет? |
| Re[17]: ПоНРаМС | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 27.12.04 17:05 | |
| Оценка: | +1 | |
| Здравствуйте, EvilChild, Вы писали: EC>Здравствуйте, AVC, Вы писали: AVC>>Просто меня (по ряду, как ни странно, практических причин EC>А можно о практических причинах, если не секрет? У меня секретов нет. Наше руководство высказало идею, что пора создавать на наших процессорах существенно более сложные системы, чем, скажем, MP3-плеер. Речь даже зашла о "портировании" Линукса. А у нас системных программистов — полтора землекопа. (До самого последнего времени только я и писал компиляторы, отладчики и т.п.) Тут я и вспомнил об Обероне. На мой взгляд, он позволяет строить надежные программные системы с нуля "малыми силами". (Показателен пример Вирта и Гуткнехта.) А это, imho, именно то, что нам надо. Я собираюсь сделать по этому поводу доклад руководству и поместить его на одном из форумов RSDN. Просто до этого еще не дошли руки: текучка заела. Хоар |
| Re: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | afonja | |
| Дата: | 28.12.04 14:06 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Выводы СГ>1) Сама .NET не является модульной системой. Модульной системой является каждое конкретное .NET приложение, в рамках которого модули загружены/слинкованы в единственном экземпляре. Извините, но то что вы написали это бред. Запускаете два разных процесса и ждете, что они будут иметь общий сегмент данных? Про защиту процессов в ОС вы никогда не слышали? Объясните мне, как в нормальной операционке два разных процесса могут использовать общие данные без дополнительных манипуляций, типа создания SharedMemory? Еще раз повторю: в нормальной ОС ни один процесс не может напрямую обращаться к памяти другого процесса. Так было! Так есть! Так будет! Почитайте Дейтела или Дейкстру. |
| Re[2]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 28.12.04 14:12 |
| Здравствуйте, afonja, Вы писали: A>Здравствуйте, Сергей Губанов, Вы писали: A>Извините, но то что вы написали это бред. Запускаете два разных процесса и ждете, что они будут иметь общий сегмент данных? A>Про защиту процессов в ОС вы никогда не слышали? Объясните мне, как в нормальной операционке два разных процесса могут использовать общие данные без дополнительных манипуляций, типа создания SharedMemory? A>Еще раз повторю: в нормальной ОС ни один процесс не может напрямую обращаться к памяти другого процесса. Так было! Так есть! Так будет! A>Почитайте Дейтела или Дейкстру. Эх, afonja! В том то и самый смак Оберон-систем, что можно (уверяю Вас) обойтись единым адресным пространством! Хоар |
| Re[3]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Курилка | http://kirya.narod.ru/ |
| Дата: | 28.12.04 14:14 |
| Здравствуйте, AVC, Вы писали: AVC>Здравствуйте, afonja, Вы писали: A>>Еще раз повторю: в нормальной ОС ни один процесс не может напрямую обращаться к памяти другого процесса. Так было! Так есть! Так будет! A>>Почитайте Дейтела или Дейкстру. AVC>Эх, afonja! AVC>В том то и самый смак Оберон-систем, что можно (уверяю Вас) обойтись единым адресным пространством! А кто сказал что Оберон-система есть нормальная ОС? |
| Re[4]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | afonja | |
| Дата: | 28.12.04 14:27 | |
| Оценка: | +1 | |
| Здравствуйте, Курилка, Вы писали: A>>>Почитайте Дейтела или Дейкстру. AVC>>Эх, afonja! AVC>>В том то и самый смак Оберон-систем, что можно (уверяю Вас) обойтись единым адресным пространством! К>А кто сказал что Оберон-система есть нормальная ОС? Операционная система обязана обеспечивать защиту адресного пространства процесса. Это часть определения операционных систем. Это аксиома. У процессов может быть общий сегмент данных, но для этого оба процесса должны с этим "согласиться". Возможно, в Оберон-системах такой сегмент создается "по умолчанию", либо все приложения выполняются в одном процессе. |
| Re[4]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 28.12.04 14:36 |
| Здравствуйте, Курилка, Вы писали: К>А кто сказал что Оберон-система есть нормальная ОС? Загадка: похожа на ОС, работает как ОС, выполняет все функции ОС, но не ОС. Хоар |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 28.12.04 14:50 |
| Hello, afonja! You wrote on Tue, 28 Dec 2004 14:27:55 GMT: a> Операционная система обязана обеспечивать защиту адресного a> пространства процесса. Это часть определения операционных систем. a> Это аксиома. Таким образом, Novell netware 3.1 операционной системой не является. А что это тогда? И где можно почитать такие странные определения? With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[5]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 28.12.04 14:53 |
| Здравствуйте, afonja, Вы писали: A>Операционная система обязана обеспечивать защиту адресного пространства процесса. Это часть определения операционных систем. Это аксиома. A>У процессов может быть общий сегмент данных, но для этого оба процесса должны с этим "согласиться". Возможно, в Оберон-системах такой сегмент создается "по умолчанию", либо все приложения выполняются в одном процессе. Позволю себе процитировать The Programmer's Guide к ETH Oberon, п.5.1 Introduction. Может быть, покажется интересным...
Хоар |
| Re[6]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | afonja | |
| Дата: | 28.12.04 18:47 |
| Здравствуйте, Sergey, Вы писали: S>И где можно почитать такие странные определения? Виноват, перезлился Когда-то давно (лет 10 назад) прочитал "Введение в операционные системы" Дейтела. С тех пор засело, что ОС без защиты памяти — не ОС Только что нашел в инете эту книгу. Там действительно нет такого строгого определения. Но я все равно не понимаю, как можно сделать реальную надежную систему без защиты памяти и разделения процессов. Разве что, однопользовательскую, которую, скорее всего придется каждый раз перезагружать после падения одного из "модулей". Все равно, программ без ошибок не бывает. Но, кажется, это уже было в Win16. |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Sergey | |
| Дата: | 29.12.04 08:55 | |
| Оценка: | +1 | |
| Hello, afonja! You wrote on Tue, 28 Dec 2004 18:47:30 GMT: a> Но я все равно не понимаю, как можно сделать реальную надежную систему a> без защиты памяти и разделения процессов. Ну вообще-то защита памяти и разделение процессов — разные вещи. Второе — наиболее грубая и примитивная реализация первого. a> Разве что, однопользовательскую, которую, скорее всего придется каждый a> раз перезагружать после падения одного из "модулей". Ну нетварь-то как раз отнюдь не однопользовательская была. А надежность ее зависела от надежности всех запускаемых nlm'ов With best regards, Sergey. Posted via RSDN NNTP Server 1.9 delta Собака бывает кусачей только от жизни собачей | |
| Re[7]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 29.12.04 11:06 |
| Здравствуйте, afonja, Вы писали: A>Но я все равно не понимаю, как можно сделать реальную надежную систему без защиты памяти и разделения процессов. Разве что, однопользовательскую, которую, скорее всего придется каждый раз перезагружать после падения одного из "модулей". Все равно, программ без ошибок не бывает. Прежде всего, я совершенно согласен с Вами в том, что нельзя сделать надежную систему без защиты памяти и разделения процессов. Просто существует несколько способов реализации этих основных требований. Насколько я понял из Ваших постов, Вы практически отождествляете процесс и отдельную (stand-alone) программу. (Поправьте меня, если я не так Вас понял.) Но, например, в Оберон-системах вообще нет понятия отдельной программы. Следовательно, нет и отдельных адресных пространств, принадлежащих таким программам. Отсюда многие делают вывод, что в Обероне не может быть надежной реализации многозадачности. ИМХО, такой вывод неверен. Во-первых, чтобы создать процесс, достаточно знать стартовую процедуру процесса и ожидаемый размер стека для размешения локальных переменных. Во-вторых, доступ к разделяемым переменным синхронизируется с помощью мониторов. Понятие монитора было введено Хоаром, и впервые применено Хансеном в языке Concurrent Pascal, а впоследствии и Виртом в языках Модула и Модула-2. Если Вы привыкли к другим механизмам, например, семафорам Дейкстры, то в недавно изданной у нас книге Эндрюса, посвященной реализации многозадачности, показано, что эти механизмы равносильны, и каждый из них может быть реализован с помощью другого. В-третьих, в Оберон-системе ни один процесс не может "испортить" единое адресное пространство, т.к. этому препятствует концепция надежности типов (type safety) в языке Оберон, на котором и пишут Оберон-системы. Надеюсь, приведенные доводы убедят Вас в том, что возможны альтернативные подходы к созданию программных систем в целом и операционных систем в частности. Когда я впервые осознал базовые принципы Оберон-систем, то меня поразила их простота и элегантность. Разумеется, это не означает, что я собираюсь "навязывать" использование Оберона всегда и везде. Хоар |
| Re[8]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 31.12.04 16:09 | |
| Оценка: | +1 | |
| Здравствуйте, Sergey, Вы писали: S>Ну вообще-то защита памяти и разделение процессов — разные вещи. Второе — S>наиболее грубая и примитивная реализация первого. А заодно и самая надежная. Любая защита без аппаратной поддержки гроша ломанного не стоит. ... << RSDN@Home 1.1.4 beta 3 rev. 268>> AVK Blog | |
| Re[9]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 01.01.05 12:41 |
| Здравствуйте, AndrewVK, Вы писали: S>>Ну вообще-то защита памяти и разделение процессов — разные вещи. Второе — S>>наиболее грубая и примитивная реализация первого. AVK>А заодно и самая надежная. Любая защита без аппаратной поддержки гроша ломанного не стоит. Конечно, дополнительная надежность никому не помешает. Но в связи с Вашим утверждением у меня возникло два вопроса. Вопрос 1: разве все микропроцессоры и микроконтроллеры имеют защищенный режим? И что делать, если не имеют? По Вашей логике, в таком случае — вся надежда на WatchDog, а программисты здесь вообще не при чем. Вопрос 2: а насколько тотальна "аппаратная" защита памяти (memory protection)? Разве она мешает процессу "портить" память в собственном адресном пространстве? (ИМХО, не мешает. В отличие от "программного" подхода Оберона.) Хоар |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AndrewVK модератор | |
| Дата: | 01.01.05 13:59 | |
| Оценка: | 1 (1) | |
| Здравствуйте, AVC, Вы писали: AVC>Вопрос 1: разве все микропроцессоры и микроконтроллеры имеют защищенный режим? Предназначенные для универсальных компьютеров и серверов (читай для параллельного выполнения различных задач и негарантированного качества софта) все. AVC> И что делать, если не имеют? Использовать те что имеют, либо отказатся от возможности запуска софта сторонних производителей (или жестко контроллировать то что они выпускают, Mac OS до версии 9 включительно припоминаешь?). AVC>Вопрос 2: а насколько тотальна "аппаратная" защита памяти (memory protection)? Разве она мешает процессу "портить" память в собственном адресном пространстве? Не мешает. Главное что мешает в чужом. Особенно важно что мешает портить ядро. ... << RSDN@Home 1.1.4 beta 3 rev. 268>> AVK Blog | |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | AVC | |
| Дата: | 01.01.05 16:56 |
| Здравствуйте, AndrewVK, Вы писали: AVC>>Вопрос 1: разве все микропроцессоры и микроконтроллеры имеют защищенный режим? AVK>Предназначенные для универсальных компьютеров и серверов (читай для параллельного выполнения различных задач и негарантированного качества софта) все. Наверное, сейчас это именно так. (И это, конечно, правильно.) Но здесь есть несколько проблем. 1) Поддержка нескольких процессов может требоваться не только на уровне универсальных компьютеров и серверов, но и встроенных (embedded) систем. Для встроенных систем использовать те же (сравнительно) дорогие процессоры, что используются в универсальных компьютерах, — непозволительная роскошь. Себестоимость процессора должна быть $1. Такие простые процессоры, как правило, не имеют защищенного режима. А потребность в надежном функционировании нескольких процессов может оставаться. Можно предложить несколько способов решения этой проблемы, в зависимости от конкретных потребностей. Здесь и кооперативная многозадачность, и управляемое событиями ПО и т.д. и т.п. Для целей (не слишком масштабных) нашей организации мне "приглянулся" подход Оберон-систем. Просто, надежно и эффективно. (Не утверждаю, что для задач большего масштаба это верно. Хотя, вроде бы, есть примеры таких "успешных" Оберон-систем, но я еще не настолько хорошо знаком со всеми принципами их организации.) 2) Проблема усложнения межпроцессного обмена информацией и снижения эффективности. Насколько я понимаю, защита памяти "небесплатна". Перемещение информации между разными адресными пространствами требует изощренных механизмов, что в совокупности с беспрерывным переключением контекстов значительно снижает эффективность. Опять же это особенно важно для простых процессоров, с какими обычно и имеет дело встроенное ПО. 3) Интересно, обязательно ли защищать именно процессы? Ведь процесс — это очень крупная программная единица. Например, Оберон защищает объекты, что кажется мне более целостным подходом. Хоар |
| Re[2]: О Майкрософте | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Lonely Dog | |
| Дата: | 12.01.05 17:34 |
| Здравствуйте, Сергей Губанов, Вы писали: СГ>Нет. Любой код может содержать ошибки. Стабильность гарантирует рантайм система языка программирования. Рантайм не дает ошибочному коду переполнить буфер и изгадить память, он не дает изгадить данные и любыми другими способами, скажем, с помощью "незаконного" приведения типов. К приведению типов, также относятся операции вида a_integer := b_real, которые запрещены еще на уровне компиляции. Если пользовательская программа пытается совершить запрещенное действие она просто останавливается самим рантаймом. Естественно, что сама система продолжает работать дальше как ни в чем не бывало. Гм... Интересно, а как рантайм будет обнаружить deadlocks или raise conditions в многопоточном коде? Вроде есть алгоритмы, которые это умеют, но они довольно сложны и по-моему не всегда работают. |
| Re[10]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | matumba | |
| Дата: | 15.06.07 09:12 | |
| Оценка: | 3 (1) -1 ![]() | |
| Сергей, добрый день! Не могли бы вы немного помочь мне? Дело касается Оберона, заинтересовался темой. Мой ящик thornik на гмэйле. Напишите, плиз. |
| Re[11]: Компонентность .NET шита белыми нитками | Оценить ![]() ![]() ![]() ![]() ![]() ![]() |
| От: | Bigger | |
| Дата: | 15.06.07 09:17 | |
| Оценка: | +1 | |
| Здравствуйте, matumba, Вы писали: M>Сергей, добрый день! M>Не могли бы вы немного помочь мне? Дело касается Оберона, заинтересовался темой. Мой ящик thornik на гмэйле. Напишите, плиз. И не лень было старую ветку поднимать ![]() Программист — это шаман..., но зачем же сразу в бубен? |