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

V>Абстрактная фабрика, конечно, пример классный. Только в ФП любой функциональный объект — точно такая же абстрактная фабрика. Так был ли мальчик?

Мы, вроде бы, не про ФП и паттерны тут говорим, а обсуждаем явно не соотвествующее действительности утверждение "SmallTalk эти паттерны и даром не сдались, у тех свои паттерны". Подавляющее большинство паттернов GOF и прочих, вроде MVC, были придуманы смолтокерами и для Смолтока.

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

FR>Польза очень даже извлекается, во первых оптимизация кода и перенос вычислений в compile time второе
FR>многопоточность.

Я не собираюсь утверждать, что пользы нет вообще, но от утверждения о том, что "польза извлекается сложно" не снимаю.

Здравствуйте, Иван Дубров, Вы писали:

ИД>http://en.wikipedia.org/wiki/Public_key_infrastructure

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

Ну и по твоей ссылке любопытно:

On July 10, 2011, a wildcard certificate was issued by DigiNotar's systems for Google by an attacker with access to their systems. This certificate was subsequently used by unknown persons in Iran to conduct a man-in-the-middle attack against Google services.[12][13] On August 28, 2011, certificate problems were observed on multiple Internet service providers in Iran.[14] The fraudulent certificate was posted on pastebin.[15] According to a subsequent news release by VASCO, DigiNotar had detected an intrusion into its certificate authority infrastructure on July 19, 2011.[16] DigiNotar did not publicly reveal the security breach at the time.

After this certificate was found, DigiNotar belatedly admitted dozens of fraudulent certificates had been created, including certificates for the domains of Yahoo!, Mozilla, WordPress and The Tor Project.[17] DigiNotar could not guarantee all such certificates had been revoked.[18] Google blacklisted 247 certificates in Chromium,[19] but the final known total of misissued certificates is at least 531.[20] Investigation by F-Secure also revealed that DigiNotar's website had been defaced by Turkish and Iranian hackers in 2009.[21]

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

S>Что кагбэ подразумевает равноправность решений по убиранию const_cast и введению модификатора clean.

ХЗ, "пойти еще дальше" — никакая не равноправность. По крайней мере мне так казалось, когда я пользовался русским языком для написания поста.


V>>Потому что, во-первых, речь шла не об иммутабельности, о ссылочной прозрачности. Это был контекст. Во-вторых, потому что с помощью const можно организовать меньше участков кода с той самой соблюдаемой ссылочной прозрачностью, чем бы мне хотелось. Но это не значит, что их нельзя организовать вообще.
S>Я не очень понимаю, как вы собираетесь организовывать "участки кода со ссылочной прозрачностью", выходя за пределы одного метода.
S>Вот мы имеем, скажем,

S>

S>void foo(const int &x)
S>{
S>   cout << x; // 1
S>   bar();
S>   cout << x; // 2 
S>}
S>

S>Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

Нет.
Слушай, как ты вообще умудряешься такое предполагать? Для меня ход твоих мыслей по поводу const полнейшая загадка до сих пор, ей-богу... Мне даже уже надоело делать вид, как же я недоумеваю. ))

Кароч, давай медленно разбирать, что есть const, какова его семантика, и как правильно получать плюшки от этой семантики.

Вернемся к сааамому началу. Напомню, речь шла о передаче аргументов в паскале и оберонах и о введении ключевого слова CONST в обероны для экономии затрат на передачу аргументов.

Давай придумаем пример некоей ф-ии на мейнстримовом синтаксисе:

static int sum(int a, int b, int c, int d) {
  a += b;
  a += c;
  a += d;
  return a;
}

Несмотря на мутабельный императивный алгоритм, ф-ия sum чиста, как слеза ребенка, ведь переменная a — копия исходного аргумента. К тому же, любой компилятор в состоянии так протрассировать ход вычислений, что ему не нужен будет никакой фрейм локальных переменных и адрес переменной "a" из этого фрейма, он может тупо подставить одну инструкцию векторного модуля процессора и вернуть на выход результат эквивалентного выражения: a+b+c+d.

