как правильно формировать пакеты?
 

Здравствуйте!
Не могу понять стандарт для формирования пакетов.
Допустим я сделал пакет buttons, при этом я думаю, все необходимые классы для создания кнопок должны лежать в этом пакете, кроме стандартных классов.
Так, если я захочу использовать кнопки в другом проекте, можно просто кинуть туда этот пакет и использовать не, задумываясь, что каких-то классов будет не хватать.
Теперь другая ситуация - на одном уровне с пакетом buttons, лежит пакет scrollbars, в котором, к примеру классы Scrollbar1, Scrollbar2, ... наследуются от класса ExtendsSprite, который лежит в пакете buttons, так как классы Button1, Button2,... тоже наследуются от ExtendsSprite.
Если мне не нужен пакет buttons в новом проекте, но нужен scrollbars, то мне придется все равно создавать пакет buttons, который будет содержать как минимум один класс ExtendsSprite, что создает неудобство.
Извините, что так много написал, хотел объяснить суть.
Нужны ваши советы

Кинуть? Нельзя копипастить библиотечные классы - тогда исчезает их преимущество: экономия времени на дебаге одного и того же в разных проектах. Библиотечные классы подключаются как source-path к проекту, копипастяться только совсем в особых и тяжелых случаях, когда ложат на совместимость и расходы на дебаг ради специфического функционала.

По поводу того, что одному пакету нужны другие: значит они должы принадлежать одной либе - всё просто! Если подключать source-path к проекту, то во флешку встроятся только используемые, т.е. нет смысла что-то там специально копипастить.

спасибо expl! В том,что вы написали я усмотрел что-то полезное, только не понял как пользоваться.
как пользоваться source-path?
Я пользуюсь Flash Builder 4.6
открыл свойства проекта, нашел пути сборки actionScript, исходный путь, добавить папку, и указал папку пакет из другого проекта - в новом проекте создался ярлык на эту папку.
пакет из старого проекта содержал класс, наследующий класс, из другого пакета.
тем самым новый проект не видит наследуемый класс - т.е нужные классы не встроились.

Не надо "из другого проекта".. Создайте себе постоянную директорию, в которой будут лежать Ваши библиотеки, и разрабатывайте классы "там". Для конкретных проектов подключайте эту директорию, или лучше укажите путь к ней как дополнительный к дефолтному, чтобы было 2 (3...n) source path. Чтобы было одно постоянное хранилище Ваших разработок. Это к тому же дисциплинирует и помогает не называть классы и пакеты абы как (например, "ExtendsSprite" не говорит о классе вообще ничего. Имена должны отражать специфику класса, его назначение).

спасибо Wolsh!, a source-path я так понял в параметрах компиляции указывать надо. это верно?

Это естественно относится к таким классам и пакетам, которые изначально предполагается использовать в разных проектах, "универсальные" (пардон за мой санскрит). Конкретные классы, имеющие смысл только в рамках текущего проекта, пусть лежат в директории проекта, не стоит засорять свою библиотеку.
Так же рекомендую поступить со сторонними библиотеками, типа твинов от гринсок и т.п. — завести для них такое же постоянное хранилище "чужих классов", и подключать их к проектам по мере надобности. Не стоит включать их как постоянный source, чтобы не забивали автокомплит своими предложениями.

Добавлено через 4 минуты
Не в курсе, как там в билдере, пишу код только в ФД. В ФД можно указывать дополнительные пути к библиотекам для каждого конкретного проекта, и можно указывать "базовый" массив (набор) source path, общий для всех проектов наравне с классами "от Adobe"))

Во FlashBuilder:
Правая кнопка по иконке проекта в дереве проекта -> Properties -> ActionScript BuildPath -> Source Path -> AddFolder
Указывается папка на один уровень выше корневой, т.е. если у вас класс ru.somePackage.SomeClass лежит в src/ru/somePackage/SomeClass.as, то нужно подключать папку src.

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

вопрос по ответу от Wolsh . а, что тогда с переносимостью?
к примеру один проект делают два человека с разных компьютеров. либо я делаю проект, в котором указываю путь к библиотеке, затем мне нужно перекинуть проект на другой компьютер.
мне придется создавать директории на 2-м компьютере с теми же именами, что на 1-м компьютере.
Поясню. У меня есть директория для моих проектов, я работаю вместе с другим программистом, у него на компе своя директория для хранения проектов. Другой программист может скопировать у меня проект, скомпилировать у себя и проект сразу заработает, а в этом случае мне придется переписывать настройки компиляции?

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

