Balancer: Все сообщения за 24 Июля 2007 года

AlexZr> Подскажите пожалуйста что храниться в таблице accounts колонка Comments?

"Русскаго языка" когда будем учить?

После долгой расшифровки было получено примерно следующее: "Подскажите пожалуйста, что хранится в колонке Comments таблицы accounts?"

Это имелось в виду?

Комментарии там хранятся. Например, за что был забанен данный аккаунт.

•  инфо
•  инструменты
• Ответить на сообщение

timochka> Рома, объем кода давно никого не пугает, пугает сложность. Т.е. много простого кода лучше чем мало сложного.

Меня пугает. Если мне для реализации класса, который в ином случае реализуется в 10 строк, придётся писать 100 строк, то на весь проект вместо месяца работы мне понадобится год. А та же Авиабаза в нынешнем варианте потребовала бы уже не 10 лет экспериментов, а 100 лет

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

В противном случае до сих пор бы все программировали в машинных кодах

timochka> Ты смотришь на проблему с позиции разрабочика-одиночки. Сейчас развитие идет в сторону групповой разработки.

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

timochka> 1) Для влезания в середину существующего кода желательно изучать как можно меньше. Т.е. разлишные модули должны быть слабо связанны.

Множественное наследование этому никак не мешает.

timochka> 2) Для того что-бы переиспользовать существующую реализацию нельзя требовать изучения толстого унаследованного API (крайне желательно перечислить большинство методов объекта прямо в классе реализации).

Опять же, со множественным наследованием это никак не связано. Ну выдаст тебе компилятор ошибку одноимённых методов, ну избавишься ты от их использования или прямо укажешь родителя.

Ведь точно такая же проблема вылезает, скажем, в той же Java при импорте. Совершенно разные классы разных пакетов могут иметь одно имя и может вылезать конфликт имён при массовом испорте сторонних пакетов. Компилятор в этом случае просто ругается и программист уточняет, чей конкретно класс он имел в виду.

Почему для имён классов такой подход допустим, а для имён методов в случае множественного наследования - нет?

timochka> 3) У множественного наследования есть еще проблема с многократным наследованием реализации (и данных) одного базового класса от нескольких родителей

Не понял проблемы. Если у кого-то из родителей в цепочке метод переопределён - это будет другой метод с тем же именем и компилятор прекрасно отловит неоднозначность.

timochka> В большом коллективе 80% работы это задачи типа есть неправильное поведение в таком-то случае.

Компилятор способен в 100% случаев отловить проблемы множественного раследования. Как он отлавливает те же проблемы со "множественным импортом".

Поэтому неожиданного поведения тут просто не может быть. Или программа не соберётся, или соберётся, но с явным знанием компилятора о том, какой метод вызывался.

timochka> Поэтому считают что лучше явно прописать все методы в классе при агрегации, чем полагаться на унаследованную реализацию.

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

1. int modify_time() { return parent2->modify_time(); }
2. int create_time() { return parent2->create_time(); }

мы получим:

1. int modify_time() { return parent2->modify_time(); }
2. int create_time() { return parent2->modify_time(); }

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

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

•  2
•  инфо
•  инструменты
• Ответить на сообщение

timochka> Считается, что ошибки не от опечаток (это проверит компилятор)

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

В то время как при множественном наследовании ошибку неоднозначности компилятор отловит.

•  инфо
•  инструменты
• Ответить на сообщение

Wyvern-2> Странник - Адольф Виссарионович Полпот фон Штирлиц-Исаев

Надо же было так смешать ТИМы "Гамлета", "Максима Горького", не знаю кого и, собственно, "Штирлица" Ну ничего в них общего нет

•  инфо
•  инструменты
• Ответить на сообщение

Сергей-4030> Ничего подобного, с какой стати? ОК, есть обьект "страничка". Иногда статическая. Иногда динамическая, ис БД. ОК, наша страничка имеет ссылкы на DataProvider . Где ты увидел удвоение классов?

Ну вот. У меня есть наворочанная система, использующая прямые вызовы. Да, идея с DataProvider в голову приходила. Но:
- Есть тонны кода, который придётся тупо переписывать.
- Получаем заметное падение производительности, поскольку у нас появляется лишняя операция извлечения этого DataProvider.
- Наконец, придётся переписать всю систему шаблонов, так как используемая не понимает метода от метода для класса. Ну вот такие у Smarty ограничения.

Итого - имеем человекомесяц лишней работы... Да проще уж, действительно, всё на Python переписать, где это множественное наследование есть Объём работы сопоставим будет. И перспективы, опять же...

Сергей-4030> Что такое "текужее представление"?

Шаблоны, элементы навигации и т.п. И вместо одного класса "страница такого-то вида" придётся делать два: "дата-провайдер такого-то вида" и "раздел сайта такого-то вида, использующий такой-то дата-провайдер".

•  инфо
•  инструменты
• Ответить на сообщение