Теперь представь, что нам надо складывать не int, а многомерные вектора, получая, скажем, итоговый вектор сил в многомерном пространстве. Тогда передавать аргументы ПО ЗНАЧЕНИЮ окажется накладным, скорее всего (из-за объема копируемых данных), и будет смысл передавать исходные данные по ссылке. Скажем, для C# примерно так:

struct Vec { 
/* many projections */ 

static Vec operator+(...) {}.
};

static int sum(ref Vec a, ref Vec b, ref Vec c, ref Vec d) {
  a += b;
  a += c;
  a += d;
  return a;
}

Упс... стоило передать не копии значений, а их ссылки, и ф-ия перестала быть чистой. Давай попробуем допилить C# до вменяемого состояния, добавим еще один модификатор in, то бишь пусть вместо модификаторов ref и out будут модификаторы ref in и ref out.

static int sum(ref in Vec a, ref in Vec b, ref in Vec c, ref in Vec d) {
  a += b;
  a += c;
  a += d;
  return a;
}

А вот этот код уже не скомпилится, потому что нарушает гарантии ref in. Поэтому код придется переписать так, чтобы гарантии не нарушались. Давай введем еще одну переменную Vec tmp и её же вернем в конце вычислений: return tmp. (писать этот вариант целиком не буду, и так понятно).

Итого, мы обогатили синтаксис C# полезным ключевым словом, который предоставляет кое-какие гарантии вызывающему коду, за счет этого мы можем смело сэкономить на копировании аргументов, передавая их по ссылке. Идем далее. У структур могут быть методы/св-ва. Эти методы могут изменять значения полей структуры, а могут и нет. Мне бы хотелось некоторого контроля за тем, какие именно методы поданного по ссылке объекта с модификатором in я могу дергать, а какие нет. Кому как, а мне модификатор in для методов не нравится, кривовато:

struct Vec { 
  public int Dimentions { in get; set; }
};

Что если так:

struct Vec { 
  public int Dimentions { const get; set; }
};

Чуть лучше.

Делее — чистота.
Чистота мне нужна как гарантия отсутствия неявных зависимостей и ни для чего более.

Т.е., что я хочу от модификатора clean для глобальных ф-ий и методов объектов:
— нельзя обращаться к мутабельным глобальным переменным и глобальным не-clean ф-иям.
— аналогично нельзя обращаться к мутабельным статическим полям объектов и к не-clean методам.

Т.е., clean, это не const, это отсутствие неявных связей. Поэтому я бы хотел примерно так организовать сигнатуру sum для "тяжеловесных" структур:

clean void sum(ref in Vec a, ref in Vec b, ref out Vec result) {...}

Заметь, sum модифицирует память по ссылке ref out Vec result, но в то же самое время для компилятора (и для меня, я же не глупее )) ) происходящее в коде абсолютно clean, потому что теперь мы оба точно знаем, в каких местах вызывающего кода можно подменять адрес на значение, а в каких нельзя.

Заметь, что "clean" и "ref in" (то бишь сиплюсовый const&) работают совместно для описания нужной мне сигнатуры. Так же заметь, что clean метод объекта запросто может быть неконстантным, ведь все зависимости явные, то бишь this передается явно не хуже "ref out Vec result".

Напомню так же, что я попытался этим clean развить понравившуюся мне мысль о "контроллируемой мутабельности". Т.е. мутабельность мне нужна, ес-но, но я хочу убежать от скрытой мутабельности, от непонятных сюрпрайзов во время работы программы.

=============
На остальное потом.

Дважды описка, читать так:

V>

V>static Vec sum(ref Vec a, ref Vec b, ref Vec c, ref Vec d) {
V>  ...
V>}
V>

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

"Остальное осмотрел". Ключевые моменты ты все-равно скипнул, отвечать больше не на что.


S>Ну покажите же мне, какие оптимизации может делать компилятор при компиляции foo(const int& x) по сравнению с компиляцией foo(int& x).

Устал поправлять, речь всегда о гарантиях для вызывающего кода:

int x = 42;
foo(x);
std::cout << x;

