Веб и ООП
даже если не знают, чем private отличается от protectedБлин, это же в википедии написано.
даже если не знают, чем private отличается от protectedВ разных языках они по-разному отличаются.
В разных языках они по-разному отличаются.Не важно, речь-то о дрйгом — о массовом психозе.
Казалось бы, и где тут веб? Если все стенания на тему баз данных, то я бы посмотрел на процедурный ORM. Основное направление развития программных технологий сейчас, имхо, в повальную абстракцию. И очень часто это оправдано. Так что веб - не веб. Один хрен.
да-да, цепепе сосёт.
терпеть не могу ооп-штучки в питоне 
Поставь оффтоп и начнем дискус, о чей-то бот 
пианист, твоя ссылка — боян. я тут уже ее постил. 
и никому она полезной не окажется, конечно же.
ведь ООП позволяет вводить Абстракции, описывать Реальный Мир, пользоваться преимуществами Полиморфизма.
а Горный — это просто пидорас какой-то, который в искусстве ничего не понимает.
и никому она полезной не окажется, конечно же.
ведь ООП позволяет вводить Абстракции, описывать Реальный Мир, пользоваться преимуществами Полиморфизма.
а Горный — это просто пидорас какой-то, который в искусстве ничего не понимает.
Если все стенания на тему баз данных, то я бы посмотрел на процедурный ORM.
Я бы лучше посмотрел без ORM. Чтоб удобно было.
видел я этого Горного на конференции как-то
из забавных утверждений оного "Любой веб-скрипт это "получить команду пользователя, достать данные из базы, положить в базу изменения, вывести результат пользователю", иногда одна-две-три стадии оказываются не нужны. Где здесь место для объектов-событий-сообщений?"
и прочая лабуда
По уровню развития тянет на простыню четверокурсника, которого на лекциях учат про ООП, но зачем это нужно, его ослабленный водкой организм не понимает, а поэтому отторгает полученную информацию в императивной форме.
из забавных утверждений оного "Любой веб-скрипт это "получить команду пользователя, достать данные из базы, положить в базу изменения, вывести результат пользователю", иногда одна-две-три стадии оказываются не нужны. Где здесь место для объектов-событий-сообщений?"
и прочая лабуда
По уровню развития тянет на простыню четверокурсника, которого на лекциях учат про ООП, но зачем это нужно, его ослабленный водкой организм не понимает, а поэтому отторгает полученную информацию в императивной форме.
И зачем нужно ООП?
ООП (в тв. падеже) надо думать. А когда с децтва ему не учили, то в зрелом возрасте так лень переходить... Т.е. я могу чужие скрипты с ООП переделывать, но свои писать - честно, ломает.
И зачем нужно ООП?чтобы задавать вопросы на собеседованиях, конечно же!
мне тут Spin сегодня рассказывал про реализацию то ли дека, то ли бимапа на множественном наследовании.
чуваки утверждали, что он дико оптимизирован по памяти.
Основное направление развития программных технологий сейчас, имхо, в повальную абстракцию.Вот о том и речь, нахуй излишнюю абстракцию ради абстракции.
видел я этого Горного на конференции как-то
Твой пост — шедевр, говорить тут не о чем.
Позволю себе один(!) вопрос: назови свой удачный веб (или не веб) проект, чуть более сложный чем страничка "я, моя чикса и другие жывотные".
Ведь согласись, что чтобы Горнала назвать "этим" надо что-то в жизни для начала сделать?
назови свой удачный веб (или не веб) проект, чуть более сложный чем страничка "я, моя чикса и другие жывотные".о. вот это чоткий разговор пошел. присоединяюсь к вопросу.
ах, понеслась, рефреширую по ф5 - ежеменутно
назови свой удачный веб (или не веб) проект, чуть более сложный чем страничка "я, моя чикса и другие жывотные".TeamWorks, OILWatch, DealLogistics, Hackney Trust, Performance Marketing Portal, Greenstreet, пара безымянных банковских продуктов - достаточно?
g DealLogisticsВозможно, вы имели в виду: Geologistics
Возможно, вы имели в виду: Geologisticsпервый раз слышу, но по содержанию наверное похоже
ну я к тому, что ничего осмысленного по твоим кейвордам не смог в гугле найти. 
На Google.com используется ООП.
это атавизм!
Только я не понял, о чем вы тут вообще говорите и что такое ООП!
ООПэ — Очередной Охуенный Повод для Экстремизма
То есть, на самом деле, я не понимаю, что такое веб-программирование в том смысле, который употребил многоуважаемый г-н Горный!
Конечно же, я имел ввиду, что я не понял, в каком именно из смыслов употребил слово "веб-программирование" многоуважаемый г-н Горный, вот!
Или что-то такое.
ну я к тому, что ничего осмысленного по твоим кейвордам не смог в гугле найти.практически все это закрытые системы
в смысле написания серверной части сайтов, рассчитанных на дофига запросов в секунду, наверное!
На Google.com используется ООП.хаха ) качество продуктов гугл падает!
а разгадка одна —
То есть, речь все же идет исключительно о той прослойке кода, что получает запросы от клиента и выдает ему ответы? Про... эээ... бизнес-логику не говорим? Причем тут тогда БД и смена хранилища?
ну для того, чтобы что-то отдать, надо же как-то применить бизнес-логику!
я не силен в терминологии и Евангелие по диагонали читал.
я не силен в терминологии и Евангелие по диагонали читал.
Я тоже. Но ведь бизнес-логика ваще любая может быть, совершенно не специфичная для web. Тогда, может быть, автор хотел сформулировать более общий тезис — ООП говно (без привязки к web-программированию)?
Ну, об этом спорят уже миллионы лет.
Ну, об этом спорят уже миллионы лет.
ООП говнону примерно так его доклад на РИТе и называется. =)
Но ведь это все хуйня.
В смысле, вот все эти разговоры: ООП говно, ФП говно, *П говно.
В смысле, вот все эти разговоры: ООП говно, ФП говно, *П говно.
хуйня, бесспорно. но тут модная технология и нежелание думать.
я думаю, у горнала наболело просто.
я думаю, у горнала наболело просто.
ну и флейм там в жж зачотненький. я прям прыгал от счастья, когда читал.
Ну ладно, раз вопрос решен, поеду прокачусь на велике!
давай. мы себе тут тоже решили стоянку для великов купить.
может и я данным девайсом обзаведусь по такому поводу.
может и я данным девайсом обзаведусь по такому поводу.
Post deleted by
пианист. ну че ты такой некультурный всегда.
пианист. ну че ты такой некультурный всегда.нафиг снёс.
почему не культурный? ну потому что приводят примеры которые даже посмотреть нельзя. Это раз.
И потом приводят примеры которые как ни напиши — всё равно будут потом железом если надо решать. смысл что-то обсуждать?
ну а я о чем. все все поняли и так, я думаю.
поставил тебе плюсик за культурный пост!
поставил тебе плюсик за культурный пост!
А кто такой этот горец Горный?
вот мои примеры: rzd.ru, onnect.raiffeisen.ru
токо я не понял про что речь
старый ржд - пхп 4, никакого ООП
новый - джава, куча ООП, даже база данных почти ООП
на коннекте - бизнес-логика ООП, а вывод на экран в струтсе через бины - фактически никакого ООП, все бины тупо плоские
токо я не понял про что речь
старый ржд - пхп 4, никакого ООП
новый - джава, куча ООП, даже база данных почти ООП
на коннекте - бизнес-логика ООП, а вывод на экран в струтсе через бины - фактически никакого ООП, все бины тупо плоские
отвечу тезисно. если какие-то тезисы не понятны - спрашивайте, распишу подробно.
1. то, что сейчас подразумевают под ООП - это лишь одна из реализаций использования концепций: полиморфизм, инкапсуляция и наследование. Надо рассказывать почему "одна из"? и почему при разработке важны эти концепции?
2. надо приводить примеры почему коллекции удобно делать с поддержкой инкапсуляции, полиморфизма и наследования? и надо ли показывать, что это проще делаеть даже на такой убогой реализации ООП как сейчас есть , чем это делать на процедурном программировании?
или здесь тоже есть место для спора?
3. то, что нынешняя реализация ООП убога, и не умеет описывать сложные вещи - а в частности не поддерживает свои базовые концепции: полиморфизм, инкапсуляцию и наследования - для чего-то большего, чем один объект - это надо показывать? или это понятно?
4. то, что преобразование одного вида данных в другой вид (особенно в простых случаях) - по сути плоско, и там обычно мало места для инкапсуляции, полиморфизма и наследования. это надо расписывать?
5. то, что концепции полиморфизм, инкапсуляция и наследования в первую очередь важны и нужны в многовариантном мире. это надо уточнять?
6. то, что текущие web-сайты по сути одноварианты, и фактически да, получается что там нафиг не нужны концепции полиморфизма, наследования и инкапсуляции. здесь есть место для спора?
7. то, что многовариантность обычно появляется при интеграции нескольких систем в единое целое, и здесь как раз появляется необходимость использования полиморфизма, инкапсуляции и наследования. вопросы?
8. и то, что автор из цитаты из первого поста фактически утверждает - "я пишу простые одновариантные web-сайты, и мне поэтому нет необходимости использовать полиморфизм, наследования и инкапсуляцию". я правильно передал основую мысль автора?
итог: да, если кто-то пишет простые одновариантные вещи, то действительно ему лучше не заморачиваться и не думать, что есть полиморфизм, инкапсуляция и наследования. Разве здесь есть о чем спорить?
1. то, что сейчас подразумевают под ООП - это лишь одна из реализаций использования концепций: полиморфизм, инкапсуляция и наследование. Надо рассказывать почему "одна из"? и почему при разработке важны эти концепции?
2. надо приводить примеры почему коллекции удобно делать с поддержкой инкапсуляции, полиморфизма и наследования? и надо ли показывать, что это проще делаеть даже на такой убогой реализации ООП как сейчас есть , чем это делать на процедурном программировании?
или здесь тоже есть место для спора?
3. то, что нынешняя реализация ООП убога, и не умеет описывать сложные вещи - а в частности не поддерживает свои базовые концепции: полиморфизм, инкапсуляцию и наследования - для чего-то большего, чем один объект - это надо показывать? или это понятно?
4. то, что преобразование одного вида данных в другой вид (особенно в простых случаях) - по сути плоско, и там обычно мало места для инкапсуляции, полиморфизма и наследования. это надо расписывать?
5. то, что концепции полиморфизм, инкапсуляция и наследования в первую очередь важны и нужны в многовариантном мире. это надо уточнять?
6. то, что текущие web-сайты по сути одноварианты, и фактически да, получается что там нафиг не нужны концепции полиморфизма, наследования и инкапсуляции. здесь есть место для спора?
7. то, что многовариантность обычно появляется при интеграции нескольких систем в единое целое, и здесь как раз появляется необходимость использования полиморфизма, инкапсуляции и наследования. вопросы?
8. и то, что автор из цитаты из первого поста фактически утверждает - "я пишу простые одновариантные web-сайты, и мне поэтому нет необходимости использовать полиморфизм, наследования и инкапсуляцию". я правильно передал основую мысль автора?
итог: да, если кто-то пишет простые одновариантные вещи, то действительно ему лучше не заморачиваться и не думать, что есть полиморфизм, инкапсуляция и наследования. Разве здесь есть о чем спорить?
А кто такой этот горец Горный?Александр Горный — в прошлом — техничейский руководитель крупнейшего почтового сервиса Mail.RU, бывший директор по разработке компании Рамблер, а ныне — продюсер проекта Почта.ру. (copypasta)
чем веб-программирование отличается от "просто" программирования ?
всмысле пусть есть система - у нее могут быть десктоп интерфейс юзера и вебный интерфейс юзера. все различие только во View. начиная с презентеров все одинаково.
или я заблуждаюсь ?
всмысле пусть есть система - у нее могут быть десктоп интерфейс юзера и вебный интерфейс юзера. все различие только во View. начиная с презентеров все одинаково.
или я заблуждаюсь ?
Веб-программирование это программирование интерфейса к БД, всю логику надо из этого интерфейса убирать и складывать в отдельное место.
По пункту 3 хотелось бы уточнить в чем убогость и самое главное существуют ли альтернативы или хотя бы виденье того к чему нужно стремиться?
1. Надо рассказывать почему "одна из"?с удовольствием почитаю по этим двум пунктам
3. то, что нынешняя реализация ООП убога, и не умеет описывать сложные вещи - а в частности не поддерживает свои базовые концепции: полиморфизм, инкапсуляцию и наследования - для чего-то большего, чем один объект - это надо показывать?
(по 1 - рассказать альтернативы, по 3 - привести простейший пример)(ну или послать куда-нить поконкретнее)
новый - джава, куча ООП, даже база данных почти ООПох, не гордился бы я им... не совсем стабильный он... и не совсем удобный...
назови свой удачный веб (или не веб) проект, чуть более сложный чем страничка "я, моя чикса и другие жывотные".
лол
это понты или ты правда не веришь в ИХ существование ? Но ведь это все хуйня.
В смысле, вот все эти разговоры: ООП говно, ФП говно, *П говно.
хз, хз... "*П говно" - мб и правда
Тогда начнем с определений:
Пара базовых определений в сжатом виде для порядка:
1. Объект - нечто небольшое замкнутое обладающее своим состоянием и поведением.
2. Система - набор взаимосвязанных между собой объектов. в простейших случаях объект может выступать как система.
3. Сложность - кол-во "вариантов разнообразия"
4. Модель - упрощенное описание(понимание) системы необходимое(и достаточное) для выполнения каких-то задач по взаимодействую с системой. Чем модель "внутренне" проще(содержит меньше кол-во правил описывающих ее) и чем модель сложнее "снаружи" (позволяет как можно больше вариантов описывать, управлять и т.д.) - тем модель лучше.
основные определения
важно понимать, что все эти характеристики качественные (т.е. можно сказать, что их где-то больше, где-то меньше а не бинарные (нельзя сказать, что где-то это точно есть, а где-то этого точно нет)
1. инкапсуляция - фактически это возможность построения моделей. Соответственно, чем лучше система позволяет строит модели, тем сильнее система поддерживает инкапсуляцию. или другими словами, чем больше мы можем абстрагироваться от мелких деталей системы, не теряя при этом понимание (управление) системой, тем лучше инкапсуляция в системе.
Примеры зарекомендовавших себя инкапсулированных систем: файловая система, БД и т.д.
2. полиморфизм - умение взаимодействовать с разными вещами(системами) одиннаковым образом (умение взаимодействовать однородным образом с разнородными вещами(системами.
3. наследование - это возможность описать, что вот это такое же как то, но вот с такими особенностями.
наследование может применяться к чему угодно, к реализации, к пониманию, к поведению и т.д.
ps
вернусь - закончу
Пара базовых определений в сжатом виде для порядка:
1. Объект - нечто небольшое замкнутое обладающее своим состоянием и поведением.
2. Система - набор взаимосвязанных между собой объектов. в простейших случаях объект может выступать как система.
3. Сложность - кол-во "вариантов разнообразия"
4. Модель - упрощенное описание(понимание) системы необходимое(и достаточное) для выполнения каких-то задач по взаимодействую с системой. Чем модель "внутренне" проще(содержит меньше кол-во правил описывающих ее) и чем модель сложнее "снаружи" (позволяет как можно больше вариантов описывать, управлять и т.д.) - тем модель лучше.
основные определения
важно понимать, что все эти характеристики качественные (т.е. можно сказать, что их где-то больше, где-то меньше а не бинарные (нельзя сказать, что где-то это точно есть, а где-то этого точно нет)
1. инкапсуляция - фактически это возможность построения моделей. Соответственно, чем лучше система позволяет строит модели, тем сильнее система поддерживает инкапсуляцию. или другими словами, чем больше мы можем абстрагироваться от мелких деталей системы, не теряя при этом понимание (управление) системой, тем лучше инкапсуляция в системе.
Примеры зарекомендовавших себя инкапсулированных систем: файловая система, БД и т.д.
2. полиморфизм - умение взаимодействовать с разными вещами(системами) одиннаковым образом (умение взаимодействовать однородным образом с разнородными вещами(системами.
3. наследование - это возможность описать, что вот это такое же как то, но вот с такими особенностями.
наследование может применяться к чему угодно, к реализации, к пониманию, к поведению и т.д.
ps
вернусь - закончу
вернусь - закончуобщая "реализация" ООП на трёх китах - она понятна и так, интересны альтернативы... с нетерпением жду возврашения
Александр Горный — в прошлом — техничейский руководитель крупнейшего почтового сервиса Mail.RU, бывший директор по разработке компании Рамблер, а ныне — продюсер проекта Почта.ру. (copypasta)Мнение конечного пользователя (а это в итоге самое главное):
почтового сервиса Mail.RU — 1. В начале мауйлу частенько тормозил. Потом видимо как-то пофиксили, я думаю железо тоже прикупили. 2.Потом началась бадяга со спамом. Яндекс вроде успешнее борится со спамом. В итоге на майлру спам заебал окончательно и я практически забросил ящик, хотя терпел я долго и надеялся... Замечу, что свой адрес я где попало не оставлял.
директор по разработке компании Рамблер — 1. В начале пользовался рамблером, потом он слил, и теперь не вижу причины заходить на этот сайт.
>техничейский руководитель
>бывший директор
скорее всего, он уже сам не писал код... а чисто внедрял концепции
. О правильности концепций можно было бы судить по успешности проектов. Но оба проекта слили.., поэтому вопрос о правильности его концепций остается открытым.Я согласен с Горным, но только заменить слово "Веб" на слово php
Про остальные языки ибо не знаю достаточно, для составления компетентного мнения.
Про остальные языки ибо не знаю достаточно, для составления компетентного мнения.
продолжаем
Теперь переходим к главному, почему нынешнее ООП убогое.
нынешнее ООП с одной стороны декларирует, что оно поддерживает все эти концепции полиморфизма, инкапсуляции и наследования., но в тоже время все эти концепции поддерживают только на уровне одного объекта, а не на уровне систем или моделей.
пример:
вот у меня за окном ездят машины - это готовая система. можно даже представить, что это есть некая программная реализация, написанная не мной, примерно со следующим фасадом:
дальше допустим я хочу с этими машинами как-то поработать(повзаимодействовать хотя бы добавить флаг - машина мне уже знакома, или еще нет.
здесь я хочу воспользовать концепцией наследования, скорее всего наследования модели: я хочу, чтобы было также как и было, но у машины добавился флаг - знакома она мне, или нет.
и вот тут начинает текущую реализацию ООП - клинить, т.к. единственный путь это сделать - это руками написать полный адаптер на всю имеющуюся систему (на все объекты, которые в ней встречаются)
основная проблема текущей реализации ООП - это то, что объектная оболочка жесткая (встроенная в саму реализацию)
возьмем ту же самую машину: по смыслу - машина на конвеере и машина на дороге - это один и тот же объект, но у машины на дороге - есть понятие дороги, к которой машина "привязана", а у машины на конвеере - такого понятия нет.
т.е. для того, чтобы полиморфизм, инкапсуляция и наследование можно было применять и для систем - объектная оболочка должна быть гибкой и создаваться на основе текущего окружения объекта.
машину "поставили" на дорогу - у нее появилось поле дорога, машина "попала" в мое поле зрения - и у нее появился флаг - занята она или нет.
причем понятно, что вот это появление полей(методов) должно лишь быть на уровне модели, а на уровне реализации должно быть что-то такое
те же проблемы и с полиморфизмом и инкапсуляцией:
нельзя уже на сформированной системе сказать, что вот такой кусочек системы должен поддерживать вот такую абстракцию - опять же это делается сейчас только через ручное написание полного адаптера ко всей системе.
Теперь переходим к главному, почему нынешнее ООП убогое.
нынешнее ООП с одной стороны декларирует, что оно поддерживает все эти концепции полиморфизма, инкапсуляции и наследования., но в тоже время все эти концепции поддерживают только на уровне одного объекта, а не на уровне систем или моделей.
пример:
вот у меня за окном ездят машины - это готовая система. можно даже представить, что это есть некая программная реализация, написанная не мной, примерно со следующим фасадом:
interface IRoad
{
ICollection<ICar> Cars{get;}
}
дальше допустим я хочу с этими машинами как-то поработать(повзаимодействовать хотя бы добавить флаг - машина мне уже знакома, или еще нет.
здесь я хочу воспользовать концепцией наследования, скорее всего наследования модели: я хочу, чтобы было также как и было, но у машины добавился флаг - знакома она мне, или нет.
и вот тут начинает текущую реализацию ООП - клинить, т.к. единственный путь это сделать - это руками написать полный адаптер на всю имеющуюся систему (на все объекты, которые в ней встречаются)
основная проблема текущей реализации ООП - это то, что объектная оболочка жесткая (встроенная в саму реализацию)
возьмем ту же самую машину: по смыслу - машина на конвеере и машина на дороге - это один и тот же объект, но у машины на дороге - есть понятие дороги, к которой машина "привязана", а у машины на конвеере - такого понятия нет.
т.е. для того, чтобы полиморфизм, инкапсуляция и наследование можно было применять и для систем - объектная оболочка должна быть гибкой и создаваться на основе текущего окружения объекта.
машину "поставили" на дорогу - у нее появилось поле дорога, машина "попала" в мое поле зрения - и у нее появился флаг - занята она или нет.
причем понятно, что вот это появление полей(методов) должно лишь быть на уровне модели, а на уровне реализации должно быть что-то такое
IRoad Road(this ICar car, [Context] God god)
{
return god.К_какой_дороге_принадлежит_машина(car);
}
те же проблемы и с полиморфизмом и инкапсуляцией:
нельзя уже на сформированной системе сказать, что вот такой кусочек системы должен поддерживать вот такую абстракцию - опять же это делается сейчас только через ручное написание полного адаптера ко всей системе.
Ээ... self?
Я согласен с Горным, но только заменить слово "Веб" на слово phpпрежде всего это говорит о том, что тебе важно качество исполнения, а не всякая поебень типа проекции реального сира в мир компутерный, виртуальный..
Про остальные языки ибо не знаю достаточно, для составления компетентного мнения.
Есть такая фигня — она как заноза — тяга к абстракции. Не умеют люди вовремя остановиться, абстрагируются сами не знают зачем и от чего.
Ээ... self?о чем речь?
прежде всего это говорит о том, что тебе важно качество исполнения, а не всякая поебень типа проекции реального сира в мир компутерный, виртуальный..у нормального прогера качество исполнения всегда на первом месте, а использование какого-либо концепций может нормально аргументировать. Но чтобы разговор был предметным надо поконкретнее охарактеризовать задачу, а автор сказал единственное слово "web".
Есть такая фигня — она как заноза — тяга к абстракции. Не умеют люди вовремя остановиться, абстрагируются сами не знают зачем и от чего.
у нормальных прогеров это проходит после первых 1-2 проектов
Первый (часто скрытый) параметр метода, определяющий объект-контекст. Или я твой пример не понял?
this = self, но еще нужен доступ к текущему контексту.
В начале пользовался рамблером, потом он слил, и теперь не вижу причины заходить на этот сайт.оо да. рамблер — это вообще богом забытый уголок интернета. =)
Self и есть текущий контекст. В чем различие-то? Может поговорим о конкретике совсем. В примере. Что у нас есть, что хотим получить и _как_ хотим это получить. А то я пока не понимаю.
Мы хотим, чтобы наш Car был сперва CarAtTheFactory, потом вдруг стал CarInTransit, потом - CarOnTheRoad, потом - CarInMyView, которые все - производные от Car, но множество методов и аттрибутов - разнообразное (причём, на дороге мы не будем менять машине шасси)
Давай с другой стороны. Вот тут что не так?
class Car:
def m(self):
print self.p
class CarAtX(Car):
p = 1
class CarAtY(Car):
p = 2
context1 = CarAtX
context2 = CarAtY
Car.m(context1)
Car.m(context2)
нам надо, чтобы объект можно было безболезненно преобразовывать от одного типа к другому с сохранением прелестей полиморфизма. пример, может, после обеда...
То есть, чтобы вместо Car.m было c.m, где с = Car ?
Self и есть текущий контекст. В чем различие-то? Может поговорим о конкретике совсем. В примере. Что у нас есть, что хотим получить и _как_ хотим это получить. А то я пока не понимаю.вот что-то такое мне приходит снаружи
interface IRoad
{
IEnumerable<ICar> Cars {get;}
}
вот что-то такое у меня есть
interface IMyView
{
Counter ViewCounter(this ICar car);
}
вот что-то такое я хочу задекларировать:
IRoad road;
IMyView myView;
var roadInMyView = road extends with myView;
чтобы можно было с этим вот так работать
foreach (var car in roadInMyView.Cars)
{
car.ViewCounter++;
}
Давай с другой стороны. Вот тут что не так?то, что ты заранее спроектировал машину так, что она может принимать некий контекст.
а необходимо, чтобы можно было наоборот - сначала спроектировать машину, а потом уже к ней привязывать разные контексты
myView просто добавляет к road некоторое количество полей и методов? Что происходит с конфликтом имен?
Я ничего не проектировал, кроме того, что использовал unbound method m. Это и не нравится?
myView просто добавляет к road некоторое количество полей и методов?фактически, да. хотим добавить какое-то кол-во полей, методов, реализованных интерфейсов и т.д.
только важно, что не только к самой road, но и в том числе к каким-то объектам, которые в этот road входят.
Что происходит с конфликтом имен?можем указывать какие будут имена в случаи конфликта
Я ничего не проектировал, кроме того, что использовал unbound method m. Это и не нравится?конечно, потому что в реально существующей системе такого метода скорее всего не будет.
только важно, что не только к самой road, но и в том числе к каким-то объектам, которые в этот road входят.Тогда пиши подробнее, что добавляет к роад, а что и к каким объектам в роад? Или ты хочешь просто всем машинам сразу поменять контекст роад, но при этом ни роад ни объекты в роад этого предусматривать не должны? А причем тут текущая реализация ООП?
Почему же? То, что метод может быть unbound никто не проектировал. Это просто какой-то метод. Про подмену контекста он ничего не знает.
Мы хотим, чтобы наш Car был сперва CarAtTheFactory, потом вдруг стал CarInTransit, потом - CarOnTheRoad, потом - CarInMyView, которые все - производные от Car, но множество методов и аттрибутов - разнообразное (причём, на дороге мы не будем менять машине шасси)Во. Это я больше всего люблю. Когда начинаются попытки привести аналогии ООП подхода с всем понятными вещами. Эти попытки меня всегда очень веселили
Но в практике я ни разу не встречал, чтобы надо было "сделать машинку фиолетовой, приделать крылья и полететь". Ибо каждая задача для нормального проектировщика\разработчика имеет (почти всегда) очевидно-прямолинейное решение. И приделывать крылья к машинке нафиг не надо - надо делать сразу самолётик.Всё это про web-программирование на php.
Собственно статья была именно про вебпрограмминг, а тут что-то скатилось всё опять на более глобальное выяснение "рулит ли ООП".
Тогда пиши подробнее, что добавляет к роад, а что и к каким объектам в роад?так вроде это как раз и написано, что IMyView к ICar добавляет ViewCounter
Или ты хочешь просто всем машинам сразу поменять контекст роад, но при этом ни роад ни объекты в роад этого предусматривать не должны?да
А причем тут текущая реализация ООП?при том, что она такую фичу не поддерживает, хотя могла бы
Если я правильно понял, значит берем готовую систему и вкрапляем дополнительный функционал который нам нужен?
Добавили мы значит дорогу в машину и потом по всей системе ввели иньекции которые бы на эту дорогу реагировали?
Добавили мы значит дорогу в машину и потом по всей системе ввели иньекции которые бы на эту дорогу реагировали?
Ибо каждая задача для нормального проектировщика\разработчика имеет (почти всегда) очевидно-прямолинейное решение.что-то мне всегда казалось, что чем человек тупее, тем больше у него очевидных прямолинейных решений.
я не прав?
Если я правильно понял, значит берем готовую систему и вкрапляем дополнительный функционал который нам нужен?в каком-то приближении, да хочется именно такое.
Добавили мы значит дорогу в машину и потом по всей системе ввели иньекции которые бы на эту дорогу реагировали?
>Но в практике я ни разу не встречал, чтобы надо было "сделать машинку фиолетовой, приделать крылья и полететь".
Если твоя система живет лет десять, то у машины могут появится не только крылья но и ноги.
Если твоя система живет лет десять, то у машины могут появится не только крылья но и ноги.
что-то мне всегда казалось, что чем человек тупее, тем больше у него очевидных прямолинейных решений.лооооол, а мегаумный каждый раз изъёбывается на чесание пяткой уха?
Кажися, такие вещи позволительны в динамических языках вроде Ruby и JavaScript. Берешь конкретный объект (не класс) и присобачиваешь ему новые методы и свойства.. Duck typing тут напрашивается просто.
что-то мне всегда казалось, что чем человек тупее, тем больше у него очевидных прямолинейных решений.Я же писал про то, что это про вебпрограмминг на php. За довольно долгий промежуток времени мне давненько не приходилось думать
я не прав?
А когда я ещё изучал всякие модные финты приходилось немало напрягаться для реализации.Я стал тупее ?
Но в практике я ни разу не встречал, чтобы надо было "сделать машинку фиолетовой, приделать крылья и полететь".а чем web - хуже/лучше реальной жизни?
Всё это про web-программирование на php.
то что текущий web много убогее, чем реальная жизнь - это не повод, чтобы на этот web молиться.
возьмем вот этот же форум, это web?
я имею право хотеть, например, навесить на каждого пользователя свои знания о нем, или нет?
если я все-таки право имею, то как мне это сделать? допустим даже у меня есть доступ к исходникам форума, но нет прав на их исправление.
т.е. я могу только от них пронаследоваться и сделать что-то свое.
Зачем спорить с пеониздом. Еще классиками было сказано: "Если человек держит в руках молоток, то все вокруг него - гвозди"
За довольно долгий промежуток времени мне давненько не приходилось думать А когда я ещё изучал всякие модные финты приходилось немало напрягаться для реализации.может быть. в web-е как минимум очень редко делаются редакторы.
Я стал тупее ?
а как раз редакторы на несколько порядков сложнее вьюверов
и в редакторах вся эта херотень по изменению типов обычно и нужна: берем объект из палитры (один тип помещаем его в рабочую среду (другой тип привязываем к нему всякие феньки (третий тип копируем результат в буфер обмена (четвертый тип) и т.д.
Кажися, такие вещи позволительны в динамических языках вроде Ruby и JavaScript. Берешь конкретный объект (не класс) и присобачиваешь ему новые методы и свойства.. Duck typing тут напрашивается просто.есть следующие проблемы:
1. мы реально меняем чужие объекты. если проводить аналогию с реальным миром, то мы подходим к машине и делаем зарубку - что мы эту машину уже видели. мне кажется, что "машине" это может не понравиться, как в реальном мире, так и в программном.
2. приходится все делать руками (отслеживание объектов, которые есть в текущем контексте, добавление/удаление методов из них и т.д. вместо того, чтобы это поручить языку(выполняемой среде)
кстати в xaml-е что-то такое появилось.
например, если мы контрол вставляем в dock-менеджер, то у контрола появляются свойства относящиеся к докингу и т.д.
например, если мы контрол вставляем в dock-менеджер, то у контрола появляются свойства относящиеся к докингу и т.д.
кстати в xaml-е что-то такое появилось.это и в WinForms было в дизайнере, но дизайнер просто генерил вызов метода с параметром
кстати какой-нибудь форумский движок, блогерный движок, движок графиков - это все web или нет?
и должны ли эти модули уметь отвязывать от хранилища, от способа задания тех же пользователей?
если должны, то как это должно оформляться?
и должны ли эти модули уметь отвязывать от хранилища, от способа задания тех же пользователей?
если должны, то как это должно оформляться?
допустим даже у меня есть доступ к исходникам форума, но нет прав на их исправление.Форум не был ориентирован на пользователей, которым захочется попрограммировать. А вообще, есть системы с плагинной архитектурой, и написаны на текущей реализации ООП
это и в WinForms было в дизайнере, но дизайнер просто генерил вызов метода с параметромв win forms-е это было жестко зашито, а здесь можно произвольные поля так делать
то что текущий web много убогее, чем реальная жизнь - это не повод, чтобы на этот web молиться.А кто-то молится ? Я и пишу что там всё просто, что ООП не нужно и что аналогии с реальным миром не уместны.
А кто-то молится ? Я и пишу что там всё просто, что ООП не нужно и что аналогии с реальным миром не уместны.ты молишься - когда утверждаешь следующее: я сейчас пишу простые web-овские проекты, поэтому в web-е всегда так есть, и так будет.
имхо, в web-е все так пока просто, потому что сейчас сложные проекты на web-е сделать действительно очень сложно (намного сложнее, чем в консоле или на desktop-е).
но это лишь же, благодаря тому, что веб до сих пор проходит эпоху становления., как только веб станет стандартом де факто, и в него полезут те же самые редакторы, интеграция, симуляторы, управление и т.д. - то и в вебе все станет очень сложно.
стандартом де факто, и в него полезут те же самые редакторы, интеграция, симуляторы, управление и т.д.зачем редактору веб?
что такое веб?
прога, которая лазит в сеть, это уже веб?
ты молишься - когда утверждаешь следующее: я сейчас пишу простые web-овские проекты, поэтому в web-е всегда так есть, и так будет.Посмеялся от души.
Шикарная логика, опирающаяся на несуществующие утверждения, что в прочем не умаляет её шикарности.
> зачем редактору веб?
для конечного пользователя, веб - дешевле и удобнее
> что такое веб?
1. размещение программы на "сервере в инете", а не на компьютере пользователя
2. работа программы у пользователя внутри браузера, с использованием html-я и javascript-а.
пока не понятно: flash и java-аплеты - это веб или не веб.
> прога, которая лазит в сеть, это уже веб?
скорее нет, чем да
для конечного пользователя, веб - дешевле и удобнее
> что такое веб?
1. размещение программы на "сервере в инете", а не на компьютере пользователя
2. работа программы у пользователя внутри браузера, с использованием html-я и javascript-а.
пока не понятно: flash и java-аплеты - это веб или не веб.
> прога, которая лазит в сеть, это уже веб?
скорее нет, чем да
фактически, да. хотим добавить какое-то кол-во полей, методов, реализованных интерфейсов и т.д.Динамическая типизация + метаклассы тебя не спасут?
только важно, что не только к самой road, но и в том числе к каким-то объектам, которые в этот road входят.
...удобнееэээ.. вообще-то считается, что на десктопе можно сделать более удобного клиента, и это действительно так. Возможно, многие со мной не согласятся, но все-таки веб-почтовые клиенты менее удобны чем десктопные, несмотря на все старания того же гугла.
Удобные в смысле развертывания и обновления — ну так надо совершенствовать инфраструктуру развертывания десктопных приложений, и это делается, правда неспешно.
Кросплатферменность — часто она нафиг не нужна.
эээ.. вообще-то считается, что на десктопе можно сделать более удобного клиента, и это действительно такс этим не спорю, я утверждаю - что если есть выбор между двумя приложениями: веб-овское и desktop-ное, обладающими одиннаковыми удобными функционалами, то в этом случае удобнее работать с вебовским приложением.
Удобные в смысле развертывания и обновления — ну так надо совершенствовать инфраструктуру развертывания десктопных приложений, и это делается, правда неспешно.куда делась самая затратная часть - обслуживание?
основной недостаток десктопных приложений - что их дороже обслуживать.
с этим еще нормально в корпоративном мире, т.к. там есть свой support, но что делать дома?
поддерживать работоспособный браузера проще, чем поддерживать работоспособность десятки приложений.
еще также остается проблема с сохраностью данных - опять же часто домашний пользователь не имеет возможности обеспечить надежное хранение данных у себя.
Тебе не кажется, что ты реально хочешь то, к чему _концепция_ ООП имеет слабое отношение? Что ты придумал некоторую достаточно хитрож*пую архитектуру и хочешь, чтобы она была реализована на уровне языка или даже зачем-то введена в концепцию ООП. Вопрос, чем твой пример достойнее этого, чем миллион других примеров, использующих ООП.
извини, что я посмел своими мыслями посягнуть на Священную Реализацию ООП.
если же серьезно, то концепция ООП утверждает следующее:
1. всё - есть объект
2. ООП с объектами должно уметь делать следующее: полиморфизм, инкапсуляцию и наследование.
я лишь только утверждаю, что для текущих реализаций ООП - это не выполняется:
т.к. если объект - это простой объект, то полиморфизм, инкапсуляция и наследование - для него поддерживается,
если же объект - это набор объектов, то полиморфизм, инкапсуляция и наследование - не поддерживается.
если же серьезно, то концепция ООП утверждает следующее:
1. всё - есть объект
2. ООП с объектами должно уметь делать следующее: полиморфизм, инкапсуляцию и наследование.
я лишь только утверждаю, что для текущих реализаций ООП - это не выполняется:
т.к. если объект - это простой объект, то полиморфизм, инкапсуляция и наследование - для него поддерживается,
если же объект - это набор объектов, то полиморфизм, инкапсуляция и наследование - не поддерживается.
есть следующие проблемы:не понимаю
1. мы реально меняем чужие объекты. если проводить аналогию с реальным миром, то мы подходим к машине и делаем зарубку - что мы эту машину уже видели. мне кажется, что "машине" это может не понравиться, как в реальном мире, так и в программном.
2. приходится все делать руками (отслеживание объектов, которые есть в текущем контексте, добавление/удаление методов из них и т.д. вместо того, чтобы это поручить языку(выполняемой среде)
машине мы зарубку не делаем (то что предлагает джаваскрипт в памяти у себя список виденных машин не сохраняем (то что предлагает ООП)
откуда же мы тогда при следующей встрече с этой машиной знаем что мы ее уже видели?
в памяти у себя список виденных машин не сохраняем (то что предлагает ООП)на уровне реализации - сохраняем у себя в памяти, смотри IMyView
откуда же мы тогда при следующей встрече с этой машиной знаем что мы ее уже видели?
но на уровне модели - как будто бы сохраняем на уровне машины
сложные проекты на web-е сделать действительно очень сложнопочему ? в чем сложность реализации по сравнению с десктоп ?
что такое сложный проект на вебе ?
по мне так отличие в основном тупо в UI - через что пользователь работает с приложением - через win-интерфейс или через бровсер. но UI это же очень небольшая часть (как правило)системы.
но на уровне модели - как будто бы сохраняем на уровне машиныне понимаю
где ооп утверждает что оно должно уметь "на уровне модели - как будто бы сохранять на уровне машины"?
почему ? в чем сложность реализации по сравнению с десктоп ?основная проблема: что html+javascript более убогий и тормозной, чем прямой вывод точек на экран
где ооп утверждает что оно должно уметь "на уровне модели - как будто бы сохранять на уровне машины"?ООП утверждает, что если я это захочу, то я смогу это сделать, пронаследовавшись от готового объекта(системы)
Что ты придумал некоторую достаточно хитрож*пую архитектуруЭто давно было придумано, только пока в статический типизированный мейнстим не попало.
http://en.wikipedia.org/wiki/Prototype-based_programming
на уровне реализации - сохраняем у себя в памяти, смотри IMyViewу нас был такой фреймворк (включая гц, ремоутинг, плагинная система) на си++
но на уровне модели - как будто бы сохраняем на уровне машины
называлось это subinterface.
все труды (полтора года на них убили) спущены в унитаз (ибо слишком большой футпринт и плохой перформанс)
теперь все пишут на голых сях++ и вспоминают прошедшее как плохой сон
Все, окончательно заглох, как машина в примерах. Это тут причем? Потребности даркгрея вполне удовлетворит мощное динамическое типизирование, по-моему, нет?
Потребности даркгрея вполне удовлетворит мощное динамическое типизирование, по-моему, нет?не хватит, хочется большего
у нас был такой фреймворк (включая гц, ремоутинг, плагинная система) на си++так понятно, что свою среду разработки очень дорого поддерживать.
называлось это subinterface.
все труды (полтора года на них убили) спущены в унитаз (ибо слишком большой футпринт и плохой перформанс)
теперь все пишут на голых сях++ и вспоминают прошедшее как плохой сон
т.к. если объект - это простой объект, то полиморфизм, инкапсуляция и наследование - для него поддерживается,класс как раз характеризует набор объектов. Во многих языках класс - это простой объект. Еще раз грю, неужели тебя не устроит динамическое типизирование + метаклассы? На этой связке можно провернуть, по-моему, все что ты захочешь в описанном случае.
если же объект - это набор объектов, то полиморфизм, инкапсуляция и наследование - не поддерживается.
Еще раз грю, неужели тебя не устроит динамическое типизирование + метаклассы? На этой связке можно провернуть, по-моему, все что ты захочешь в описанном случае.при желании можно это и на статик ооп прикрутить, можно наверное даже на голом Cи сделать
но только ведь это все будет ручное, а не на уровне программной среды.
ps
это почти как прикручивать сборщик мусора к среде, который этот сборщик мусора нативно не поддерживает.
Ну, что такое уровень программной среды? Модуль стандартной билиотеки - это какой уровень? Я тебе предложил с небольшими затратами как раз написать подобный модуль. И пользоваться.
это почти как прикручивать сборщик мусора к среде, который этот сборщик мусора нативно не поддерживает.
Не в тему, кстати. Тут как раз все возможности "предусмотрены", просто конкретно твоих фич нет. Именно потому, что класс - вполне себе объект, издевайся как хочешь
динамическое типизирование + метаклассыМетаклассы это которые в питоне? Я нашел только примеры когда их можно использовать при описывание класса.
Ну, что такое уровень программной среды? Модуль стандартной билиотеки - это какой уровень? Я тебе предложил с небольшими затратами как раз написать подобный модуль. И пользоватьсячерез аля "замочная скважина" - по идее - да, сделать можно.
в жабаскрипте тебе никто не мешает добавить функцию/член именно к классу, а не к экземпляру, а где там будет инфа хранится - дело имхо десятое..
в питоне думаю тоже все это можно - конкретно в эту сторону не смотрел
в питоне думаю тоже все это можно - конкретно в эту сторону не смотрел
Во-первых, еще можно делать фабрики по созданию классов, использовать декораторы + динамическое добавление свойств. Это про "рантайм".
Во-вторых, да, только на этапе описания класса, потому что это "классы для классов". С помощью метаклассов я предлагал делать что-нибудь вроде наследования, которого даркгрею не хватало на уровне классов, как обычных объектов.
ЗЫ А вообще, я думаю, достаточно взять язык с более мощным, чем у питона метапрограммированием и "ваще-ваще радоваццо".
Во-вторых, да, только на этапе описания класса, потому что это "классы для классов". С помощью метаклассов я предлагал делать что-нибудь вроде наследования, которого даркгрею не хватало на уровне классов, как обычных объектов.
ЗЫ А вообще, я думаю, достаточно взять язык с более мощным, чем у питона метапрограммированием и "ваще-ваще радоваццо".
но мне все это хочется при статической типизации, причем особых проблем при этом не должно быть
XML, я кстати, люблю примерно так же, как объекты.Дичайше показательная фраза. Объясняет про чувака всё.
С одной стороны, XML идеален для определённого набора довольно часто встречающихся задач — сохранить немножко структурированных данных, например. Ему тупо нет альтернативы, это идеальный инструмент. Как его можно не любить, если он идеален?
С другой стороны, есть специальные увлекающиеся люди, которые обнаруживают, что к XML можно приделывать схемы, писать в схемах разнообразные констрейнты, использовать XSLT и так далее, и тому подобное, причём обнаружив это они не только начинают рожать чудовищ, но и используют XML для задач, для решения которых он не предназначен — для реализации базы данных, например.
Аффтар упорно смотрит на эту вторую сторону и делает из наблюдений вывод о том, что XML — плохой формат. И предаётся сладострастным обличениям, тешащим чувство собственной важности. Ну и дурак, что тут можно сказать.
То же самое, естественно, относится и к ООП. Понятно, что если хочется работать с комплексными числами, например, то ничего лучше инкапсуляции их в классе придумать нельзя в принципе. Это плохо? От этого нужно отказаться, потому что какие-то мудаки абьюзят ООП в других местах? Где логика?
Ему тупо нет альтернативы, это идеальный инструмент.Да ну, гон. Альтернатив куча. Вопрос только в стандартизации.
Какие, например? Я правда не знаю.
Не, понятно, что можно за пять минут нафигачить какой-нибудь приблизительный формат, хоть S-expressions те же, если добавить к ним соглашения о том, как хранятся key-value pairs, там, стринги как эмбеддятся и эскейпятся, всё такое. Только получится ровно тот же XML, но без отлаженных библиотек под все мыслимые платформы и языки, с нечёткой спецификацией, потенциальными дырами в спецификации и прочими радостями.
CSV и бинарные дампы я, понятно, не рассматриваю, это не о том вообще.
Не, понятно, что можно за пять минут нафигачить какой-нибудь приблизительный формат, хоть S-expressions те же, если добавить к ним соглашения о том, как хранятся key-value pairs, там, стринги как эмбеддятся и эскейпятся, всё такое. Только получится ровно тот же XML, но без отлаженных библиотек под все мыслимые платформы и языки, с нечёткой спецификацией, потенциальными дырами в спецификации и прочими радостями.
CSV и бинарные дампы я, понятно, не рассматриваю, это не о том вообще.
Где у XML четкая спецификация?
XML это идея. "Можно делать так". Никакого особенного стандарта там нет.
В нем вся прелесть — в XSLT и тп, которые позволяют более-менее универсально с ним работать и приводить в нужный вид.
XML это идея. "Можно делать так". Никакого особенного стандарта там нет.
В нем вся прелесть — в XSLT и тп, которые позволяют более-менее универсально с ним работать и приводить в нужный вид.
дальше допустим я хочу с этими машинами как-то поработать(повзаимодействовать хотя бы добавить флаг - машина мне уже знакома, или еще нет.А почему не вариант добавить класс связей машины со "знакомостью" и машины с дорогой?
здесь я хочу воспользовать концепцией наследования, скорее всего наследования модели: я хочу, чтобы было также как и было, но у машины добавился флаг - знакома она мне, или нет.
Ну тот же JSON, который набил уже по-моему всем оскомину. Под конкретные задачи, как ты мб замечал, например, конфиги, вообще уже миллиард вариантов, по-моему, как только не извращаются. Имхо еще раз, XML - первый обобщенный, стандартизированный, получивший распространение. Всего-навсего. Никакого "идеала".
Где у XML четкая спецификация?Тебе показали.
Нифига это не "идея". Это вполне формально определённый низкоуровневый формат древовидных данных. Там чётко прописано, как записываются числа, символы, стринги, комментарии, всякие CDATA, как оно работает с уникодом етс. А в рамках этого формата ты можешь делать что угодно и как угодно, естественно. То есть если ты хочешь изобразить хэштейбл, ты можешь зафигачить отдельно два массива ключей и значений, или массив элементов ключ+значение, произвольно организуя вложенность, выбирая между хранением в атрибутах, в теле элемента или даже в имени элемента, етс, миллионом способов короче. Но после того, как ты выбрал способ, ты можешь взять произвольную библиотеку для работы с XML, мгновенно её использовать и быть уверенным, что даже когда в твоей хэштейбле в ключах встречаются кавычки, угловые скобки и прочая, и прочая, они все корректно заэскейпятся, а на другой стороне любая другая библиотека сумеет прочитать всё обратно. Ну, то есть, следует воспринимать эту часть стандарта как что-то низкоуровневое, как TCP/IP, например.
Другое дело, что там выше есть и другие штуки, как массивы хранить, там, неймскпейсы всякие, етс, и вот они действительно в виде рекомендаций существуют, если я не ошибаюсь.
А в XML уже есть стандартное представление бинарных данных?
отлаженных библиотек под все мыслимые платформыВон тут пишут, что даже поточный валидатор самому приходится делать:
http://blog.josh420.com/archives/2007/10/validate-xml-stream...
Не исключаю, что автор - мудак, так как я прочитал подиагонале.
А почему не вариант добавить класс связей машины со "знакомостью" и машины с дорогой?Некуда засунуть наследование. А ООП без наследования - не ООП ни разу.
Тебе показали.
Не заметил.
Напомню:
С одной стороны, XML идеален для определённого набора довольно часто встречающихся задач — сохранить немножко структурированных данных, например. Ему тупо нет альтернативы, это идеальный инструмент. Как его можно не любить, если он идеален?
С другой стороны, есть специальные увлекающиеся люди, которые обнаруживают, что к XML можно приделывать схемы, писать в схемах разнообразные констрейнты, использовать XSLT и так далее, и тому подобное, причём обнаружив это они не только начинают рожать чудовищ, но и используют XML для задач, для решения которых он не предназначен — для реализации базы данных, например.
Так вот по ссылке я вижу список working groups. Из них только одна собственно об xml заботится, остальные о подмножествах и расширениях. То есть они "специальные увлекающиеся люди" в твоей терминологии.
Не можем мы "сохранить немножко структурированных данных", это не кроссплатформенно. То есть чем сохраняли, тем и читаем. И то что выбрали "формат xml" — это наши причуды.
xml-based форматы есть: xsl-fo, xslt, xml-rpc.
Это я к тому что в xml единственный смысл — это то, что к xml можно что-то приделывать. А то, для чего он по-твоему "идеален" лучше делать без xml вовсе.
А в XML уже есть стандартное представление бинарных данных?base64 - разве не стандартное?
ну тут как обычно, стандартов так много, что есть из чего выбрать
Вон тут пишут, что даже поточный валидатор самому приходится делать:Там просто привели пример, как использовать валидатор, используя вместо устаревшего класса новый (для .NET 2.0).
http://blog.josh420.com/archives/2007/10/validate-xml-stream...
Не исключаю, что автор - мудак, так как я прочитал подиагонале.
Не исключаю, что автор - мудак, так как я прочитал подиагонале.скорее, ты очень сильно читал по диагонали.
потому что в статье лишь описывается о том, что один класс в стандартной либе объявлен устаревшим, и теперь лучше использовать другой класс из стандартной либы.
> ты очень сильно читал по диагонали
наверное
там просто так много букв, что мне показалось, что слишком много руками сделано
наверное
там просто так много букв, что мне показалось, что слишком много руками сделано
ну тут как обычно, стандартов так много, что есть из чего выбратьчто ты еще стандартное кроме base64 знаешь?
uuencode
heump
уenc
конструкторы массивов в C
heump
уenc
конструкторы массивов в C
Во-первых, вот: http://www.w3.org/TR/xml11/
Спецификация.
Во-вторых, я не очень понимаю, в чём, собственно, проблема. Тебя не очень удивляет то, что в стандартах вокруг TCP/IP ничего не написано про то, что, собственно, предполагается передавать при помощи этих протоколов? И в стандарте RS-232 тоже ничего про это не написано, что, он от этого менее стандартом становится? Ещё раз повторяю, XML — это не "идея", это формальный стандарт. А засовывать туда ты действительно можешь что угодно как угодно. Конечно, когда ты решишь его использовать в реальной задаче, тебе понадобятся другие спецификации (придуманные тобой лично, например описывающие, как именно ты собираешься туда засовывать то, что ты туда собираешься засовывать. И что?
"А то, для чего он по-твоему "идеален" лучше делать без xml вовсе" — ну-ка, ну-ка, и как?
2: окей, да, их действительно много разных, не знал. Ну ладно, пусть XML не "идеален" в том смысле, что у других стандартов могут быть какие-то преимущества, не знаю, меньшее количество символов для записи некоторых штук, более высокая скорость обработки в определённых условиях и так далее. Ну и что? Это повод сильно нелюбить XML?
2Gadfather: не, стандарта для бинарных данных нету. Но можешь пихать base64 куда угодно! Что до поточной валидации, во-первых, схемы как таковые уже относятся к надстройкам, а во-вторых, дико странное желание на самом деле, если учесть, что в схеме можно юзать сколь угодно сложные xpath выражения. Я же могу потребовать, чтобы значение атрибута где-нибудь там обязательно встречалось в виде имени элемента в детях у рута, и вперёд, пока всё не прочитаешь, не будешь знать, выполняется ли это требование.
Спецификация.
Во-вторых, я не очень понимаю, в чём, собственно, проблема. Тебя не очень удивляет то, что в стандартах вокруг TCP/IP ничего не написано про то, что, собственно, предполагается передавать при помощи этих протоколов? И в стандарте RS-232 тоже ничего про это не написано, что, он от этого менее стандартом становится? Ещё раз повторяю, XML — это не "идея", это формальный стандарт. А засовывать туда ты действительно можешь что угодно как угодно. Конечно, когда ты решишь его использовать в реальной задаче, тебе понадобятся другие спецификации (придуманные тобой лично, например описывающие, как именно ты собираешься туда засовывать то, что ты туда собираешься засовывать. И что?
"А то, для чего он по-твоему "идеален" лучше делать без xml вовсе" — ну-ка, ну-ка, и как?
2: окей, да, их действительно много разных, не знал. Ну ладно, пусть XML не "идеален" в том смысле, что у других стандартов могут быть какие-то преимущества, не знаю, меньшее количество символов для записи некоторых штук, более высокая скорость обработки в определённых условиях и так далее. Ну и что? Это повод сильно нелюбить XML?
2Gadfather: не, стандарта для бинарных данных нету. Но можешь пихать base64 куда угодно! Что до поточной валидации, во-первых, схемы как таковые уже относятся к надстройкам, а во-вторых, дико странное желание на самом деле, если учесть, что в схеме можно юзать сколь угодно сложные xpath выражения. Я же могу потребовать, чтобы значение атрибута где-нибудь там обязательно встречалось в виде имени элемента в детях у рута, и вперёд, пока всё не прочитаешь, не будешь знать, выполняется ли это требование.
base64 - разве не стандартное?Не в таком смысле стандартное. То есть строки, числа и имена символов у тебя есть в стандарте в качестве базовых сущностей, а закодированное в base64 что-нибудь тебе придётся реально представлять в виде одной из этих базовых сущностей.
Тебя не очень удивляет то, что в стандартах вокруг TCP/IP ничего не написано про то, что, собственно, предполагается передавать при помощи этих протоколов?Гонишь. С помощью TCP передают поток октетов - вполне однозначная сущность.
А вот что такое "древовидные данные" - хз.
NO U.
Стандарт XML вполне однозначно описывает, что в нём можно хранить. А процедура маппинга твоих личных данных в XML-представление ничем качественно не отличается от процедуры маппинга твоих личных данных в поток байтов.
Стандарт XML вполне однозначно описывает, что в нём можно хранить. А процедура маппинга твоих личных данных в XML-представление ничем качественно не отличается от процедуры маппинга твоих личных данных в поток байтов.
> То есть строки, числа и имена символов у тебя есть в стандарте в качестве базовых сущностей,
Не всякие строки, а только в той кодировке, что в заголовке документа указана. И с точностью до пробельных символов.
Не всякие строки, а только в той кодировке, что в заголовке документа указана. И с точностью до пробельных символов.
А процедура маппинга твоих личных данных в XML-представление ничем качественно не отличается от процедуры маппинга твоих личных данных в поток байтов.Заметьте, не я это сказал.
Ну и что? Это повод сильно нелюбить XMLМногие его не любят именно потому, что им заставляют пользоваться несмотря на разные доводы в определенных конкретных случаях. Только и всего. А так я не вижу, за что его не любить и не вижу, за что его любить. Есть и есть. И х* бы с ним
Что смешного-то?
Да, стандарт позволяет тебе использовать XML для того, чтобы загнать прям в корень произвольные данные в base64, например.
Но вообще, если у тебя древовидные данные, причём среди них в основном встречаются числа и строки, то ты можешь замечательно использовать предоставляемые возможности и запихивать их соответственно. Это удобно. Но стандарт тебя этого делать не заставляет, потому что, как ты совершенно верно заметил, в нём нету определения _твоих_ древовидных данных. Точно так же как в протоколах TCP/IP нет определения _твоего_ потока байтов. Поэтому ты вполне можешь превратить _свой_ поток байтов опять-таки в base64 и получившуюся строчку записать в сетевое устройство, в виде _его_ потока байтов. Понимаешь?
Да, стандарт позволяет тебе использовать XML для того, чтобы загнать прям в корень произвольные данные в base64, например.
Но вообще, если у тебя древовидные данные, причём среди них в основном встречаются числа и строки, то ты можешь замечательно использовать предоставляемые возможности и запихивать их соответственно. Это удобно. Но стандарт тебя этого делать не заставляет, потому что, как ты совершенно верно заметил, в нём нету определения _твоих_ древовидных данных. Точно так же как в протоколах TCP/IP нет определения _твоего_ потока байтов. Поэтому ты вполне можешь превратить _свой_ поток байтов опять-таки в base64 и получившуюся строчку записать в сетевое устройство, в виде _его_ потока байтов. Понимаешь?
ну для древовидных данных данных придуманы S-выражения
стандарты опять же есть для пар (ключ, значения) и для эскейпа строк
в XML же много ещё наворотов, из-за чего возникает неоднозначность преобразования до такой степени, что действительно, качественного отличия с кодированием сразу в поток символов нет
стандарты опять же есть для пар (ключ, значения) и для эскейпа строк
в XML же много ещё наворотов, из-за чего возникает неоднозначность преобразования до такой степени, что действительно, качественного отличия с кодированием сразу в поток символов нет
вот что такое древовидные данные?
поток октетов - это вот что
это либо пустой поток
либо октет, а за ним - поток октетов
октет - это строка из 8 бит
а древовидные данные - можно определять по разному
если есть множество атомов, то можно определять то, что называется алгебраическими структурами, то есть взять замыкание относительно операций декартового произведения, (конечной) итерации и, может быть, перехода к множеству (вычислимых) функций
но если так делать - лисп получится
поток октетов - это вот что
это либо пустой поток
либо октет, а за ним - поток октетов
октет - это строка из 8 бит
а древовидные данные - можно определять по разному
если есть множество атомов, то можно определять то, что называется алгебраическими структурами, то есть взять замыкание относительно операций декартового произведения, (конечной) итерации и, может быть, перехода к множеству (вычислимых) функций
но если так делать - лисп получится
ну для древовидных данных данных придуманы S-выраженияЯзык декларации структуры этих s-выражений стандартизирована?
Запросы поверх этих S-выражений стандартизированы?
кстати, где можно посмотреть на сам стандарт S-выражений?
Не в таком смысле стандартное. То есть строки, числа и имена символов у тебя есть в стандарте в качестве базовых сущностей, а закодированное в base64 что-нибудь тебе придётся реально представлять в виде одной из этих базовых сущностей.Что значит "не в таком смысле стандартное"?
открываем стандарт XML Schema Part 2: Datatypes (даже еще в первой редакции) и читаем раздел "встроенные типы":
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in...
3.2 Primitive datatypes
3.2.1 string
3.2.2 boolean
3.2.3 decimal
3.2.4 float
3.2.5 double
3.2.6 duration
3.2.7 dateTime
3.2.8 time
3.2.9 date
3.2.10 gYearMonth
3.2.11 gYear
3.2.12 gMonthDay
3.2.13 gDay
3.2.14 gMonth
3.2.15 hexBinary
3.2.16 base64Binary
3.2.17 anyURI
3.2.18 QName
3.2.19 NOTATION
3.2.16 base64Binary
[Definition:] base64Binary represents Base64-encoded arbitrary binary data. The ·value space· of base64Binary is the set of finite-length sequences of binary octets. For base64Binary data the entire binary stream is encoded using the Base64 Content-Transfer-Encoding defined in Section 6.8 of [RFC 2045].
То есть если для реализации чего-то не используется наследование, но используются полиморфизм и/или инкапсуляция, это уже не ООП?
Кроме того, здесь может пригодиться наследование при создание класса связи.
Кроме того, здесь может пригодиться наследование при создание класса связи.
А почему не вариант добавить класс связей машины со "знакомостью" и машины с дорогой?можно, но не удобно.
в жизни же, когда строятся модели так же не делается...
Не понял, в каком смысле "не делается".
Не понял, в каком смысле "не делается".в том смысле, что если бы мы строили модель мысленно, а не в коде, то скорее бы эти признаки привешивали бы к модели машина, а не как отдельные сущности.
хотя если бы вопрос шел о хранение этих признаков, то да - их скорее бы всего записывали бы в отдельный "блокнотик".
т.е. в мысленных моделях скорее характерны фразы:
берем машину, смотрим на какой дороге она находится, проверяем знакомая машина или нет.
соответственно хочется именно вот эту мысленную фразу в коде и видеть, а не:
берем машину, далее берем центр связей отвечающий за дороги, в нем смотрим на какой дороге машина находится, далее берем центр связей отвечающий за - известна машина нам или нет, проверяем через него, что машина нам известна и т.д.
ps
если более формально и в терминах ФЯ, то хочеться иметь возможность быстрого и удобного замыкания одной системы на другую.
по-моему прекрасный вариант - завести машине координаты, завести объект географии, который по координатам возвращает объект на карте
о! тема!
надо к мышке прицепить географические координаты, и возвращать их, там, столько-то градусов северной широты, столько градусов восточной долготы.
надо к мышке прицепить географические координаты, и возвращать их, там, столько-то градусов северной широты, столько градусов восточной долготы.
по-моему прекрасный вариант - завести машине координатычто делать если у исходной машины таких полей нет?
А почему не вариант добавить класс связей машины со "знакомостью" и машины с дорогой?Потому что это не решает задач интеграции, например, вот такого модуля:
interface IRoad
{
ICar[] Cars {get;}
}
interface ICar
{
IWheel[] Wheels {get;}
}
interface IWheel
{
double Diametr {get;}
}
с вот таким
interface IStorehouse
{
IStoreTicket Store(ICar car);
}
interface ICar
{
int WheelCount {get;}
}
Ты не понял, по-моему.
Твоё определение потока октетов, точно так же, как и определение (древовидной) структуры XML документа, внутреннее. Оно описывает не твои данные, а то, что ты должен скормить соответствующему преобразователю, и что у него после этого будет внутри, на логическом уровне.
Ты, видимо, думаешь так: если у меня есть поток октетов, то я могу посмотреть на внутреннее определение потока октетов протокола, увидеть, что мой поток октетов действительно является потоком октетов с точки зрения протокола, и отдать его непосредственно, без дополнительных преобразований вроде перекодирования в base64, дописывания длины в байтах, контрольной суммы и прочего. Точно так же, если у тебя есть XML-документ в каком-то своём представлении, ты можешь посмотреть на определение well-formed XML, увидеть, что твои данные под него подпадают, и передать их непосредственно.
Дальше ты, кажется, предполагаешь, что "вероятность" того, что у тебя случайно окажутся данные в виде потока октетов, выше, чем если они случайно окажутся в формате XML (понятно, имеется в виду логическое представление, то есть как-то именованные и вложенные друг в друга элементы с атрибутами и прочим, не результирующее текстовое представление). Поэтому если ты имеешь дело с протоколом, принимающим поток октетов, то "чаще" будешь обнаруживать, что тебе не нужно делать никаких преобразований, что структура твоих данных уже удовлетворяет его формату.
Это предположение содержит весьма разнообразные ошибки. Укажу одну, наиболее фатальную: между нами говоря, любой поток октетов энкодится в XML более или менее однозначно:
<root><></root>
(добавить доктайпы и переименовать рут по вкусу, спасибо Даркгрею, кстати, за ссылку на формат, в котором сказано, что бейз64 таки является стандартизованным типом!)
То есть всё, вообще всё без исключения, что ты можешь запихнуть в TCP без раздумий и перекодировок, ты можешь запихнуть и в XML тоже однозначно, 1:1 (хоть и с тривиальной перекодировкой). При этом есть и какие-то другие случаи, которые гарантированно не пихаются в поток октетов без перекодировки (потому что всё, что пихается, мы только что рассмотрели но для которых существует однозначное представление в XML. Например, если ты хочешь передать один инт.
На возможное возражение, что "стандартный способ передачи ХХХ" является рекомендацией, а не правилом, я уже в принципе ответил: ты и поток октетов не обязан передавать через поток октетов в сыром виде, это чисто рекомендация такая. Более того, если мне не изменяет память, в случае HTTP over TCP например она нарушается, потому что там ещё длина пишется, хотя по идее нижележащий поток сам за ней следит.
Так вот, к чему это я: ты на самом деле хочешь невозможного. Ты хочешь, чтобы XML предоставляло _внешний_ и _ненарушаемый_ стандарт для передачи чего-нибудь сверх потока октетов, для древовидных данных, например. Это невозможно: и поток октетов такого стандарта для передачи потока октетов не предоставляет, на самом деле. А если ты согласишься убрать условие ненарушаемости, то всё нормально, подавляющее большинство твоих древовидных данных (интуитивно определённых) мапятся в "древовидные данные" стандарта XML более или менее однозначно.
Твоё определение потока октетов, точно так же, как и определение (древовидной) структуры XML документа, внутреннее. Оно описывает не твои данные, а то, что ты должен скормить соответствующему преобразователю, и что у него после этого будет внутри, на логическом уровне.
Ты, видимо, думаешь так: если у меня есть поток октетов, то я могу посмотреть на внутреннее определение потока октетов протокола, увидеть, что мой поток октетов действительно является потоком октетов с точки зрения протокола, и отдать его непосредственно, без дополнительных преобразований вроде перекодирования в base64, дописывания длины в байтах, контрольной суммы и прочего. Точно так же, если у тебя есть XML-документ в каком-то своём представлении, ты можешь посмотреть на определение well-formed XML, увидеть, что твои данные под него подпадают, и передать их непосредственно.
Дальше ты, кажется, предполагаешь, что "вероятность" того, что у тебя случайно окажутся данные в виде потока октетов, выше, чем если они случайно окажутся в формате XML (понятно, имеется в виду логическое представление, то есть как-то именованные и вложенные друг в друга элементы с атрибутами и прочим, не результирующее текстовое представление). Поэтому если ты имеешь дело с протоколом, принимающим поток октетов, то "чаще" будешь обнаруживать, что тебе не нужно делать никаких преобразований, что структура твоих данных уже удовлетворяет его формату.
Это предположение содержит весьма разнообразные ошибки. Укажу одну, наиболее фатальную: между нами говоря, любой поток октетов энкодится в XML более или менее однозначно:
<root><></root>
(добавить доктайпы и переименовать рут по вкусу, спасибо Даркгрею, кстати, за ссылку на формат, в котором сказано, что бейз64 таки является стандартизованным типом!)
То есть всё, вообще всё без исключения, что ты можешь запихнуть в TCP без раздумий и перекодировок, ты можешь запихнуть и в XML тоже однозначно, 1:1 (хоть и с тривиальной перекодировкой). При этом есть и какие-то другие случаи, которые гарантированно не пихаются в поток октетов без перекодировки (потому что всё, что пихается, мы только что рассмотрели но для которых существует однозначное представление в XML. Например, если ты хочешь передать один инт.
На возможное возражение, что "стандартный способ передачи ХХХ" является рекомендацией, а не правилом, я уже в принципе ответил: ты и поток октетов не обязан передавать через поток октетов в сыром виде, это чисто рекомендация такая. Более того, если мне не изменяет память, в случае HTTP over TCP например она нарушается, потому что там ещё длина пишется, хотя по идее нижележащий поток сам за ней следит.
Так вот, к чему это я: ты на самом деле хочешь невозможного. Ты хочешь, чтобы XML предоставляло _внешний_ и _ненарушаемый_ стандарт для передачи чего-нибудь сверх потока октетов, для древовидных данных, например. Это невозможно: и поток октетов такого стандарта для передачи потока октетов не предоставляет, на самом деле. А если ты согласишься убрать условие ненарушаемости, то всё нормально, подавляющее большинство твоих древовидных данных (интуитивно определённых) мапятся в "древовидные данные" стандарта XML более или менее однозначно.
А json чем плох?
Так вот, к чему это я: ты на самом деле хочешь невозможного. Ты хочешь, чтобы XML предоставляло _внешний_ и _ненарушаемый_ стандарт для передачи чего-нибудь сверх потока октетов, для древовидных данных, например.Почему невозможного? JSON существует, простые "древовидные данные "в него легко можно запихивать.
Я вот запихиваю в HTML-страничке данные в json, на сервере читаю python'ом. Не сочиняя никаких парсеров.
А json чем плох?вопросы все те же самые
Язык декларации структуры json-пакета стандартизирован?
Запросы поверх этих json-пакета стандартизированы?
Где можно посмотреть на стандарт json?
Кодировка json-пакета стандартизуется?
Какие примитивные типы данных json стандартизирует?
Язык декларации структуры этих s-выражений стандартизирована?Всё, кроме первого, можно посмотреть в R6RS.
Запросы поверх этих S-выражений стандартизированы?
кстати, где можно посмотреть на сам стандарт S-выражений?
Декларация структуры - вещь, кажется, в теории полезная, но очень часто не нужная. Вот если бы кто-то реально умел ускорять преобразования XML, если известно, что исходный документ соответствует имеющейся схеме или что-то вроде того...
но для которых существует однозначное представление в XML. Например, если ты хочешь передать один инт.Если надо передать один инт, большинство вменяемых людей обойдётся без XML.
А если структуры посложнее - ты как раз объясняешь, почему представление в XML не сильно отличается от представления в виде потока октетов. В любом случае нужно придумывать спецификацию представления данных.
напиши по-русски
вопросы все те же самые
http://www.json.org/
какие бы они ни были, хранение древовидных данных через json работает, а через xml — нет, надо свой парсер писать.
В следующих браузерах обещались toJson & fromJson ввести.
есть два больших модуля, которые работают примерно с одним и тем же, например, машинами, но с чуть-чуть разным представлением этих машин.
например, для одного модуля достаточно кол-ва колес, а другому требуется описание каждого колеса.
сейчас чтобы эти два модуля простыковать надо в ручную написать мега-адаптер под один из модулей, и в этом мега-адаптере надо учесть все подобъектики модуля.
например, для одного модуля достаточно кол-ва колес, а другому требуется описание каждого колеса.
сейчас чтобы эти два модуля простыковать надо в ручную написать мега-адаптер под один из модулей, и в этом мега-адаптере надо учесть все подобъектики модуля.
в ручную написать мега-адаптер под один из модулейА что, глобальной замены WheelCount на Wheels.Count будет недостаточно?
А что, глобальной замены WheelCount на Wheels.Count будет недостаточно?дык, при интеграции скорее всего - это модули чужие причем скорее всего поставляемые в бинарниках.
но и open source не сильно поможет, т.к. поддерживать свою ветку чужого модуля - это еще тот гемор.
open source не сильно поможет, т.к. поддерживать свою ветку чужого модуля - это еще тот гемор
почему?
Многие так делают, ну и мы в том числе.
дорого, т.к. нужно лезть именно в реализацию, а нельзя обойтись только внешним стыком.
Что "дорого" — очевидно.
Дело в том что редко какая прога умеет именно то и именно так как надо. И еще и без багов.
Поэтому патчим 4Suite, Ghostscript, libxml, feedparser и тд и тп.
Дело в том что редко какая прога умеет именно то и именно так как надо. И еще и без багов.
Поэтому патчим 4Suite, Ghostscript, libxml, feedparser и тд и тп.
ты знаешь какие-то решения этой проблемы, кроме гипотетического ИИ?
Очевидно, что между двумя объектами с разными интерфейсами нужно строить мост.
Очевидно, что между двумя объектами с разными интерфейсами нужно строить мост.
Очевидно, что между двумя объектами с разными интерфейсами нужно строить мост.так хочется, чтобы для этого был некий язык и среда, а не чтобы это строилось с помощью рук и такой-то матери.
т.е. хочется реализации паттернов на уровне языка?
Какие тебе смогут помочь средства, если автор компонента пометил свой компонент sealed (final)
т.е. хочется реализации паттернов на уровне языка?нет.
Какие тебе смогут помочь средства, если автор компонента пометил свой компонент sealed (final)например, автоматическое построение внешней обертки
Очевидно, что между двумя объектами с разными интерфейсами нужно строить мост.только все-таки адаптер, а не мост.
это скорее должна быть фишка среды, а не языка
это скорее должна быть фишка среды, а не языкаописание адаптации (оболочки) - фишка языка
реализация адаптации(оболочки) - фишка среды
> В любом случае нужно придумывать спецификацию представления данных.
Да, но xml здесь выступает как промежуточный уровень. Т.е. придумать отображение твоих данных в xml может оказаться проще чем придумать отображение их же в potok oktetov (если эти данные обладают определённой структурой - xml и имеет смысл использовать в таких случаях).
Может я что-то не понял, но твоя позиция предстаёт в таком виде. "Язык программирования X тоже универсальный, но программы на нём писать тоже кто-то должен. Так чем он принципиально отличается от других языков?"
Да, но xml здесь выступает как промежуточный уровень. Т.е. придумать отображение твоих данных в xml может оказаться проще чем придумать отображение их же в potok oktetov (если эти данные обладают определённой структурой - xml и имеет смысл использовать в таких случаях).
Может я что-то не понял, но твоя позиция предстаёт в таком виде. "Язык программирования X тоже универсальный, но программы на нём писать тоже кто-то должен. Так чем он принципиально отличается от других языков?"
Т.е. придумать отображение твоих данных в xml может оказаться проще чем придумать отображение их же в potok oktetov (если эти данные обладают определённой структурой - xml и имеет смысл использовать в таких случаях).Ну вот какая такая структура естественно представится в виде дерева из дырявых строк? А дырявые строки - в основе идеи markup language.
Да, можно не писать самому преобразование чисел в строки, эскейпинг строк, простейший лексический анализатор. И всё. Вышеупомянутый json делает ровно это, и ничего лишнего. Лисповые функции read и print - тоже.
Аа. Т.е. в xml тебе не нравится неестественность того, что это не просто древовидная структура, а древовидная структура над простым текстом (по крайней мере так предполагалось раньше)?
ну я не знаю ещё, зачем нужны одновременно элементы и атрибуты
эти навороты нужны, чтобы цветной текст с картинками показывать, а не чтоб максимально просто обмениваться машинными данными
эти навороты нужны, чтобы цветной текст с картинками показывать, а не чтоб максимально просто обмениваться машинными данными
я так и не понял понимаю я тебя или нет
вот в джаве 7 ща модули вводят
если для них сделают наследование и все такое (ваще не представляю как, но допустим как-то такое воможно организовать)
то это будет то что ты хочешь?
т.е. что типа такого: в одном модуле твоя машина будет представлена в одном виде
в другом модуле эта же самая машина в другом виде
и чтобы на языке ты описывал токо разницу в представлениях машины, а при обращении к объекту автоматически бы делался кастинг к представлению в этом модуле из которого идет обращение
вот в джаве 7 ща модули вводят
если для них сделают наследование и все такое (ваще не представляю как, но допустим как-то такое воможно организовать)
то это будет то что ты хочешь?
т.е. что типа такого: в одном модуле твоя машина будет представлена в одном виде
в другом модуле эта же самая машина в другом виде
и чтобы на языке ты описывал токо разницу в представлениях машины, а при обращении к объекту автоматически бы делался кастинг к представлению в этом модуле из которого идет обращение
кстати
если говорить про ооп, то мне не нравится очень скудный набор ограничений видимости
private,public,protected + еще некторые
ну не хватает их
если говорить про ооп, то мне не нравится очень скудный набор ограничений видимости
private,public,protected + еще некторые
ну не хватает их
ну не хватает ихА тебе чего не хватает? распределения доступа по отдельным родам классов? это же недемократично
то это будет то что ты хочешь?конечно, именно это и нужно при построение больших систем
ну не хватает ихтак бери какой-нибудь CAS и вперед, т.к. такие права уже нужно делать средствами среды, а не средствами языка.
А тебе чего не хватает? распределения доступа по отдельным родам классов?ну хотя бы чтобы можно было дружественные модули указывать
в с++ 0 указать дружественные нэймспейсы
а в джаве - дружественные пакеты
Моё глубочайшее убеждение состит в том, что Web-программирование и объектная модель друг другу противопоказаныДаже если у твоего проекта сложная бизнес-логика?
Даже если у твоего проекта сложная бизнес-логика?ООП её не упростит
Оставить комментарий
Werdna
Решил запостить здесь небольшую простынь Горнала. Мне кажется, многим будет полезно.http://gornal.livejournal.com/55794.html