Можно ли жить без приватных членов? [re: js изврат ООП]
Непонятно зачем нужно жестко запрещать вызывать какие-то методы у объекта.Это контроль корректности испрользования функционала. Можно жить и без него, но тяжело.
То же касатся и duck typing'а, при всех его плюсах, очень легко облажаться.
хватаетit depends. если ты делаешь какую-нибудь расширяемую систему, в которой может работать чужой код (плагины, например то ты не захочешь полагаться на соглашения, но постараешься обеспечить безопасную работу ядра.
it depends. если ты делаешь какую-нибудь расширяемую систему, в которой может работать чужой код (плагины, например то ты не захочешь полагаться на соглашения, но постараешься обеспечить безопасную работу ядра.Нет, в этом случае приватные методы использовать нельзя — это только иллюзия защиты.
конечно. в этом случае защиту даст только выключенный компьютер.
разверни мысль, в общем
Это контроль корректности испрользования функционала. Можно жить и без него, но тяжело.Зачем он нужен — непонятно. Что без него тяжело — непонятно. Зачем ограничивать пользователей своего кода заранее — непонятно, надо просто указать работу каких функций ты не гарантируешь, если пользователь захочет — любой приватный метод сломает, так что этот контроль — иллюзия. Это вроде азы и много раз везде обсуждалось.
разверни мысль, в общемДаже в ВКШ на лекциях по С++ рассказывают что на такую приватность полагаться нельзя: злоумышленник всегда может отсчитать в своем плагине нужное количество байтиков и загрузить нужный код.
области видимости - защита не от злоумышленника, а от некорректного дизайна
Если ты пишёшь функции, работу которых не гарантируешь, может лучше вообще не писать?
Код в руках врага и чем сложнее ему будет использовать его не по назначению, тем лучше, разве не очевидно?
Код в руках врага и чем сложнее ему будет использовать его не по назначению, тем лучше, разве не очевидно?
давай вернемся к js. немного кода:
Напиши код, который скомпроментирует counter.
upd: добавил return в inc
var app = (function{
var counter = 0;
var inc = function {return counter++};
return {
getNext: function {return inc;}
};
};
Напиши код, который скомпроментирует counter.
upd: добавил return в inc
области видимости - защита не от злоумышленника, а от некорректного дизайнаДа, я это и говорю, спасибо.
Если ты пишёшь функции, работу которых не гарантируешь, может лучше вообще не писать?Почему? Пусть пользователь убоится и понимает что ссзб.
Код в руках врага и чем сложнее ему будет использовать его не по назначению, тем лучше, разве не очевидно?
Защита кода методом "авось", ага.
Защита кода методом "авось", ага.Во-первых, лучше, чем ничего, а во-вторых, это означает, что такое использование было сделано осознанно, а не как следствие
неудачного рефакторинга и прочее. Различие в том, что для того, чтобы обойти защиту в твоём случае достаточно плохо разбираться
в языке, а в моём - нужно уметь испрользовать нетривиальный функционал. В итоге вероятность испрользования по ошибке сводится
почти на нет.
Во-первых, лучше, чем ничегоХуже. Потому что создает иллюзию защиты.
Различие в том, что для того, чтобы обойти защиту в твоём случае достаточно плохо разбираться
в языке, а в моём - нужно уметь испрользовать нетривиальный функционал. В итоге вероятность испрользования по ошибке сводится
почти на нет.
По какой ошибке? У тебя кто враги — твои коллеги? Или пользователи твоей библиотеки? Зачем ты за них думаешь? Подсказал что не стОит эту функцию трогать и хватит.
В общем обсуждение — боян. По теме повторю: есть целые языки где приватность в понимании Жавы и Си игнорируют, аргументов и статей написано много, можно почитать и выбрать. Пережевывать в очередной раз тут незачем.
Пережевывать в очередной раз тут незачем.Зачем тогда начинал?
У тебя кто враги — твои коллеги? Или пользователи твоей библиотеки?т.е. другие возможности ты исключаешь?
Зачем тогда начинал?Почитай плз тред: у чувака проблема что в жаваскритпе нет приватности, я говорю: нет и не надо.
т.е. другие возможности ты исключаешь?Если подумать головой, то нет: я говорю что если код у врага — приватности недостаточно, если у друга — она мешает. Вывод: она не нужна.
Почитай плз тред: у чувака проблема что в жаваскритпе нет приватности, я говорю: нет и не надо.Нет, ты говоришь не "нет, и не надо", а "я не понимаю, зачем". Учту, что не это не повод развивать тему, ок.
Нет, ты говоришь не "нет, и не надо", а "я не понимаю зачем". Учту, что не это не повод развивать тему, ок.А, понял. Действительно, криво сказал.
приватность с одной стороны нужна, но с другой стороны ей часто злоупотребляют.
правильнее было бы разделить приватность и секъюрность.
правильнее было бы разделить приватность и секъюрность.
правильнее было бы разделить приватность и секъюрность.А в Жаве как я понимаю это деление совсем усложнено: кроме приватности есть еще и интерфейсы.
один из стандартных сценариев, когда приватность мешает.
автор библиотеки поддержал только возможность изменения записей по одной, соответственно когда через эти же классы библиотеки за раз прогоняется изменение тысячи (не говоря уже о миллионах) записей - всё жутко тормозит (каждое изменение каждый раз проходит все проверки, а потом каждый раз пересчитываются все зависимые данные).
соответственно, в этом случае хочется аккуратно добавить возможность группового изменения, но это невозможно, т.к. автор библиотеки закрыл всё приватностью, чтобы внешний код не мог испортить внутреннее сложное состояние классов
автор библиотеки поддержал только возможность изменения записей по одной, соответственно когда через эти же классы библиотеки за раз прогоняется изменение тысячи (не говоря уже о миллионах) записей - всё жутко тормозит (каждое изменение каждый раз проходит все проверки, а потом каждый раз пересчитываются все зависимые данные).
соответственно, в этом случае хочется аккуратно добавить возможность группового изменения, но это невозможно, т.к. автор библиотеки закрыл всё приватностью, чтобы внешний код не мог испортить внутреннее сложное состояние классов
А в Жаве как я понимаю это деление совсем усложнено: кроме приватности есть еще и интерфейсы.интерфейс как раз более гуманно, с одной стороны он явно показывает, что можно трогать, и в то же время,
если сам класс открытый, то остается возможность скаститься к классу, и через него провести нужные изменения
интерфейс как раз более гуманно, с одной стороны он явно показывает, что можно трогать, и в то же время,Тем не менее 2 механизма для одного и того же. По логике вещей в этом месте секьюрность и надо встраивать — удобное место решить дело на системном уровне и не парить секьюрностью программиста.
если сам класс открытый, то остается возможность скаститься к классу, и через него провести нужные изменения
Интерфейс - это ни разу не для секьюрности и вообще с приватностью на контачит. Ровно тем же способом, что и у обычного класса, у класса, переданного по интерфейсу ты способен вызвать приватные методы.
Интерфейсы - это способ построения модульного расширяемого и тестируемого кода.
Приватность и прочие модификаторы - это методы построения структуры внутри одного модуля, которые конечно можно сломать, но в обычном случае делать не стоит. (Кстати как тут относятся к приватным конструкторам?)
Секьюрность - это обфускация кода и разнообразные ассерты, к примеру.
Интерфейсы - это способ построения модульного расширяемого и тестируемого кода.
Приватность и прочие модификаторы - это методы построения структуры внутри одного модуля, которые конечно можно сломать, но в обычном случае делать не стоит. (Кстати как тут относятся к приватным конструкторам?)
Секьюрность - это обфускация кода и разнообразные ассерты, к примеру.
вообще с приватностью на контачитВот из вашего жабского туториала:
Implementing an interface allows a class to become more formal about the behavior it promises to provide. Interfaces form a contract between the class and the outside world, and this contract is enforced at build time by the compiler.
Интерфейсы - это способ построения модульного расширяемого и тестируемого кода.
Приватность и прочие модификаторы - это методы построения структуры внутри одного модуля, которые конечно можно сломать, но в обычном случае делать не стоит. (Кстати как тут относятся к приватным конструкторам?)
Секьюрность - это обфускация кода и разнообразные ассерты, к примеру.
Это ты рассказываешь как есть сейчас, а я говорю как
а я говорю как нужноможно сделать по умукак ты это себе представляешь и, главное, зачем?
Зачем он нужен — непонятно. Что без него тяжело — непонятно. Зачем ограничивать пользователей своего кода заранее — непонятно, надо просто указать работу каких функций ты не гарантируешь, если пользователь захочет — любой приватный метод сломает, так что этот контроль — иллюзия. Это вроде азы и много раз везде обсуждалось.Когда я рассказываю об ООП разным неофитам, то для иллюстрации инкапсуляции привожу в пример класс треугольник:
class Triangle
{
public:
Triangle(double a, double b, double c);
void setSides(double a, double b, double c);
double getA;
double getB;
double getC;
double expand(double factor);
}
У данного объекта есть очевидное "внутреннее состояние": длины трех его сторон. Кроме того, очевидно, что не любые три числа являются допустимым внутренним состоянием для объекта: стороны должны быть положительными, и удовлетворять неравенству.
Именно поэтому в публичную часть вынесена только та часть функциональности объекта, использование которой не позволит получить недопустимого внутреннего состояния.
Итак, часть функциональности приватна для того, чтобы объект всегда находился в допустимом состоянии.
Это правило очень удобно тем, что пользователю объекта вообще не следует думать о том, как он устроен, и как его не поломать. Чтобы не поломать объект, достаточно использовать только его публичную часть.
Еще одно дополнение. private можно рассматривать как встроенный метод
надо просто указать работу каких функций ты не гарантируешь
Ровно тем же способом, что и у обычного класса, у класса, переданного по интерфейсу ты способен вызвать приватные методы.на прямую не можешь, можешь только с помощью явного приведения к какому-то другому интерфейсу или классу, у которого эти методы public.
соответственно, в вариантах, когда секьюрность строится на интерфейсах, то уже имеющийся интерфейс(объект доступный через интерфейс) можно приводить только к явно разрешенному набору интерфейсу.
при этом на этапе дизайна код доступен целиком.
> Секьюрность - это обфускация кода и разнообразные ассерты, к примеру.
это не секурность. секьюрность - это CAS ( http://en.wikipedia.org/wiki/Code_Access_Security ) и аналоги.
когда проверяется откуда каждый кусок кода взялся, и какие у него есть права. в частности, например, CAS может запрещать лазейку для доступа к приватным членам через reflection, если у вызывающего кода мало прав.
на CAS основана http://en.wikipedia.org/wiki/Singularity_%28operating_system..., когда вся ОС (ядро, все пользовательские программы) живет в одном адресном пространстве, а защита доступа делается средствами языка, что обеспечивает теоретическую высокую скорость работы из-за отсутствия переключений между ядром и программами.
Именно поэтому в публичную часть вынесена только та часть функциональности объекта, использование которой не позволит получить недопустимого внутреннего состояния.но в тоже время, такой подход запрещает и использовать совместно с этим классом какие-то другие модели, например, модель равностороннего треугольника, который удобно задавать лишь длиной одной стороны.
в идеале же хотелось сказать:
треугольник (без привязки к плоскости) можно задать через длины трех сторон (а можно и как-то по другому).
для того, чтобы такое задание было корректным, длины сторон должны удовлетворять следующим неравенствам.
если треугольник задан корректно, то доступны следующие выводы(свойства):
площадь,
величина углов
и т.д.
а уже к такому определению легко коннектиться определение равностороннего треугольника:
равносторонний треугольник можно задать через длину одной стороны a.
при этом равносторонний треугольник всегда является треугольником(a, a, a
произвольный же треугольник иногда, когда все стороны равны a=b=c, является равностороннем треугольником.
для равностороннего треугольника справедливы следующие выводы(свойства): ...
на прямую не можешь, можешь только с помощью явного приведения к какому-то другому интерфейсу или классу, у которого эти методы public.false. Доступ к приватным методам объекта любого класса доступен через рефлекшн, вне зависимости от того, как передаётся объект. Кастить объект ты не запретишь.
соответственно, в вариантах, когда секьюрность строится на интерфейсах, то уже имеющийся интерфейс(объект доступный через интерфейс) можно приводить только к явно разрешенному набору интерфейсу.
при этом на этапе дизайна код доступен целиком.
ЗЫ посмотрел ссылку. Интересно конечно, но про C#, когда мы говорили про Java. К тому же я, как злоумышленник, могу и такую защиту обойти.
К тому же я, как злоумышленник, могу и такую защиту обойти.не можешь.
> Когда я рассказываю об ООП разным неофитам, то для иллюстрации инкапсуляции привожу в пример класс треугольник
Спасибо! А по теме треда что-нибудь скажешь?
Спасибо! А по теме треда что-нибудь скажешь?
но в тоже время, такой подход запрещает и использовать совместно с этим классом какие-то другие модели, например, модель равностороннего треугольника, который удобно задавать лишь длиной одной стороны.Смысл наследовать равносторонний треугольник от обычного достаточно мал: чем будет отличаться объект равностороннего треугольника и обычного треугольника, созданного равносторонним? Если равносторонние треугольники дают выигрыш, скажем, в каком-то алгоритме, то стоит сделать объект абстрактного треугольника с приватным конструктором и создавать треугольники-расширения (равносторонний, обычный) неким методом-фабрикой.
не можешь.что, этот фреймворк и отладчки все превентивно убивает?
>false. Доступ к приватным методам объекта любого класса доступен через рефлекшн, вне зависимости от того, как передаётся объект. Кастить объект ты не запретишь.
>
>ЗЫ посмотрел ссылку. Интересно конечно, но про C#, когда мы говорили про Java. К тому же я, как злоумышленник, могу и такую защиту обойти.
никогда от SecurityManager-а не ловил SecurityException-ов? тогда мы идем к вам!
>
>ЗЫ посмотрел ссылку. Интересно конечно, но про C#, когда мы говорили про Java. К тому же я, как злоумышленник, могу и такую защиту обойти.
никогда от SecurityManager-а не ловил SecurityException-ов? тогда мы идем к вам!
Спасибо! А по теме треда что-нибудь скажешь?Тема треда: "можно ли жить без приватных членов?"
Отвечаю: "да."
Если ты запрещаешь расширенные ответы в своем треде, заказывал бы голосовалку с двумя вариантами ответов.
Смысл наследовать равносторонний треугольник от обычного достаточно малВот-вот, жесткие private ограничения привлекательны для быдлокодеров, считающих себя умнее тех, кто будет их код использовать.
Если ты запрещаешь расширенные ответы в своем треде, заказывал бы голосовалку с двумя вариантами ответов."Когда я рассказываю неофитам про форум я начинаю с того что такое Интернет".
У тебя не расширенный ответ, а обмусоливание определения. Зачем ты его написал — непонятно. Вопрос же не в том что такое инкапсуляция и зачем она нужна, а в том, надо ли жестко ее ограничивать — про это в твоем посте ни слова не нашел.
это не секурность. секьюрность - это CAS ( http://en.wikipedia.org/wiki/Code_Access_Security ) и аналоги.Скорее аналоги. Потому что в теории разделение на ring0,ring3 тоже безопасно, только вот винда так и не научилась делать безопасных гейтвеев и рекомендует использовать эмуляцию для доса
Вот-вот, жесткие private ограничения привлекательны для быдлокодеров, считающих себя умнее тех, кто будет их код использовать.Ну ты сам уже ответил ведь, какой еще тебе нужен ответ? Мы, быдлокодеры, пишем везде private потому, что любим власть.
> ты сам уже ответил ведь, какой еще тебе нужен ответ?
Ну уж не рассказ о том что такое инкапсуляция
Ну уж не рассказ о том что такое инкапсуляция
Ну давай еще попытку.
Зачем нужно наследование/полиморфизм, если все равно можно самому написать VMT и тайпкасты? И классы зачем, если можно обойтись структурами, а функциям просто передавать this первым аргументом?
Но ведь сделали же, потому что так удобнее было. Тем кто сделал. Ты можешь не пользоваться.
Ты и private можешь не пользоваться, если тебе неудобно. Мне вот - удобно.
Как мы уже выснили выше, это потому что я быдлокодер и думаю, что умнее тех, кто будет мой код использовать.
Зачем нужно наследование/полиморфизм, если все равно можно самому написать VMT и тайпкасты? И классы зачем, если можно обойтись структурами, а функциям просто передавать this первым аргументом?
Но ведь сделали же, потому что так удобнее было. Тем кто сделал. Ты можешь не пользоваться.
Ты и private можешь не пользоваться, если тебе неудобно. Мне вот - удобно.
Как мы уже выснили выше, это потому что я быдлокодер и думаю, что умнее тех, кто будет мой код использовать.
Вот-вот, жесткие private ограничения привлекательны для быдлокодеров, считающих себя умнее тех, кто будет их код использовать.ну да, не дают быдлокодерам, которые считаю, что лучше чем они знают, какая должна архитектура библиотеки быть, всё ломать
Потому что в теории разделение на ring0,ring3 тоже безопасно, только вот винда так и не научилась делать безопасных гейтвеевпроблема в скорости работы. если вспомнить, то NT начиналась с красивой микроядерной архитектуры, но потом из-за проблем с быстродействием такой архитектуры, всё больше и больше частей объединялось вместе, и запихивалось в ring0.
Смысл наследовать равносторонний треугольник от обычного достаточно мал: чем будет отличаться объект равностороннего треугольника и обычного треугольника, созданного равносторонним?открой учебник по геометрии, и выпиши свойства равностороннего треугольника и произвольного треугольника.
это и есть ответ на вопрос - чем класс равносторонний треугольник отличается, от произвольного треугольника, у которого случайно оказалось, что стороны равны.
> Если равносторонние треугольники дают выигрыш, скажем, в каком-то алгоритме, то стоит сделать объект абстрактного треугольника с приватным конструктором
полностью с нуля или как?
вот, например, в классе треугольника был метод расчета площади. для равностороннего треугольника этот метод ты предлагаешь писать заново?
открой учебник по геометрии, и выпиши свойства равностороннего треугольника и произвольного треугольника.причём здесь свойства? Важен только контракт. Наследник должен быть применимым везде, где можно использовать родителя. Соответственно в данном примере это возможно только для неизменяемых данных
причём здесь свойства?потому что каждый метод класса - это и есть свойство из учебника.
> Важен только контракт.
верно, и значит, т.к. равносторонний треугольник удовлетворяет контракту произвольного треугольника, то все методы произвольного треугольника должны автоматически быть применимы для равностороннего треугольника.
> Соответственно в данном примере это возможно только для неизменяемых данных
отчасти да, но есть ряд методов, как обеспечить применимость и для изменяемых данных (можно хотя бы вспомнить ковариантность, контравариантность)
то все методы произвольного треугольника должны автоматически быть применимы для равностороннего треугольника.ты бы сначала описал бы методы этого треугольника.
Вот тебе первый для начала: вытянуть треугольник вдоль одного из углов. Теоретически - запросто
потому что каждый метод класса - это и есть свойство из учебника.Это неверный подход. Классам не всегда есть смысл повторять структуру земных объектов. Можно было бы продемонстрировать это на животных... но вернёмся к фигурам.
Смотри: вот у тебя есть класс треугольник, от него ты унаследовал треугольник равнобедренный. Теперь предположим, что кто-либо создал обычный треугольник, но так, что он на самом деле равнобедренный. И создал другой такой же через наследника. Вопрос заданный выше - это чем отличаются эти два объекта. И то, что они отличаются - это плохо.
Поэтому нам нужно отойти от зависимостей объектов в реальном мире и делать обобщения исходя из специфики задачи. Т.е. возможно мы будем наследовать равнобедренный треугольник не от треугольника, а от абстрактного и переписывать методы выдачи сторон\углов\площади.
Вот тебе первый для начала: вытянуть треугольник вдоль одного из углов. Теоретически - запростоупрощенно, допустим есть метод:
class triangle
{
void expand(double k)
{
this.a = this.a* k;
this.b = this.b * k;
this.c = this.c;
}
}
его можно записать множеством способов
например, так:
triangle expand(this triangle tr, double k)
{
return triangle(tr.a * k, tr.b * k, tr.c);
}
даже такая формулировка уже применима и к равностороннему треугольнику (но при этом результат не остается в том же поле)
можно записать и в более общей формулировке.
return triangle(tr.a * k, tr.b * k, tr.c);ага. Вот и неизменяемые объекты появились. Ты на практике показываешь противоречие между твоим желанием выразить через ООП естественным способом любой объект и его возможность отображать мир. Поэтому забей на естественные свойства и смотри только на котракт. Выполняется - наследник, не выполняется - не наследник. А с треугольниками фишка проходит только если объекты неизменяемы, что, конечно, не соответствует естественному положению дел (я тебе могу запросто привести пример натуральной модели, где треугольники меняют очертания).
ага. Вот и неизменяемые объекты появились.это лишь метод описания
можно тоже самое записать и через изменяемые объекты, а можно предыдущую запись автоматически преобразовывать к этой (и наоборот)
void expand(this triange tr, double k)
{
tr.a = tr.a * k;
tr.b = tr.b * k;
tr.calculate_current_type;
}
данный подход, например, актуален для графического редактора.
зы
если ты действительно хочешь разобраться в данной проблеме, то сначала необходимо ответить на вопрос - что такое тип и зачем он нужен?
ззы
> Поэтому забей на естественные свойства и смотри только на котракт.
контрактный способ - это тоже лишь один из методов описания. имеющий свои плюсы и свои минусы
если ты действительно хочешь разобраться в данной проблеме, то сначала необходимо ответить на вопрос - что такое тип и зачем он нужен?тип - это тип. Контракт, список гарантированных свойств, выраженных через функции и сигнатуры.
upd:
Есть встроенные типы
Есть типы, порождаемые классами
Есть типы, пораждаемые алгеброй типов, например Array[String]
Лишний уровень индирекции канает. Я так проблему эллипса-круга решал на питоне. Там у объектов есть замечательные __dict__ и __class__ и я их налету менял.
тип - это тип. Контракт, список гарантированных свойств, выраженных через функции и сигнатуры.а почему допустим просто нельзя обойтись функциями IsTriangle, IsEquilateralTriangle, IsCircle, IsElliplse? которые на основе текущего состояния определяют, что сейчас есть на самом деле?
а почему допустим просто нельзя обойтись функциями IsTriangle, IsEquilateralTriangle, IsCircle, IsElliplse?обойтись - можно. Ассемблер тьюринг-полный. Можно написать диспетчеризацию и так, как говоришь ты. Вся система типов нужна для статического анализа, поиска ошибок на ранних стадия, выполнения оптимизаций
Вся система типов нужна для статического анализа, поиска ошибок на ранних стадия, выполнения оптимизацийа почему нельзя для этого же просто написать, что данная функция применима, если функция IsEllipse возвращает true?
и пусть компилятор проверяет это.
верно, и значит, т.к. равносторонний треугольник удовлетворяет контракту произвольного треугольника, то все методы произвольного треугольника должны автоматически быть применимы для равностороннего треугольника.Ты сам себе устроил ловушку примером. Приведи пример наследования, суть которого не сводится к добавлению инварианта. Вообще, имхо, неправильно делать class EquiliteralTrialngle: Triangle
если функция IsEllipse возвращает true?эта проблема алгоритмически неразрешима
и пусть компилятор проверяет это.
Вот тебе первый для начала: вытянуть треугольник вдоль одного из углов. Теоретически - запростоКстати, даже не смотря на то, что равносторонний треугольник я бы не рекомендовал выделять в класс, для него существует очевидное решение. От обычного треугольника он отличается наличием инварианта. Соответственно, в случае expand, который бы сделал из него неравносторонний треугольник надо генерировать какой-нибудь InvariantBreakedException.
надо генерировать какой-нибудь InvariantBreakedException.нарушение контракта. Родительский метод такого эксепшна не генерирует. Правильнее всего использовать неизменяемый объект, TriangleForm, и отделить его от остального класса. Получится как и у дакргрея лишний уровень индирекции
Приведи пример наследования, суть которого не сводится к добавлению инварианта.из классики - увеличение состояния. например, CGradientButton:CButton
> не стоит делать class EquiliteralTrialngle: Triangle
в таких языках как C++, Java, C# сильно связано состояние, instance и категории. там нет возмножности описать их по-отдельности, соответственно, если мыслить в терминах этих языков, то легко попасть в ловушку, что ты и сделал.
с точки зрения категорий: EquiliteralTrialngle является частным случаем Triangle, и поэтому EqualityTriangle: Triangle для "читающих" операций, и наоборот для "записывающих" операций
с точки зрения состояния: состояние EquiliteralTrialngle имеет мало общего с состоянием Triangle, но любое состояние EquiliteralTrialngle может быть преобразовано к Triangle, а состояние Triangle может быть преобразовано к EquiliteralTrialngle, лишь для случая когда у Triangle стороны равны.
если считать, что преобразования проводятся над одним instance, то тогда придется иметь дело с объектом с динамическим типом, если преобразования формируют новый instance, тогда каждый объект будет строго одного неменяющегося типа.
и соответственно, mainframe языки (C++, Java, C#) плохо умеют описывать классы для которых, с точки зрения категорий можно задать отношение, а с точки зрения состояния, такого отношения нет.
классический подход предлагает разделить описание на интерфейсы и на само состояние, но описание получается очень громоздким, и все равно неудобным с точки зрения instance-ов.
эта проблема алгоритмически неразрешимаобоснуй.
если к логике компилятора, кроме четких да, нет добавляется "я не знаю", то проблемы останова не существует, и задача становится алгоритмически разрешимой.
ну и зачем нужна такая статическая проверка?
ну и зачем нужна такая статическая проверка?да, потому что нет задачи
в простом варианте задачу стат. проверки можно записать как:
есть выражение: x.f1(..).f2(..).f3(..)...fn(..) и необходимо ответить на этапе разработки(на этапе компиляции) выдаст ли fn ошибку в рантайме или нет?
допустим fn выглядит как:
fn(..)
{
if (!isCircle(..
throw Error;
return Ok;
}
тогда значит на этапе компиляции необходимо решить задачу:
будет ли выражение x.f1(..).f2(..).f3(..)...fn-1(..) соответствовать IsCircle для всех произвольных значений x или нет.
в простом случае (при малой вариативности x) можно просто перебрать все варианты, и не париться.
если вариантов больше, то приходится вводить категории, каждая функция анализируется на предмет того, как она одни категории преобразует в другие, и перебираются уже категории, а не отдельные значения.
сейчас эту задачу решает программист, а не компилятор. программист глядя в потолок придумывает типы, выписывает для каждого преобразования какой тип он берет, какой выдает и т.д. при этом он ленится, и выписывает в лучшем случае 1% зависимостей для преобразований. и соответственно ни о каком переборе вариантов речи вообще не идет.
что, этот фреймворк и отладчки все превентивно убивает?конечно. из под песочницы (когда прав мало) никакой отладчик запустить не получится (попробуй из того же Java-аплета или Silverlight-а запустить отладчик а если у тебя изначально прав было много, и поэтому ты можешь запустить отладчик, то какое это отношение имеет к security?
Вообще, имхо, неправильно делать class EquiliteralTrialngle: TriangleНаследники-инварианты имеют смысл, если для частного случая некая задача решается легче. Вот тебе другой пример, с алгоритмами посложней: мы имеем класс взвешенного графа (с реализованным поиском пути и т.п. дерева и, скажем, разреженного графа. Разумеется все алгоритмы графа работают на его физических подклассах, но знание типа графа позволяет в значительной мере оптимизировать алгоритмы. И тут наследование, разумеется, возможно, но приводит к тому же - часть специальных графов будет обрабатываться неоптимизированными алгоритмами. Так что опять же лучше сделать фабрику, чем повторять классами физическую градацию.
А без инвариантов физическая градация чаще применима.
то какое это отношение имеет к security?Я таки не понимаю, что мы тогда обсуждаем, что злоумышленник захочет сломать наш фреймворк и сделать гадость или что в рамках некой вирт машины можно защититься от злоумышленного кода?
Я таки не понимаю, что мы тогда обсуждаем, что злоумышленник захочет сломать наш фреймворк и сделать гадость или что в рамках некой вирт машины можно защититься от злоумышленного кода?Если взять браузер, то там загруженный код javascript-а, java-аплета, silverlight-а или flash-а находится в одном адресном пространстве с самим браузером. Соответственно, загруженный код может легко оказаться зловредным, и захватить под контроль сам браузер, а дальше и компьютер целиком, и это осуществить мешают лишь те или иные security-технологии.
вот эти security-технологии и обсуждаются (в первую очередь те, которые в строены в сами языки)
Ок. Про эти технологии я согласен с доводами предыдущих докладчиков.
Ну давай еще попытку.Лучше не надо было
Повторю: ты споришь не со мной, а с названием треда. Его придумал Даркгрей. Чтобы спорить со мной надо почитать мои посты.
Но ведь сделали же, потому что так удобнее было. Тем кто сделал. Ты можешь не пользоваться.
Ты споришь про теорию ООП. Есть другие способы мышления кроме ООП, но ООП большинству достаточно понятен. Не надо в 100500ый раз это рассказывать.
Инкапсуляция удобна и есть разные механизмы ее реализации.
Ты понимаешь разницу между private методами в Python и Java? Прочитай .
В этом треде я рассчитывал на что-то бОльшее чем очередное пережевывание тех же доводов: "мне непонятно зачем нужна приватность как в Жаве" означало не "я не знаю что это и как оно работает", а "я не знаю зачем оно работает именно так", потому что обоснование вида "мы все взрослые люди"(прочитай ссылку сначала) на мой взгляд убедительно для питоньего стиля обеспечения приватности, и не видно почему жава свой костыль не выкинет.
БОльшего не случилось.
Ты споришь про теорию ООП. Есть другие способы мышления кроме ООП, но ООП большинству достаточно понятен.Вообще не понял, к чему ты это. Есть и другие занятия, кроме программирования, но этот тред не о них. Как и не о других способах мышления.
Не у всех языковых конструкций есть ЦЕЛЬ. Некоторые возникли спонтанно, исторически. Вирт придумал точку с запятой ставить между операторами, и это прижилось. Сейчас уже глупо обсуждать, чем точка с запятой удобнее, скажем, решетки.
Исследование вопроса "зачем такие приватные члены сейчас?" неизбежно сведется к выяснению "зачем они были такие в языке Smalltalk в 1980-м году?"
Если есть и питон, и жаба - это прекрасно, видовое разнообразие расширяет кругозор. Каких-либо определяющих преимуществ у того или другого подхода к инкапсуляции я не вижу. Как ты сам написал, если тебе очень нужно вызвать приватный метод - ты его и в жабе вызовешь. А если тебе это не нужно - и в питоне не будешь.
Вообще не понял, к чему ты этоДа, ты вообще не понял о чем тред, но объяснять тебе это уже невыгодно.
Не у всех языковых конструкций есть ЦЕЛЬ. Некоторые возникли спонтанно, исторически. Вирт придумал точку с запятой ставить между операторами, и это прижилось. Сейчас уже глупо обсуждать, чем точка с запятой удобнее, скажем, решетки.
Стандарты языка меняются, конкретно в Жаве этот костыль выпрямляется легко хотя бы в самом минимальном виде.
Каких-либо определяющих преимуществ у того или другого подхода к инкапсуляции я не вижу.
+ ко всем остальным, которых ты не увидел, можно посмотреть даже в этом треде на быдлокодеров, не понимающих разницу между секьюростью и инкапсуляцией, которых в Питоне в разы меньше, т.к. в доке явно сказано что менять приватные методы сложно, но можно.
Ты неприятный в интернет-общении тип, а в твоей компетентности я все равно не убедился. Засим устраняюсь из треда.
Примерно в каждом первом треде с твоим участием ты все обсуждение сводишь к требованию читать твои посты.
надо почитать мои посты
Твои посты состоят всегда имеют следующее содержание:
"Вы все говно, а я Д'Артаньян"
"Все что вы делаете говно"
"Читай мои посты"
Удивительно, но твоих постов уже давно никто не читает, потому что это бесполезно.
Примерно в каждом первом треде с твоим участием ты все обсуждение сводишь к требованию читать твои посты.Я тоже расстраиваюсь, но реально читать написанное очень мало кто умеет.
Общие такие обвинения, как у тебя, очень радостны для безмозглых хомячков, но по сути ты рискуешь сесть в лужу как и alepar со своими претензиями.
Может просто ты не умеешь писать так, чтобы всем было понятно?:)
реально читать написанное очень мало кто умеет
Может просто ты не умеешь писать так, чтобы всем было понятно?:)Я не хочу. Это такой фильтр — если человек не способен понимать, то с ним бессмысленно разговаривать. Он не осознает проблемы и мы с ним занимаемся не согласованием предмета обсуждения, а расширением его сознания. Смысл есть только если мне вдруг почему-то будет интересно собеседника учить и удовлетворяться ощущением что "я умнее".
А мне лень, мне интереснее получить новую информацию. Поэтому немного труда приложить можно — показав пару раз что человек говорит не о том. Если это не помогает, то вряд ли он сообразителен настолько, что от него будет полезная информация, не стоит тратить на него время.
Смотри акулой не стань.
>Стандарты языка меняются, конкретно в Жаве этот костыль выпрямляется легко хотя бы в самом минимальном виде.
в этом треде же говорили уже про SecurityManager-ов и прочее? в великом и могучем есть что-то подобное, или для этого надо использовать jython или ещё какие-нибудь извращения?
в этом треде же говорили уже про SecurityManager-ов и прочее? в великом и могучем есть что-то подобное, или для этого надо использовать jython или ещё какие-нибудь извращения?
в этом треде же говорили уже про SecurityManager-ов и прочее? в великом и могучем есть что-то подобное, или для этого надо использовать jython или ещё какие-нибудь извращения?Чего-то говорили в рамках ликбеза про секьюрность. И даже ссылки на нечто подобное в питоне я давал — там такой штуки нет, не осилили. Точнее, штуки сделали, но в них нашлись дырки из-за которых на идею забили и модули deprecated.
Но вообще-то в треде говорили о приватных методах классов. И костыль это схема работы с приватными методами классов.
>Но вообще-то в треде говорили о приватных методах классов. И костыль это схема работы с приватными методами классов.
как же ты предлагаешь эту схему поменять, чтобы не сломать ту же самую секьюрность?
как же ты предлагаешь эту схему поменять, чтобы не сломать ту же самую секьюрность?
как же ты предлагаешь эту схему поменять, чтобы не сломать ту же самую секьюрность?А какое к SecurityManagerу и к секьюрности имеют отношение приватные методы классов?
>А какое к SecurityManagerу и к секьюрности имеют отношение приватные методы классов?
самое прямое - SecurityManager может не позволять вызвать напрямую приватные методы классов.
самое прямое - SecurityManager может не позволять вызвать напрямую приватные методы классов.
самое прямое - SecurityManager может не позволять вызвать напрямую приватные методы классов.Ну пусть не позволяет, это его личное дело. Про то как они (методы) должны быть устроены на примере питона я давал ссылку в треде. Ты ведь ее прочитал?
А какое к SecurityManagerу и к секьюрности имеют отношение приватные методы классов?если для security-запретов можно использовать уже готовое деление на public/private, то это уменьшает кол-во сущностей, и кол-во кода.
>Ну пусть не позволяет, это его личное дело. Про то как они (методы) должны быть устроены на примере питона я давал ссылку в треде. Ты ведь ее прочитал?
прочитал, не вижу кардинальной разницы между тем как это сделано в великом и могучем и java.
прочитал, не вижу кардинальной разницы между тем как это сделано в великом и могучем и java.
если для security-запретов можно использовать уже готовое деление на public/private, то это уменьшает кол-во сущностей, и кол-во кода.Я к тому и спрашивал: сейчас — использует? Проглядел мельком доку по нему, не увидел таких слов.
И в любом случае _использовать_ такое деление никто не мешает, просто SecurityManager будет его (вызов) запрещать когда включен, при этом вопрос можно/нельзя этот вызов в коде писать — отдельный, мы же выяснили что вызвать приватный метод и сейчас можно.
>Я к тому и спрашивал: сейчас — использует? Проглядел мельком доку по нему, не увидел таких слов.
да иначе для чего по-твоему нужен вот
этот метод?
да иначе для чего по-твоему нужен вот
этот метод?
да иначе для чего по-твоему нужен вотХороший метод. Вот я не вижу чем друг другу мешают приватность и секьюрность, тем более при наличии такого метода.
этот метод?
Так что приватность можно исправлять в любом удобном направлении.
>Так что приватность можно исправлять в любом удобном направлении.
для чего? чтобы фанаты великого и могучего радовались?
для чего? чтобы фанаты великого и могучего радовались?
для чего? чтобы фанаты великого и могучего радовались?Ты точно почитал ссылку и обсуждение почему приватные методы в питоне не приватные?
Чтобы оставалась возможность использования приватных методов, даже если разработчик библиотеки "неправильно" расставил public & private.
> Чтобы оставалась возможность использования приватных методов, даже если разработчик библиотеки "неправильно" расставил public & private.
Ты часто вызываешь несвои приватные методы?
Даже не так. Тебе хоть раз это приходилось делать?
Ты часто вызываешь несвои приватные методы?
Даже не так. Тебе хоть раз это приходилось делать?
Даже не так. Тебе хоть раз это приходилось делать?Да, даже мне приходилось это делать, притом что кодил я не так уж много.
Уверен, что приходилось? Интересно посмотреть, что за ситуация.
Уверен, что приходилось? Интересно посмотреть, что за ситуация.Пример (выдуманный): есть десериализатор (или как это правильно) csv, который чудесно умеет делать все нужные штуки с csv, но не умеет поддерживать юникод — там регекспы без него внутри в приватном методе написаны.
Подходит?
Подходит?А я приведу пример юнит тестов, которые тестируют закрытое API
Не уверен, что понял, что именно тебе нужно.
Разве в описании тут http://docs.python.org/library/csv.html не решение твоей проблемы?
В код я не глядел особо, гляну на досуге, так что, наверное, всё же не так понял.
Даже если проблема в другом и действительно по-другому никак, правильно я понимаю, что
тебя вынуждают так делать криво написанные библиотеки? Так тогда это проблема библиотек.
Ты на каждом углу кричишь, что всё уже давно написано, на проверку оказывается, что надо
допиливать, да еще и используя плохой код (быдлокод, на твоём языке). Тогда да, вам оно
действительно мешает, но зачем проецировать комплексы на другие языки, непонятно.
Разве в описании тут http://docs.python.org/library/csv.html не решение твоей проблемы?
В код я не глядел особо, гляну на досуге, так что, наверное, всё же не так понял.
Даже если проблема в другом и действительно по-другому никак, правильно я понимаю, что
тебя вынуждают так делать криво написанные библиотеки? Так тогда это проблема библиотек.
Ты на каждом углу кричишь, что всё уже давно написано, на проверку оказывается, что надо
допиливать, да еще и используя плохой код (быдлокод, на твоём языке). Тогда да, вам оно
действительно мешает, но зачем проецировать комплексы на другие языки, непонятно.
Не уверен, что понял, что именно тебе нужно.Ну вот. Поэтому я и не хотел приводить конкретный пример — ты полез сразу конкретную проблемку решать. Ты думать пошире умеешь? Давай я тебе подробнее намекну что это десериализатор, а не "ридер", давай придумаю функциональность которой в нем нет, если пример непонятен.
Разве в описании тут http://docs.python.org/library/csv.html не решение твоей проблемы?
В код я не глядел особо, гляну на досуге, так что, наверное, всё же не так понял.
Даже если проблема в другом и действительно по-другому никак, правильно я понимаю, что
тебя вынуждают так делать криво написанные библиотеки?
Ну почти. Криво надо написать в кавычках: "криво". Потому что много случаев когда разработчик плохо продумал варианты использования библиотеки, или продумал не так: банально не понял что один из его приватных методов вообще говоря решает интересную и другим задачу.
Так тогда это проблема библиотек.
Спасибо, капитан.
Ты на каждом углу кричишь, что всё уже давно написано, на проверку оказывается, что надо
допиливать, да еще и используя плохой код (быдлокод, на твоём языке).
Ужас, правда? Библиотеки иногда приходится дописывать!
Тогда да, вам оно
действительно мешает, но зачем проецировать комплексы на другие языки, непонятно.
Тебе непонятно потому что у тебя в работе маленькая предметная область, имеющая слабую связь с реальным миром.
> Давай я тебе подробнее намекну что это десериализатор, а не "ридер"
Не десериализатор, а десериализатор (или как это правильно). В душе не ебу, что ты подразумеваешь под последним.
> Потому что много случаев когда разработчик плохо продумал варианты использования библиотеки, или
> продумал не так: банально не понял что один из его приватных методов вообще говоря решает интересную и другим задачу.
Тут появляется слишком много условностей, типа "лицензия не позволяет видоизменять код", "разработчик оказался на редкость асоциальным типом и не идёт на контакт по поводу модификации библиотеки, либо связаться с ним нет никакой возможности, ну, либо функциональность надо получить уже вчера", "мы готовы зафиксировать версию библиотеки и ни в коем случае ее не обновлять, либо каждое обновление аккуратно смотреть, не выпилилось ли что-то из нами использованного не по назначению". Если всё это имеет место быть (что уже маловероятно то вперёд, говнокодь. Я бы всерьз задумался об использовании такой библиотеки. Это всё про внешние либы. Про внутренние сказать не смогу. Ни разу не встречал такого с функциональностью, включённой в java se, с ee не работал, может, кто подскажет примеры.
> Тебе непонятно потому что у тебя в работе маленькая предметная область, имеющая слабую связь с реальным миром.
Ну так просвети меня, а то что же это получается, есть улучшения языка, без которого ни один жава-программист просто жить не может (хотя слышал я пока это только от тебя а мужики-то не знают.
> Ужас, правда? Библиотеки иногда приходится дописывать!
Не знаю, ни разу не приходилось это делать таким способом. Правда ужас? Или только в первый раз больно?
Не десериализатор, а десериализатор (или как это правильно). В душе не ебу, что ты подразумеваешь под последним.
> Потому что много случаев когда разработчик плохо продумал варианты использования библиотеки, или
> продумал не так: банально не понял что один из его приватных методов вообще говоря решает интересную и другим задачу.
Тут появляется слишком много условностей, типа "лицензия не позволяет видоизменять код", "разработчик оказался на редкость асоциальным типом и не идёт на контакт по поводу модификации библиотеки, либо связаться с ним нет никакой возможности, ну, либо функциональность надо получить уже вчера", "мы готовы зафиксировать версию библиотеки и ни в коем случае ее не обновлять, либо каждое обновление аккуратно смотреть, не выпилилось ли что-то из нами использованного не по назначению". Если всё это имеет место быть (что уже маловероятно то вперёд, говнокодь. Я бы всерьз задумался об использовании такой библиотеки. Это всё про внешние либы. Про внутренние сказать не смогу. Ни разу не встречал такого с функциональностью, включённой в java se, с ee не работал, может, кто подскажет примеры.
> Тебе непонятно потому что у тебя в работе маленькая предметная область, имеющая слабую связь с реальным миром.
Ну так просвети меня, а то что же это получается, есть улучшения языка, без которого ни один жава-программист просто жить не может (хотя слышал я пока это только от тебя а мужики-то не знают.
> Ужас, правда? Библиотеки иногда приходится дописывать!
Не знаю, ни разу не приходилось это делать таким способом. Правда ужас? Или только в первый раз больно?
Не десериализатор, а десериализатор (или как это правильно). В душе не ебу, что ты подразумеваешь под последним.Нет нормального стандарта CSV, есть общепринятая практика. Мы хотим не просто распарсить CSV, а сгенерировать какую-то структуру, желательно на лету. Пример: загрузить данные из csv-фикстур в БД. Оказывается что работает это хорошо только для простых случаев.
Тут появляется слишком много условностей, типа "лицензия не позволяет видоизменять код", "разработчик оказался на редкость асоциальным типом и не идёт на контакт по поводу модификации библиотеки, либо связаться с ним нет никакой возможности, ну, либо функциональность надо получить уже вчера", "мы готовы зафиксировать версию библиотеки и ни в коем случае ее не обновлять, либо каждое обновление аккуратно смотреть, не выпилилось ли что-то из нами использованного не по назначению".
Спасибо, капитан.
Если всё это имеет место быть (что уже маловероятно то вперёд, говнокодь. Я бы всерьз задумался об использовании такой библиотеки. Это всё про внешние либы
Задумайся и напиши вместо нее свою, как какой-нть Бачан с ugh или яндексоиды со своим Фантомом. Если ты расскажешь о своих пожеланиях переписать библиотеку человеку с бизнес-логикой он даст тебе по наглой рыжей морде и будет абсолютно прав.
Ну так просвети меня, а то что же это получается, есть улучшения языка, без которого ни один жава-программист просто жить не может (хотя слышал я пока это только от тебя а мужики-то не знают.
Приведи ссылку на мое такое утверждение, истеричка.
Не знаю, ни разу не приходилось это делать таким способом. Правда ужас? Или только в первый раз больно?
Не, не особо ужас. Ты просто книжек не читаешь , поэтому такой зашуганный.
> Если ты расскажешь о своих пожеланиях переписать библиотеку человеку с бизнес-логикой
> он даст тебе по наглой рыжей морде и будет абсолютно прав.
Приведи ссылку на мое такое утверждение, истеричка.
> Не, не особо ужас. Ты просто книжек не читаешь , поэтому такой зашуганный.
Не понял вопроса - не беда, скажи собеседнику, чтоб больше читал.
>> Ну так просвети меня, а то что же это получается, есть улучшения языка, без которого
>> ни один жава-программист просто жить не может (хотя слышал я пока это только от тебя а мужики-то не знают.
> Приведи ссылку на мое такое утверждение, истеричка.
Может, ты просто книжек не читаешь
А вообще печально, что тред опять скатился до оскорблений. Надоело.
> он даст тебе по наглой рыжей морде и будет абсолютно прав.
Приведи ссылку на мое такое утверждение, истеричка.
> Не, не особо ужас. Ты просто книжек не читаешь , поэтому такой зашуганный.
Не понял вопроса - не беда, скажи собеседнику, чтоб больше читал.
>> Ну так просвети меня, а то что же это получается, есть улучшения языка, без которого
>> ни один жава-программист просто жить не может (хотя слышал я пока это только от тебя а мужики-то не знают.
> Приведи ссылку на мое такое утверждение, истеричка.
Может, ты просто книжек не читаешь
А вообще печально, что тред опять скатился до оскорблений. Надоело.
Приведи ссылку на мое такое утверждение, истеричка.Я не вижу другого варианта, если ты не хочешь использовать либу в которой чуток не так спроектировано АПИ, а аналогичной хорошей либы нет. Если ты в такую ситуацию не попадал, то как раз и говорю — узкая предметная область у тебя.
Не понял вопроса - не беда, скажи собеседнику, чтоб больше читал.
Если не понял ответа — тоже годится.
Может, ты просто книжек не читаешь
Читаю: "Гипербола свойственна и риторическому, ораторскому стилю, как средство патетического подъёма, равно как и романтическому стилю, где пафос соприкасается с иронией", за иронию ты и получил ответный риторический прием, в чем проблема?
А вообще печально, что тред опять скатился до оскорблений. Надоело.
Ты сам этого .
Возможно, я предложу очевидное, но давайте больше просто не будем общаться с Но (ну или хотя бы в этой теме). Он тут нахер никому не сдался, пользы с него как с козла молока, зато он пытается почему-то самоутвердиться.
Оставить комментарий
pilot
Может я конечно не понимаю, но вроде замыкания и приватные методы это совсем разные штуки. Замыкания использовать удобно, просто не надо думать что это такой костыль для приватности.Непонятно зачем нужно жестко запрещать вызывать какие-то методы у объекта. В питоне не рекомендуется вызывать метод, название которого начинается с подчеркивания, и очень не рекомендуется — если с двух подчеркиваний. Такого соглашения хватает.