Для разных вариантов foo будет сгенерен разный код. Для первого варианта будет такое:

foo(42);
std::cout << 42;

Для второго — исходный.

ИМХО, невооруженным взглядом видно, где тут работает ссылочная прозрачность.

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


K>И как "не-clean операции" будут отличаться от clean? Т.е. можно будет только clean-функции использовать и только константы читать?

Вот тут обрисовал как я использую const и для чего хотел бы иметь clean:
http://www.rsdn.ru/forum/philosophy/4838600.1.aspx

Автор: vdimas
Дата: 01.08.12

K>Да, с точностью до именования лексем, = использовать нельзя, это ключевое слово. Можно и короче — с += и прочим. Можно и вышеупомянутый x++ сделать, с той поправкой, что постфиксные операторы в хаскеле должны быть в скобках, т.е. (x++). Можно даже лучше, написать линзы, но не "функциональные", а с изменением по-месту, с помощью ST, а это, фактически, first-class l-values.

Ну... круто, если так. ))

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


FR>Если брать D в котором нечто подобное уже реализовано http://dlang.org/function.html#pure-functions то все очень жестко
FR>

FR>does not read or write any global or static mutable state
FR>cannot call functions that are not pure
FR>can override an impure function, but an impure function cannot override a pure one
FR>is covariant with an impure function
FR>cannot perform I/O

Именно оно!!!

Тааак... походу зря D обходят вниманием... по крайней мере я зря обхожу... ))
А каковы прогнозы насчет готовности D2?

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

V>Здравствуйте, Иван Дубров, Вы писали:

ИД>>http://en.wikipedia.org/wiki/Public_key_infrastructure

V>Увы и ах, военные не могут позволить себе полагаться на мифические независимые "достоверные центры", определяющие истинность сертификатов.

В смысле -- не могут? Почему они не могут завести свои CA и подписывать своими ключами ключи своих устройств?

При этом даже если полагаться на сторонние CA (например, для установления первоначального защищённого соединения по которому уже будет передана информация о своём CA), это всё равно будет безопаснее, чем просто передавать публичный ключ устройства.

V>Поэтому, система генерит аналоги сертификатов сама при регистрации конкретных "девайсов" (включая мобильные). Просто, если для проводных устройств можно хотя бы для регистрации подключать их в изолированную локальную сеть, то GSM траффик перехватывается таким же точно образом вообще на раз.

Я уверен, можно придумать множество вариантов, более защищённых чем то, что ты описал (просто обменяться публичными ключами). Если это потребуется.

V>Ну и по твоей ссылке любопытно:
V>

V>On July 10, 2011, a wildcard certificate was issued by DigiNotar's systems for Google by an attacker with access to their systems. This certificate was subsequently used by unknown persons in Iran to conduct a man-in-the-middle attack against Google services.[12][13] On August 28, 2011, certificate problems were observed on multiple Internet service providers in Iran.[14] The fraudulent certificate was posted on pastebin.[15] According to a subsequent news release by VASCO, DigiNotar had detected an intrusion into its certificate authority infrastructure on July 19, 2011.[16] DigiNotar did not publicly reveal the security breach at the time.

V>After this certificate was found, DigiNotar belatedly admitted dozens of fraudulent certificates had been created, including certificates for the domains of Yahoo!, Mozilla, WordPress and The Tor Project.[17] DigiNotar could not guarantee all such certificates had been revoked.[18] Google blacklisted 247 certificates in Chromium,[19] but the final known total of misissued certificates is at least 531.[20] Investigation by F-Secure also revealed that DigiNotar's website had been defaced by Turkish and Iranian hackers in 2009.[21]

А что тут любопытного? Слишком много CA, которым устройства доверяют "по умолчанию" (прописаны во всех браузерах, например), и которые могут быть скомпроментированы. В случае если нужно построить прям совсем защищённую сеть, можно развернуть свою PKI. При этом, в любом случае, man-in-the-middle атака существенно проще, чем украсть ключ одного из CA.

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

