Есть ли будущее у DELPHI?

Цитата --Ins-- @ 26.03.12, 09:26

Цитата DesweR @ 26.03.12, 01:57

А ты вообще как ЭТО представляешь или что под ЭТИМ подразумеваешь??

Я, кстати, себе это отлично представляю и Смайка поддерживаю

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

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

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

Добавлено 28.03.12, 18:32

Цитата --Ins-- @ 26.03.12, 17:36

В общем, с момента Delphi 7 язык скорее испортили, чем сделали лучше. Ощущение целостности и согласованности языковых инструментов - пропало

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

Почему та же IDEA предлагает свои коммерческие продукты бесплатно разработчикам OpenSource решений? Почему Embarcadero не понимает элементарного? Они первые должны быть в этом заинтересованы.

Цитата [S]mike @ 28.03.12, 17:19

Справедливости ради хочу сказать. Если в Object Inspector стереть Name компонента, то для него не будет генерироваться объект в классе формы.

НО!

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

Добавлено 28.03.12, 19:48

Цитата [S]mike @ 28.03.12, 17:19

Согласен. Библиотека компонентов в целом в Delphi крайне не продумано. Тебя принуждают иметь зоопарк. Нельзя в одном проекте использовать одни компоненты, а в другом другие. И самое худшее - нельзя в проекте использовать СВОИ компоненты. Нужно делать пакет, который ставить вместе со всеми остальными. И потом искать свои компоненты среди 1000 других. Ужас!

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

Сообщение отредактировано: --Ins-- - 28.03.12, 19:54

Цитата --Ins-- @ 28.03.12, 19:45

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

Ну я читал об этом у Марко Кэнту. Он как бы автор единственной вменяемой книги по Дельфям. А если оно совсем нелегально - то зачем было давать такую возможность? В ранних дельфях такого не было.

Цитата --Ins-- @ 28.03.12, 19:45

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

Кому ты это рассказываешь? У меня все-таки очень приличный опыт дельфи-программирования. А потом будешь разруливать мусор в файлах других проектов (хорошо заметно в системе контроля версий). Потому что среда записывает какие пакеты ты _отключил_, а не какие включил. Мегапродумано, да? То есть поотключаешь компоненты, откроешь дельфийский проект - вуаля, у тебя прописываются все твои исключенные проекты, в системе контроля версий мусор, хотя ты не сделал ни единой правки в коде! Или же наоборот, придется в каждом проекте настраивать проекты, сотни раз чекбоксы напротив пакетов в каждом проекте. Кому это надо?

Сообщение отредактировано: [S]mike - 28.03.12, 21:01

Цитата --Ins-- @ 28.03.12, 19:45

Хотя я не знаю каким магическим образом они бы появились на палитре

Таким же, каким они появляются в библиотеке в Xcode/IB.

Цитата korvin @ 29.03.12, 03:49

Таким же, каким они появляются в библиотеке в Xcode/IB

Я не знаю что такое Xcode/IB, и не представляю как код компонента, не включенного в пакет, который загружен средой в собственное адресное пространство, может быть помещен на форму в design-time. Если ты знаешь - объясни мне

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

amk, вопрос не в отображении на палитре. Компонент выполняет свой код в design-time. Как это возможно? В случае пакетов - все понятно, пакет это dll, загруженная в АП среды

Цитата --Ins-- @ 29.03.12, 08:52

Цитата korvin @ 29.03.12, 03:49

Таким же, каким они появляются в библиотеке в Xcode/IB

Я не знаю что такое Xcode/IB, и не представляю как код компонента, не включенного в пакет, который загружен средой в собственное адресное пространство, может быть помещен на форму в design-time. Если ты знаешь - объясни мне

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

Добавлено 29.03.12, 10:34

Цитата --Ins-- @ 29.03.12, 10:16

amk, вопрос не в отображении на палитре. Компонент выполняет свой код в design-time. Как это возможно? В случае пакетов - все понятно, пакет это dll, загруженная в АП среды

Нет, не выполняет, зачем?

Цитата korvin @ 29.03.12, 10:33

Внутреннего механизма не знаю

Ну и я не знаю. Поэтому и написал, что было бы неплохо, но вот как это осуществимо - не имею понятия:

Цитата --Ins-- @ 28.03.12, 19:45

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

Добавлено 29.03.12, 10:37

Цитата korvin @ 29.03.12, 10:33

Нет, не выполняет, зачем?

Спорим?

Цитата --Ins-- @ 29.03.12, 10:16

amk, вопрос не в отображении на палитре. Компонент выполняет свой код в design-time.

И? Что мешает одновременно с размещением на палитре загрузить нужный код?
Непонятно только, зачем? Вот когда компонент будет брошен на форму, дизайнер формы пусть и загружает design-time код для исполнения.

Цитата amk @ 29.03.12, 11:00

И? Что мешает одновременно с размещением на палитре загрузить нужный код?

Не могу себе представить механизм, как это будет происходить

Цитата --Ins-- @ 29.03.12, 10:36

Спорим?

Ты ж не знаешь, что там делает Xcode/IB, о чем хочешь спорить? Я вот уверен, что никакой свой код компонент в Xcode/IB не выполняет.

Цитата korvin @ 29.03.12, 12:30

Ты ж не знаешь, что там делает Xcode/IB, о чем хочешь спорить?

А мы разве не о компонентах и пакетах в Delphi говорили? Для меня там загадка как сделать иначе, чем сделано теперь, для тебя нет и ты критикуешь эту модель и еще и не веришь мне почему там иначе сделать проблематично? Докажи обратное, и не съезжай с темы

http://files.pfrf.ru/userdata/branches/ot_...echen_3.1.2.zip

Прога создана школьником кнопко-кидальщиком на Делфи для отчетности предприятий в Пенсионный фонд РФ

Сейчас моя задача: помочь кадровику составить отсчет с помощью этого ***, что бы сдать отчет в ПФ, потому что документы они уже не принимают