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

S>Вроде бы нет. Я таки выбил из него ссылки на то, что он столь высокомерно цитирует. Это не Smalltalk. Это Us — настолько академический проект, что smalltalk на его фоне просто заезженный мейнстрим.

Поделись ссылочкой... А то "us" заезженное слово, по нему нифига в Гугле не находится

VladD2 wrote:

Обсуждение личностей является злостным оффтопом...

> Здравствуйте, _vovin, Вы писали:
>
> Мне кажется, что ты боришся за очень странные идиалы. Ты все время пыташся объяснить всем окружающим, что вокруг куча идиотов пишущих невменяемые библиотеки поставляемые исключительно в виде неизменяемых компонентов. И что тебе лично постоянно приходится пользоваться этими компонентами постоянно нарываясь на невменяемость авторов. При это ты делашь вывод, что все ораничения (точнее инкапсуляци) по сути есть козни дьявола и только системы плюющие на инкапсуляцию есть истина в последней инстанции.

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

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

>
> А может быть ты живешь в не нормальном мире? Может все же создатели библиотек несколько мудрее чем нерадивые пользователи? Может они не зря ставят private на методах и переменных?

Ненормальный = отличный от твоего?
В обычном мире мудрость/глупость не сильно коррелирует с создателями и
пользователями библиотек. Но пользователь в любом случае в целом умнее
именно для своего приложения, поэтому ему и решать. А создатели тоже
очень умные, т.к. используют свои библиотеки уже для *своих* приложений,
но у них есть очевидно преимущество — они могут быстренько подправить
непреодолимые ограничения своей библиотеки. У пользователей *частенько*
такой возможности нет.

>
> Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.

Учимся не говорить за всех.
А ты не думал, что private может быть поставлен потому что в этом
конкретном месте про реюзабилити никто специально не думал? Или в ходе
автоматического рефакторинга (Extract Method) или просто нежелания дать
некоторые возможности? Даже если автор очень умен и вроде бы все
продумал, где гарантия, что он учел все теоретические варианты?

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

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

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

Читаем все, что написано. Предложенный мной вариант инкапсуляции
содержит бесконечное количество областей видимости (это отметил и Sinclair).

Тема тобой не изучена, разговаривать дальше пока не о чем.

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

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

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

VD>>Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
S>Вроде бы нет. Я таки выбил из него ссылки на то, что он столь высокомерно цитирует. Это не Smalltalk. Это Us — настолько академический проект, что smalltalk на его фоне просто заезженный мейнстрим.
S>Прикол в том, что тот подход, который проповедует _vovin, преследует ровно те же цели, что и protected/private.

Мне показалось, что _vovin вообещ исповедут мысль о том, что все эти "protected/private" мешают ему делать то что он хочит с чужими библиотеками. И мне показалось, что он несколько раз говорил, что подобных проблем в Смолтоке у него нет. Можно переспросить его?

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

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

Забавно. Значит они не в праве определить публичный интерфейс своего класса и скрыть реализацию? Или они попросту не способны это сделать?

А ты когда нибудь слышаль такой термин "связанность"? Как ты думашь, как можно развивать библиотеку если куча уверенных в себе орлов влезли в ее кишки и пользуются ими как хотят? А если я в следующей вресии своего класса захочу изменить эти кишки? Ну, или я захочу использовать какую-то иную реализацию некого алгоритма? Что выслушивать гневные крити таких уверенных в себе "вертай все назад..."?

_> Поэтому пусть они не будут создавать
_>жестких *непреодолимых* ограничений, и многие им скажут спасибо.

Грамотный разработчик определяет публичный интерфейс предоставляющий запланированную функциональность. Все остальное скрывается от потребителя. Потребитель видит класс как черный ящик с некоторым интерфейсом. Если автор не предоставил нужной функциональности через публичный интерфейс, то это просто не очень хорошая реализация. И стоит найти другую, убедить автора исправить свою ошибку, или написать собственную. А лезь в чюжое нижнее белье, да еще в большинстве не понимая всей сути происходящего — это самый плохой вариант.

_>А бороться нужно с такими писаками как ты,

Нда. Уровень ниже плинтуса.

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

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

_>Ненормальный = отличный от твоего?

Нормальны == квалифицированный, грамотный.

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

Мудрость и глупость вообще не коррелируют. Это просто свойства людей. Но эдак мы уж совсем уйдем в абстрактную философию.

_> Но пользователь в любом случае в целом умнее
_>именно для своего приложения, поэтому ему и решать.

Ясно. Именно этот вопрос меня и интересовал. Пользователь умнее. Это ему ведь нужен публичный интерфейс. И что там планировал разработчик класса пользователя колыхать не должно.

Боюсь, с тобой многие не согласятся. И уж точно ты противоречишь идеям ООП (на которые периодически ты так любишь ссылаться).