Стоит заметить, что вы с vdimas почти полное подобие. Забавно наблюдать, что у вас даже получается некоторое общение

> Вот у меня лежит исходник системы со всякими новомодными шифрованиями, этой системой пользуюся даже в армии одной страны, которая слишком часто на слуху. Писал расширение к этой системе. Дык, я достоверно знаю как ее вскрыть через прослушку трафика. При регистрации девайсов системы обмениваются открытыми ключами, начиная прямо с этого момента надо лишь проксировать трафик м/у двумя вскрываемыми системами, где обоим сторонам подсунуть свои открытые ключи вместо оригинального. Кароч, через проксирование трафика система вскрывается настолько банально, что даже стремно владеть такой информацией...

Сказочки в стиле Мышъх-а.
Читай несимметричное шифрование. Ты не можешь имитировать другую сторону или подменять пакеты не зная что в передаваемых пакетах и не можешь расшифровать пакеты, проксирование тебе в этом никак не поможет, ибо. Тебе правильно ссылку на википедию дали Не бывает такого в военных системах, не надо ля-ля.

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

V>ХЗ, "пойти еще дальше" — никакая не равноправность. По крайней мере мне так казалось, когда я пользовался русским языком для написания поста.
Ладно, я отвечу. Но это — в последний раз.


S>>

S>>void foo(const int &x)
S>>{
S>>   cout << x; // 1
S>>   bar();
S>>   cout << x; // 2 
S>>}
S>>

S>>Можно ли в точке 2 заменить "адрес" x его "значением", закешированным в точке 1?

V>Нет.
V>Слушай, как ты вообще умудряешься такое предполагать?
Ну это же вы утверждали, что const нам поможет для ссылочной прозрачности. Вот я пытаюсь применить её определение.

V>Кароч, давай медленно разбирать, что есть const, какова его семантика, и как правильно получать плюшки от этой семантики.


V>Теперь представь, что нам надо складывать не int, а многомерные вектора, получая, скажем, итоговый вектор сил в многомерном пространстве. Тогда передавать аргументы ПО ЗНАЧЕНИЮ окажется накладным, скорее всего (из-за объема копируемых данных), и будет смысл передавать исходные данные по ссылке. Скажем, для C# примерно так:

V>Упс... стоило передать не копии значений, а их ссылки, и ф-ия перестала быть чистой. Давай попробуем допилить C# до вменяемого состояния, добавим еще один модификатор in, то бишь пусть вместо модификаторов ref и out будут модификаторы ref in и ref out.
V>

V>static int sum(ref in Vec a, ref in Vec b, ref in Vec c, ref in Vec d) {
V>  a += b;
V>  a += c;
V>  a += d;
V>  return a;
V>}
V>

V>А вот этот код уже не скомпилится, потому что нарушает гарантии ref in. Поэтому код придется переписать так, чтобы гарантии не нарушались. Давай введем еще одну переменную Vec tmp и её же вернем в конце вычислений: return tmp. (писать этот вариант целиком не буду, и так понятно).
Не очень понятно.

V>Итого, мы обогатили синтаксис C# полезным ключевым словом, который предоставляет кое-какие гарантии вызывающему коду, за счет этого мы можем смело сэкономить на копировании аргументов, передавая их по ссылке. Идем далее.
Не, далее мы не пойдём. Будем разбирать этот пример. Какие именно гарантии предоставляет ключевое слово in?
Вот, допустим, у меня такие методы:

private Vec _dong;
public fail()
{
   _dong = new Vec(...)
   var ding = _dong.DeepCopy();
   var oops = same(ref _dong);
   Debug.Assert(ding == _dong);
}
public same(ref in Vec a)
{
  _dong.Wipe();
  return a;
}

Как видим, ref in не помешало мне сломать гарантии компилятору.


V>Делее — чистота.
V>Чистота мне нужна как гарантия отсутствия неявных зависимостей и ни для чего более.

V>Т.е., что я хочу от модификатора clean для глобальных ф-ий и методов объектов:
V>- нельзя обращаться к мутабельным глобальным переменным и глобальным не-clean ф-иям.
V>- аналогично нельзя обращаться к мутабельным статическим полям объектов и к не-clean методам.