Не изменяйте, пишите новые)) На то она и "библиотека", а не папка рабочего проекта. Если Вам нужен не такой класс, как в библиотеке, пишите его в проекте. А по вашей логике можно и в гринсок залезть да переписать там десяток классов под свои нужды....

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

1. Настройки IDE обычно не комитятся в репозиторий.
Т.е. в самом простом случае при получении кода программист настраивает пути к либам и всему остальному вручную

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

2. Есть ещё автоматическая сборка, но здесь всё гораздо проще - основной скрипт (например, ant) - комитится в репозиторий и одинаков на всех машинах. Файл специфических настроек путей не комитится и туда вносятся только те настройки, с которыми программисту не повезло - которые не совпали с прописанными с скрипте (у автора скрипта обычно таких нет :) ). Т.е. чтобы что-то собрать на своей машине, программист дописывает пару несовпавших настроек в файл конфигурации ant.

Если голые батники используются - то там сложнее - каждому проггеру нужно написать свой батник, запускающий другой (неизменяющийся) батник с нужными настройками. Батников не один, поэтому лучше использовать ситсемы сборки типа rake(все хвалят, но устанавливается _очень_ тяжело на windows) или ant.

Это палка о 2-х концах:
1. Вынести в либу
+ все баги найденные там будут исчезать во всех проектах
+ новые фитчи будут появлятся во всех проектах
- все изменения в либе надо тщателно проверять, чтобы не поломать предыдущие проекты (поэтому обычно в библиотеке больше всего автоматических тестов)
2. Оставить в проекте
- мучительный копипастинг новых фитч и заплаток
- копипастинг не может проходить без появления багов
+ легкость изменений - не надо обеспечивать совместимость
+ гарантия того, что старые проекты не поломаются

я не это имел ввиду, я имел ввиду что если мой проект скопирует другой программист, то проект работать у него не будет

Это я и называю конкретным классом для конкретного проекта. В библиотеке такому не место.
При "архивации" старого проекта можно скопировать необходимые либы в его корень. Другого способа не вижу))
Важный минус к пункту два: 100500 вариантов вроде бы одного пакета.
p.S. Я не зря говорил о дисциплине))

Сложно найти проект, который не использует ничего внешнего.
Но можно, конечно, каждый раз при изменении своей либы генерить swc и копировать ее в папки с проектом.

Ну да, логично было бы.

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

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

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

Все редакторы кода позволяют сохранить настройки конкретного проекта. Или не все? Если не позволяет - в топку. Таким образом настройки также можно закоммитить.

При совместной разработке используйте систему версирования, это категорически обязательно - отпадут вопросы по составу классов проекта у других программистов. Впрочем и для индивидуальной разработки svn/git ( кому что удобнее ) очень рекомендуем. Помимо сохранения состояния проекта в каждом отдельном коммите, она позволяет работать над одним и тем же проектом хоть на десятке машин, не копипастя ни одного файла.

Как-бы проблема в том что настройки путей (и не только путей) у всех разные. И если их коммитить - у всех кодеров поочерёдно будет переставать собираться. Тут нужны более тонкие подходы.
Ладно, с путями к либам ещё можно договорится (хотя бывали случаи что вот лежит либа на D, а у чувака нет такого диска :), он согласен, что у всех должно быть одинаково, но изменить путь на D:\workspace\our-libs не может). Но с путями к компилятору, java-машине и т.д. и т.п. такое уже не прокатывает.

Как будто можно сделать по-другому. Было бы интересно посмотреть на 2-х кодеров, работающих с одним кодом без системы контроля версий.
... хотя, говорят бывает O_o таджик-свн

Настройки путей? Если используется свн, то классы вы подключаете не через проект, а через свн ( команда externals ), при этом копии нужных классов выгружаются в директорию проекта, сохраняются в копиях созданных экспортом, и в не зависят от последующих изменений в подключенных, оригинальных классах ( правда это надо указать специально).

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

Добавлено через 9 минут
а что такое свн?