_> А создатели тоже
_>очень умные, т.к. используют свои библиотеки уже для *своих* приложений,
_>но у них есть очевидно преимущество — они могут быстренько подправить
_>непреодолимые ограничения своей библиотеки. У пользователей *частенько*
_>такой возможности нет.

А может быть это нормально? Почему ты не удивляешся тому, что ты не можешь быстренько подпрвить внутренее устройство кофемолки или принтера? Ну, или исправить микросхему чтобы твой монофонический приемник стал ДВД-плеером?

Мир не идеален. Бывают просто кривые библиотеки. Ищи библиотеки с исходниками. Или коришись с авторами. На худой конец создай свой аналог класса/библиотеки. Но не нужно ратовать за хаки создающие кучу пролем на ровном месте.

>> Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.

_>Учимся не говорить за всех.

Это хорошо, что ты учишся это делать. Еще нужно учиться не приклеивать ярлыков и видеть только то что есть.

Я, как ты мог заметить, говорю за себя и соглашаюсь с одним человеком.

_>А ты не думал, что private может быть поставлен потому что в этом
_>конкретном месте про реюзабилити никто специально не думал?

Тут и думать нечего. Может. Более того частенько так и происходит. В прочем, так же как частенько программисты ставят знак "-" вместо "+" и т.п. Это называется ошибкой.

_> Или в ходе автоматического рефакторинга (Extract Method) или просто нежелания дать некоторые возможности? Даже если автор очень умен и вроде бы все продумал, где гарантия, что он учел все теоретические варианты?

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

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

Очень похоже на безграмотную организацию проекта и на столь же безграмотное проектирование. Хотя для рельного вывода нужно иметь намного больше информации.

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

_>Читаем все, что написано. Предложенный мной вариант инкапсуляции
_>содержит бесконечное количество областей видимости (это отметил и Sinclair).

Синклер отметил, что предложенный тобой вариант вообще не жизненоспособен. Или я его не так понял?

Потом ты как-то не очень хорошо объяснил как при твоем подходе защититься от любителей покапаться с чужой реализацией?

_>Тема тобой не изучена, разговаривать дальше пока не о чем.

Доктор сказал в морг, значит в мор. Не занимайтесь самоличением. Так что ли?

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

Ура, ура. Я понял что имеется тут ввиду. Несмотря на путанные объяснения господина _vovin и самой статьи. Считай что множественная диспечеризация только с помощью интерфейсов(в терминах мейнстрима). Эта штука мне нравится.
Только одно:
Какого x... э.. с... у......... с я...... назвали это layer approach и взяли эти дурацкие термины.

To Sinclair and VladD2: Вообще у меня создалось впечатление (и не сейчас) что если бы допустим Net 3.0 CAS шифровала private часть класса, то вы бы это называли как раз той самой оптимальной инкапсуляцией которую ждал весь мир. Ничего личного, но впечатление такое есть. По моему нельзя относиться к ней как к ДОГМЕ. Все хорошо в меру.
Хочу заметить также, что статья 96 года, и на него и ориентирована.

С уважением, Gleb.
ЗЫ: Кто безгрешен? Кто не нарушал инкапсуляцию, пусть первым бросит в меня килобайтом.

VladD2 wrote:

> Здравствуйте, _vovin, Вы писали:
>
> _>Ты ошибся, авторов я считаю вполне умными и адекватными, но не им решать
> _>какой вариант использования их библиотеки является наилучшим для моего
> _>приложения для конкретной ситуации.
>
> Забавно. Значит они не в праве определить публичный интерфейс своего класса и скрыть реализацию? Или они попросту не способны это сделать?

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

>
> А ты когда нибудь слышаль такой термин "связанность"? Как ты думашь, как можно развивать библиотеку если куча уверенных в себе орлов влезли в ее кишки и пользуются ими как хотят? А если я в следующей вресии своего класса захочу изменить эти кишки? Ну, или я захочу использовать какую-то иную реализацию некого алгоритма? Что выслушивать гневные крити таких уверенных в себе "вертай все назад..."?

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

>
> _> Поэтому пусть они не будут создавать
> _>жестких *непреодолимых* ограничений, и многие им скажут спасибо.
>
> Грамотный разработчик определяет публичный интерфейс предоставляющий запланированную функциональность. Все остальное скрывается от потребителя. Потребитель видит класс как черный ящик с некоторым интерфейсом. Если автор не предоставил нужной функциональности через публичный интерфейс, то это просто не очень хорошая реализация. И стоит найти другую, убедить автора исправить свою ошибку, или написать собственную. А лезь в чюжое нижнее белье, да еще в большинстве не понимая всей сути происходящего — это самый плохой вариант.