V>Т.е., clean, это не const, это отсутствие неявных связей. Поэтому я бы хотел примерно так организовать сигнатуру sum для "тяжеловесных" структур:
V>

V>clean void sum(ref in Vec a, ref in Vec b, ref out Vec result) {...}
V>

V>Заметь, sum модифицирует память по ссылке ref out Vec result, но в то же самое время для компилятора (и для меня, я же не глупее )) ) происходящее в коде абсолютно clean, потому что теперь мы оба точно знаем, в каких местах вызывающего кода можно подменять адрес на значение, а в каких нельзя.
Конечно знаем — ни в каких нельзя.

V>Заметь, что "clean" и "ref in" (то бишь сиплюсовый const&) работают совместно для описания нужной мне сигнатуры. Так же заметь, что clean метод объекта запросто может быть неконстантным, ведь все зависимости явные, то бишь this передается явно не хуже "ref out Vec result".
Отлично, я так и думал. Именно поэтому я не хотел выкладывать сюда результаты моих медитаций — вы бы начали юлить и обвинять меня в том, что я за вас неправильно придумал ограничения на clean.

Давайте модифицируем пример вот так:

clean void fail(ref in Vec a, ref out Vec result, clean Action callback)
{
  result = a;
  callback();
}

Очевидно, что модификатор clean можно также распространять и на делегаты. По вашему определению, с fail всё в порядке — он вызывает только clean метод, с ref in аргументом ничего не делает, мутабельные статические поля не трогает.

Теперь вызовем его вот так:

var Vec test = new Vec(...);
var Vec test2;
fail(ref test, ref test2, ()=>{test.Wipe();} )
Debug.Assert(test == test2);

Наше замыкание — тоже вполне себе clean. Оно вызывает только один метод на test, который тоже clean — он меняет только this, а ведь он ничем не хуже, чем ref out result.
Таким образом, мы видим, что из clean компилятор тоже не может сделать ничего полезного.
Попробуйте изменить ограничения на clean метод — возможно, вы всё же получите какую-нибудь пользу

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

V>>Давай введем еще одну переменную Vec tmp и её же вернем в конце вычислений: return tmp. (писать этот вариант целиком не буду, и так понятно).
S>Не очень понятно.

Имелось ввиду такое:

static Vec sum(ref in Vec a, ref in Vec b, ref in Vec c, ref in Vec d) {
  Vec tmp = a;
  tmp += b;
  tmp += c;
  tmp += d;
  return tmp;
}

Теперь sum опять чиста, несмотря на всю мутабельность, если эта мутабельность не выходит за пределы ф-ии.


S>Не, далее мы не пойдём. Будем разбирать этот пример. Какие именно гарантии предоставляет ключевое слово in?

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

S>Вот, допустим, у меня такие методы:
S>

S>private Vec _dong;
S>public fail()
S>{
S>   _dong = new Vec(...)
S>   var ding = _dong.DeepCopy();
S>   var oops = same(ref _dong);
S>   Debug.Assert(ding == _dong);
S>}
S>public same(ref in Vec a)
S>{
S>  _dong.Wipe();
S>  return a;
S>}
S>

S>Как видим, ref in не помешало мне сломать гарантии компилятору.

Да приводили уже аналогичный пример на Си и я показывал уже ошибку рассуждений. Еще до момента вызова same(ref _doing) была нарушена ссылочная прозрачность _doing. Тут нет исходной ссылочной прозрачности и ее некуда распространять. То бишь я, как программист (а заодно и компилятор) никаких выводов относительно значений _dong после вызова same() делать не будет.

А откуда ссылочная прозрачность появляется? Вопрос на мильон, а ответ простой — только в месте создания значения.

Надо было не присваивать new Vec куда-то во внешний мир (в д.с. поле по адресу this), и тогда цикл жизни этого созданного значения можно было бы трекать. После присвоения мемберу объекта и вызова неконстантных методов объекта — уже нельзя. Это же закон для const. Надо было вызвать const-методы, но в нем ты бы не смог вызвать не-const метод переменной _dong, бо константность распространилась бы и на нее. Для замыканий все работает аналогично с распространением константности, boost::bind в пример.