Добавлено через 1 минуту
это контроль версий и есть

основные разновидности:
http://ru.wikipedia.org/wiki/Subversion
http://ru.wikipedia.org/wiki/Git

Что тут можно сказать, я в восхищении от вашей брутальности и суровости O_o (Вручную сливать правки 2-х человек да еще и только раз в неделю!!)
А как вы бекапы то делаете - сохраняете в zip с датой а если надо откатится вручную выясняете какие правки надо откатывать, а какие нет?

fish_r:
Так, стоп. У нас всегда был отдельный репозиторий (на худой конец отдельная папка в svn репозитории) для библиотек и отдельные для проектов.
А вы предлагаете как-то использовать в директории проекта папку с другого svn/git-репозитория? И можно как-то сделать, чтобы обновление во всех проектах шло через один репозиторий либ?

В subversion есть фича называется externals c помощью неё можно подключить к проекту классы находящиеся в том же или в другом репозитории. При этом копии нужных папок с файлами классов размещаются в проекте. Изменения этих классов в "родном" расположении отслеживаются и при апдейте заливаются в текущий проект, но это можно запретить указав номер версии коммита которым хотим ограничиться.
У меня туртоза для винды, здесь это делается через контекстное меню настроек папки проекта. Это можно сделать также в файле entries закрепленном за соотв-ей папкой.

Вот здесь есть общее описание http://svnbook.red-bean.com/nightly/...nced.externals.
Как это реализуется в конкретном клиенте (обертке) надо наверно смотреть документацию. Как это делается в git не знаю, с гитом опыта работы нет.

а как еще два человека могут править один файл одновременно?

Добавлено через 3 минуты
А как еще два человека могут править один файл одновременно?

Большинство систем может автоматически объединить (слить) изменения, сделанные разными разработчиками.

Bgg прав - по вам плачет система контроля версий. Прям срочно займитесь этим вопросом.
Для начала ( быстрого ) могу порекомендовать TortoiseSVN.
Удобная система, хотя возможно с этим могут многие поспорить :), документация понятная и простая, и на рус. и на англ. Очень быстро освоите.

объединить два файла в один автоматическая система не сможет, потому, что она не знает как это сделать. Файл должен проанализировать человек
Я это делаю через Total commander - сравнение файлов. При этом я копирую те строки, которые созданы другим программистом, к себе, а если встречаются несовместимые моменты, дорабатываю код, так как я знаю суть того, что должно получиться

Добавлено через 4 минуты
Вот объясните мне пожалуйста, как вы сделаете такую задачу через систему контроля версий. К примеру у меня 20 файлов в которые я должен внести изменения, причем в 10 из них должен внести изменения другой программист. Мы работаем одновременно - это нельзя делать поочередно, так как времени нет.

3 страницы объяснений коту под хвост. Предсказываю ещё 10 подобных страниц.

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

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

Вот именно для этого система контроля версий и используется. В простом случае без веток:
-Ты забрал версию X, поправил
- Друг забрал версию X, поправил
- Ты вкомитил
- Друг вкомитил.
Перед коммитом друг забирает твои правки,
система берет изменения друга относительно версии X и накладывает поверх наложеннных твоих правок. Т.е. она не файлы перетирает, а добавляет _относительные_ изменения.
В случае если нет конфликтных правок (ты изменил 10 на 20, а друг 10 на 30, например) - никаких напряжений мозжечка не потребуется - потребуется один клик или пару комманд в консоли. Если есть - в 90% потребуется 5 минут для того чтобы вам с другом разобраться, как должен выглядеть слитый файл.

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

Большинство людей начинает использвать SVN в тот же день в который его впервые видит в новой конторе. С git сложнее, но можно разобраться тоже.

ок! спасибо!
Хотелось бы также узнать соглашения по пакетам
к примеру, может(правильно) ли обращать класс лежащий в пакете1 к классу в пакете2
если
1:пакет1 и пакет2 лежат на одном уровне.
2:пакет1 лежит в пакете2
?

соглашения по пакетам? а есть такие? есть соглашения по именованию пакетов, но и они носят рекомендательный характер...

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

на счёт путей, в flash builder есть такая штука как "Переменные пути" в свойства проекта. а ещё есть ant с возможностями ввода своих локальных путей