>
> _>А бороться нужно с такими писаками как ты,
>
> Нда. Уровень ниже плинтуса.
>
> _> которые норовят провести
> _>анализ собственной проекции других личностей с учетом штампов,
> _>сложившихся на основе неадекватно восприятой информации. =)
>
> Боюсь я тебя растрою. Анализировать твою лично нет никакой нужды. Твои аргументы явно слабоваты и достаточно проанализировать их. Данный порыв хамства, который видимо тебя и обрадовал, только подтверждает это.

Ответ на сарказм — вровень с плинтусом. =)

>
> _>Ненормальный = отличный от твоего?
>
> Нормальны == квалифицированный, грамотный.
>
> _>В обычном мире мудрость/глупость не сильно коррелирует с создателями и
> _>пользователями библиотек.
>
> Мудрость и глупость вообще не коррелируют. Это просто свойства людей. Но эдак мы уж совсем уйдем в абстрактную философию.

Значит сойдемся, что все умные.

>
> _> Но пользователь в любом случае в целом умнее
> _>именно для своего приложения, поэтому ему и решать.
>
> Ясно. Именно этот вопрос меня и интересовал. Пользователь умнее. Это ему ведь нужен публичный интерфейс. И что там планировал разработчик класса пользователя колыхать не должно.

А если пользователь умный настолько, что заметил баг в библиотеке? Или
что увидел неоправданный private на метод, который можно переопределить
и этим избавиться от вагона кода?

>
> Боюсь, с тобой многие не согласятся. И уж точно ты противоречишь идеям ООП (на которые периодически ты так любишь ссылаться).

Брось, каждый под ООП понимает столько разного, прям ужас.

>
> _> А создатели тоже
> _>очень умные, т.к. используют свои библиотеки уже для *своих* приложений,
> _>но у них есть очевидно преимущество — они могут быстренько подправить
> _>непреодолимые ограничения своей библиотеки. У пользователей *частенько*
> _>такой возможности нет.
>
> А может быть это нормально? Почему ты не удивляешся тому, что ты не можешь быстренько подпрвить внутренее устройство кофемолки или принтера? Ну, или исправить микросхему чтобы твой монофонический приемник стал ДВД-плеером?

Т.е. все-таки ты предполагаешь, что пользователь всегда глупее? А если
он на досуге эти кофемолки мастерит и прошивки для двд правит?

>
> Мир не идеален. Бывают просто кривые библиотеки. Ищи библиотеки с исходниками. Или коришись с авторами. На худой конец создай свой аналог класса/библиотеки. Но не нужно ратовать за хаки создающие кучу пролем на ровном месте.

Библиотеки с исходниками — круто. Но как только тебе нужно
сертифицировать определенные версии всех библиотек и написать якобы
чуточку кода, чтобы это все склеить, а потом оказывается, что во всех
библиотеках нужно подправить кучу багов и добиться от них реюзабилити,
которая в них не заложена из-за private, то рисуется совсем другая картина.
А про хаки ты зря. Если тебе такой подход не нравится, это еще не значит
хак. В скриптовых языках вообще отсутствует контроль доступа — это одна
противоположность. Делать private все, что не в публичных интерфейсах —
это вторая противоположность. Но, как обычно, противоположности сходятся
в одной точке.

>
>
>>>Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.
>
>
> _>Учимся не говорить за всех.
>
> Это хорошо, что ты учишся это делать. Еще нужно учиться не приклеивать ярлыков и видеть только то что есть.

Не придирайся. Я говорю по факту — я увидел абсолютно тупо навешанный
private, который напрашивается быть protected, чтобы этот метод был
перегружен.
Но все равно в твоей реальности я отношусь к "просто не очень
дальновидные люди (мягко выражаясь) не способные адекватно оценить
ситуацию"?

>
> Я, как ты мог заметить, говорю за себя и соглашаюсь с одним человеком.
>
> _>А ты не думал, что private может быть поставлен потому что в этом
> _>конкретном месте про реюзабилити никто специально не думал?
>
> Тут и думать нечего. Может. Более того частенько так и происходит. В прочем, так же как частенько программисты ставят знак "-" вместо "+" и т.п. Это называется ошибкой.

— на + меняется в ходе тестирования, а private на protected только если
кто-то в дальнейшем уткнется в него носом, но у него уже может не быть
такой возможности — если версии библиотек жестко фиксируются.
На хороший дизайн юнит-тестов не придумаешь.

>
> _> Или в ходе автоматического рефакторинга (Extract Method) или просто нежелания дать некоторые возможности? Даже если автор очень умен и вроде бы все продумал, где гарантия, что он учел все теоретические варианты?
>
> Гарантия в его имени. Хороший автор будет исправлять ошибки и стараться не допустить их. Как подстраховка может быть что библиотеку можно поставлять с исходниками. К сожалению подправление библиотек для личных нужд приводит к тем же проблемам что и зализание в чужие потраха через методы среды или языка. Но тут хотя бы можно попытаться убедить разработчика класса в неправоте и добиться того, чтобы в следующей вресии проблема была устранена.