V>>Делее — чистота.
V>>Чистота мне нужна как гарантия отсутствия неявных зависимостей и ни для чего более.

V>>Т.е., что я хочу от модификатора clean для глобальных ф-ий и методов объектов:
V>>- нельзя обращаться к мутабельным глобальным переменным и глобальным не-clean ф-иям.
V>>- аналогично нельзя обращаться к мутабельным статическим полям объектов и к не-clean методам.

V>>Т.е., clean, это не const, это отсутствие неявных связей. Поэтому я бы хотел примерно так организовать сигнатуру sum для "тяжеловесных" структур:
V>>

V>>clean void sum(ref in Vec a, ref in Vec b, ref out Vec result) {...}
V>>

V>>Заметь, sum модифицирует память по ссылке ref out Vec result, но в то же самое время для компилятора (и для меня, я же не глупее )) ) происходящее в коде абсолютно clean, потому что теперь мы оба точно знаем, в каких местах вызывающего кода можно подменять адрес на значение, а в каких нельзя.
S>Конечно знаем — ни в каких нельзя.

В приведенном примере таки знаем достоверно.

V>>Заметь, что "clean" и "ref in" (то бишь сиплюсовый const&) работают совместно для описания нужной мне сигнатуры. Так же заметь, что clean метод объекта запросто может быть неконстантным, ведь все зависимости явные, то бишь this передается явно не хуже "ref out Vec result".
S>Отлично, я так и думал. Именно поэтому я не хотел выкладывать сюда результаты моих медитаций — вы бы начали юлить и обвинять меня в том, что я за вас неправильно придумал ограничения на clean.

S>Давайте модифицируем пример вот так:
S>

S>clean void fail(ref in Vec a, ref out Vec result, clean Action callback)
S>{
S>  result = a;
S>  callback();
S>}
S>

S>Очевидно, что модификатор clean можно также распространять и на делегаты. По вашему определению, с fail всё в порядке — он вызывает только clean метод, с ref in аргументом ничего не делает, мутабельные статические поля не трогает.

Да. Только, боюсь, вместо clean Action будет некий CleanAction с другой сигнатурой определения делегата — с модификатором clean.

S>Теперь вызовем его вот так:
S>

S>var Vec test = new Vec(...);
S>var Vec test2;
S>fail(ref test, ref test2, ()=>{test.Wipe();} )
S>Debug.Assert(test == test2);
S>

S>Наше замыкание — тоже вполне себе clean. Оно вызывает только один метод на test, который тоже clean — он меняет только this, а ведь он ничем не хуже, чем ref out result.

Абсолютно правильные рассуждения. Просто нужна толика внимательности: замыкание является clean, но не является const. Итого, мы опять передаем неконстантную ссылку на переменную test "куда-то", и после этого не можем гарантировать её константности. Как разработчику, так и компилятору это прекрасно известно. То бишь на плюсах я отлично отслеживаю подобные моменты, даже когда использую boost::bind для аналогичных сценариев. Просто в отсутствии clean их трекать приходится сугубо умозрительно, "вручную" соблюдая необходимые мне clean-гарантии.


S>Таким образом, мы видим, что из clean компилятор тоже не может сделать ничего полезного.

Может. Просто пользу надо уметь извлекать. Как именно — я показал в своих примерах в предыдущем посте. То бишь, если мне нужны гарантии, я делаю код таким, чтобы эти гарантии могли быть соблюдены. Коль речь об ООП, то модификатор const так же применяется к методам, в этом случае он означает const this внутри методов и распространяеся на значения всех полей и составных тоже рекурсивно.


S>Попробуйте изменить ограничения на clean метод — возможно, вы всё же получите какую-нибудь пользу

Не хочу! ))
См сюда: http://www.rsdn.ru/forum/philosophy/4836755.1.aspx

Автор: FR
Дата: 31.07.12

Бока ограничений на обязательную иммутабельность я уже описал:

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

То бишь мой вывод такой, что при введении гарантированной иммутабельности в том смысле как ты настаиваешь, когда модификатор приписывается не к переменной, а к типу как таковому, чтобы эти гарантии распространялись в любую сторону, а не только по направлению in вызываемых методов... в общем, в случае такой гарантированной иммутабельности оставаться в рамках парадигмы ООП будет банально неудобно. Вот и всё кино.

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

V>>Абстрактная фабрика, конечно, пример классный. Только в ФП любой функциональный объект — точно такая же абстрактная фабрика. Так был ли мальчик?

K>Мы, вроде бы, не про ФП и паттерны тут говорим, а обсуждаем явно не соотвествующее действительности утверждение "SmallTalk эти паттерны и даром не сдались, у тех свои паттерны". Подавляющее большинство паттернов GOF и прочих, вроде MVC, были придуманы смолтокерами и для Смолтока.

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

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


S>>>>>А кто проверяет эти security — артефакты, передаваемые в виде аргументов?
V>>А как это организованно в виндах, понимаешь? Ну, чтобы я лишнего не писал.
S>Нет. Можно ссылку на MSDN?

msdn security descriptor overview

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379571%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379557%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374876%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379204%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379198%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374807%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379195%28v=vs.85%29.aspx


V>>Конкретно насчет WebRequest.Send(), артефакты безопасности будут переданы при вызове ниже и где-то будет просто уровень TCP-стека, к которому относятся несколько пунктов из политики и которые (эти пункты) будут проверяться в соотв, вызовах TCP. Т.е. модули, отвечающие за сетевой уровень, должны будут попасть внутрь пояса безопасности.
S>Что такое "внутрь"? Я правильно понимаю, что для вызова WebRequest.Send() мой прикладной модуль должен будет иметь у себя в "артефактах безопасности" пункты, разрешающие TCP/IP?
S>Если да — то это, простите, дыра.

)))
нет, прикладной модуль должен иметь внутри себя свой аналог дотнетным WindowsIdentity/WindowsPrincipal, а настройки для юзверов и групп хранятся и проверяются системой. Мне лишь надо расширить исходную модель Windows так, чтобы я мог подавать несколько principal, а перед выполнением охраняемой функциональности работала суперпозиция разрешений/запрещений всех поданных principal.

То бишь, скажем, некоторому юзверю кое-что не разрешено, но при работе конкретно через это приложение ему будет доступна некая функциональность, которую разрешит администратор. Если же будут вхождения deny для некоего приложения, то даже админ не сможет их преодолеть, зашедши иначально с аккаунтом с полным доступом ко всему и запустив это приложение, будь то удаленно или локально.


V>>В общем, какая-то часть системного кода должна быть доверенной всё-равно. Должна быть некая точка опоры, от которой мы отталкиваемся.
S>Вопрос — какая именно часть кода у вас доверенная. Вот, скажем, драйвер GSM-модема от 3rd-party — он доверенный или нет?

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

Здравствуйте, Иван Дубров, Вы писали:

V>>Увы и ах, военные не могут позволить себе полагаться на мифические независимые "достоверные центры", определяющие истинность сертификатов.

ИД>В смысле -- не могут? Почему они не могут завести свои CA и подписывать своими ключами ключи своих устройств?

Могут, но это надо делать централизовано. А система изначально предназначена для создания своей защищенной сети в интернет по миру. Ты же не может сгенерить пару ключей и послать пару по сети, правильно?))

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


ИД>При этом даже если полагаться на сторонние CA (например, для установления первоначального защищённого соединения по которому уже будет передана информация о своём CA), это всё равно будет безопаснее, чем просто передавать публичный ключ устройства.

Вряд ли в таких делах будут полагаться на сторонние CA. ИМХО, когда речь о политике, то все эти вещи не работают. Они работают до тех пор, пока ты им доверяешь. А так ведь сторонний центр может быть частью сценария атаки.