Нет, это ошибка должна быть как-то устранена к такой-то релиз-дате и
точка. А библиотеки менять нельзя.
Может быть хороший автор все делает хорошо, но и супер-мастер местами
бывает откровенно тупит.

>
> _>Угу, вот тебе мой недавний пример — последняя версия ядра системы сдана
> _>и сертифицирована, работать нужно именно с ней, переход на новую версию
> _>не намечается да и смерти был бы подобен такой переход если бы захотели.
> _>В итоге заводится собственный бранч, из нужного класса копируются
> _>буквально все методы и делается небольшая правочка в одном из них.
>
> Очень похоже на безграмотную организацию проекта и на столь же безграмотное проектирование. Хотя для рельного вывода нужно иметь намного больше информации.

Молодец. Я бы с тобой пожалуй согласился, если бы в задачах проекта ядра
было определение всех самых невероятных возможностей реюзабилити.
А так — не катит. Проект был сдан в срок, функциональность закрыта —
значит он вполне хороший.

>
>
>>>Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
>
>
> _>Читаем все, что написано. Предложенный мной вариант инкапсуляции
> _>содержит бесконечное количество областей видимости (это отметил и Sinclair).
>
> Синклер отметил, что предложенный тобой вариант вообще не жизненоспособен. Или я его не так понял?

По-моему он сказал, что вариант покрывает кучу возможностей. Но ему
все-таки не нравится.

>
> Потом ты как-то не очень хорошо объяснил как при твоем подходе защититься от любителей покапаться с чужой реализацией?

У меня такой задачи не стоит, но она реализуема. Нет времени все описывать.

>
> _>Тема тобой не изучена, разговаривать дальше пока не о чем.
>
> Доктор сказал в морг, значит в мор. Не занимайтесь самоличением. Так что ли?

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

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

T>Поделись ссылочкой... А то "us" заезженное слово, по нему нифига в Гугле не находится

http://citeseer.ist.psu.edu/cache/papers/cs/280/ftp:zSzzSzftp.ccs.neu.eduzSzpubzSzjournalszSztaposzSztaposadmzSzczSzsubjectivityzSzSmith-uszSzthePaper2.pdf/smith96simple.pdf

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Я так и не понял, почему "инкапсуляция = наличие модификаторов"?
потому, что инкапсуляция == возможность скрывать детали реализации от разных потребителей. модификаторы доступа дают возможность классифицировать этих потребителей. Ты точно читаешь то, что я пишу?

ANS>Моё виденье такое: поведение объекта зависит от его состояния. Закрыв доступ к его состоянию мы получаем невозможность установки объекта в невалидное состояние со стороны. Нет возможности поломать состояние — есть инкапсуляция. А куда тут притулить модификаторы?
Ну естественно. В таком понимании инкапсуляции модификаторы не нужны.

ANS>Ну, так бы сразу и сказал, что модификатором можно прикрыть дырку в языке. Было бы создание объектов через посылку сообщения изначально (читай, через фабрику), не было б надобности закрывать конструктор.
Помимо конструктора, приходится еще много чего закрывать.

ANS>>Я так и не понял, почему "инкапсуляция = наличие модификаторов"?
S>потому, что инкапсуляция == возможность скрывать детали реализации от разных потребителей. модификаторы доступа дают возможность классифицировать этих потребителей. Ты точно читаешь то, что я пишу?

сто пудов сверху по ветке можно найти изначальный вопрос: какая польза то такого понимания инкапсуляции.
Ты сказал, что польза — маленький публичный интерфейс. Я думаю, если у класса интерфейс большой, то
просто приложив "private/protected" к "не нужным потребителю" методам проблему не решить. Тут рефакторить нужно.
Еще?

ANS>>Моё виденье такое: поведение объекта зависит от его состояния. Закрыв доступ к его состоянию мы получаем невозможность установки объекта в невалидное состояние со стороны. Нет возможности поломать состояние — есть инкапсуляция. А куда тут притулить модификаторы?
S>Ну естественно. В таком понимании инкапсуляции модификаторы не нужны.

Хе-хе. Тогда, на вопрос сверху можно не отвечать, ибо мы сошлись в точке когда понимаем "понимание" друг друга, но не принимаем его.

ANS>>Ну, так бы сразу и сказал, что модификатором можно прикрыть дырку в языке. Было бы создание объектов через посылку сообщения изначально (читай, через фабрику), не было б надобности закрывать конструктор.
S>Помимо конструктора, приходится еще много чего закрывать.

Если так много примеров, то можно и еще хоть один привести?