V>>Поэтому, система генерит аналоги сертификатов сама при регистрации конкретных "девайсов" (включая мобильные). Просто, если для проводных устройств можно хотя бы для регистрации подключать их в изолированную локальную сеть, то GSM траффик перехватывается таким же точно образом вообще на раз.

ИД>Я уверен, можно придумать множество вариантов, более защищённых чем то, что ты описал (просто обменяться публичными ключами). Если это потребуется.

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


ИД>А что тут любопытного? Слишком много CA, которым устройства доверяют "по умолчанию" (прописаны во всех браузерах, например), и которые могут быть скомпроментированы.

А вариант заведомо за несколько лет до взлома создания "правдоподобной" CA ты не учитываешь? Все эти CA — сплошной субъективизм.


ИД>В случае если нужно построить прям совсем защищённую сеть, можно развернуть свою PKI.

Можно, но если доступ к ней будет по тому же самому проводу, то man-in-the-middle можно применять на любой стадии. См. замечание насчет де-факто рекурсивности процесса.

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

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

Еще один "доктор по фотографии"...
Курить процедуру обмена ключами.

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

V>>Пруф насчет фанатов? Это только от совсем большого ума жалеть можно.
S>http://compgroups.net/comp.lang.oberon/enumeration-types/1433942
S>Я надеюсь, само собой понятно, что на нишевом языке никто, кроме фанатов, не пишет?

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

V>>Идеологически в мейнстриме enums — это "типизированные" целочисленные константы. Т.е. это два в одном:
V>>1. Эдакие юзверские алиасы для целочисленных типов.
V>>2. Константные значения этих типов.
S>Я не знаю, что именно вы называете мейнстримом.

Известный тебе дотнет пойдет? "Всё-таки я люблю шарп" (С)
Ну я еще упоминал С/С++ и считаю, что они тоже самый что ни на есть мейнстрим.

S>Скажем, енумы в Джаве сделаны сильно по-другому, чем енумы в Object Pascal aka Delphi.

Т.е., когда я говорил о раскраске enums в С++, я должен был иметь ввиду enums из Джавы? ))
И да, в Джаве можно объявлять обычные целочисленные enums практически c такой же семантикой, как в плюсах.

V>>Так что, не от большого ума можа можно лишь пытаться сожалеть о том, что чего-то нет, хотя оно на самом деле есть и даже всяко удобнее.
S>Я улавливаю общий паттерн в вашей манере ведения спора. Вы утверждаете чушь (типа "енум это всего лишь алиас для целочисленного типа"), а потом из неё делаете глубокие выводы.

Я думаю, ты полностью потерял нить беседы:

V>- enum нет
Как это? Куда дели enum?
...
То, что в Обероне их нет — это, мягко говоря, не от большого ума.

Я тебе объясняю, что функциональность enum из мейнстрима в обероне доступна изкаробки. В джаве enums я бы не сказал, что так уж в мейнстриме, они появились недавно, когда основная масса кода популярных джавовских фреймворков уже написана.


V>>Пытаться натягивать set на enum — вот это ляп.
S>Я не понимаю, что значит "натягивать set на enum". Вы что, ещё и путаете Set type с enum type?

Я путаю?

Как это? Куда дели enum?
RTFM:
http://www.delphibasics.co.uk/Article.asp?Name=Sets

Это залет.

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


ARK>Кстати, enum на мой взгляд вообще очень мутная концепция. По крайней мере с точки зрения ООП. Чужеродная примесь. Хотя в некоторых кусках кода выглядит полезно,

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


ARK>однако фиг знает — может быть существует что-то получше енумов.

Существует — алиасинг типов.


ARK>Еще нехороший момент — для удобства использования требует встраивания в компилятор, эмулировать другими языковыми средствами (чтобы с сохранением этого самого удобства) нельзя...

В плюсах можно эмулировать алиасинг без затрат в рантайм. Но муторно в исходнике: статические константы юзверских типов надо сначала объявить внутри класса, а потом проинициализировать вне класса. Такое дублирование раздражает.

> Еще один "доктор по фотографии"...
> Курить процедуру обмена ключами.

Очередной слив в вопросах безопасности засчитан.