Как правильно называть пакеты?

[Zebestov]

Сообщение от LifeIsRhythm

Да, но мне нужно создать массив задач и название тоже будет tasks... И это уже ошибка.
Или писать allTasks?

taskArray

[ChuwY]

Могй голос уходит за tasksList.

[Zebestov]

Сообщение от ChuwY

Мой голос уходит за tasksList.

taskList тогда уже

[caseyryan]

Наверное, я плохо объяснил... Свойства у меня protected, так-как они используются в классах-наследниках, но для них нужно сделать геттеры. Понимаете, для protected свойств - геттеры, public геттеры. И по этому я и спросил, как в таких ситуациях должны выглядеть сами protected свойства? Они же не могут быть с подчеркиванием, а это означает, что нужно придумывать какую-то приставку или ещё что-то, чтобы имя с геттером не совпадало. Вот я и поинтересовался, есть ли упоминание об этом в конвенции.

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

[Wolsh]

а для изменения из потомков создать свое пространство имен и в потомках использовать его для полного контроля над свойствами

И к чему городить огород, если можно просто объявить их protected?
По поводу оформления — я просто ставлю прочерк как и для private. Для меня главное пометить, что это свойство недоступно извне и является "личным" для экземпляра. Для данного класса в цепочке наследования оно по-сути тот же самый private, разница есть только при анализе самой цепочки наследования, да и то... нет, ну на самом деле — Вы ведь все-равно не сможете в наследнике обращаться к private суперкласса. То есть, в коде класса-наследника не будет этих переменных суперкласса, так зачем выдумывать какие-то особые приставки чтобы отделить protected от того, чего вообще нет в коде? (разве что свои собственные private наследника, но сколько их может быть?). Не усложняйте правила игры — конвенции нужны для упрощения, а не усложнения разбирательства с кодом.

[caseyryan]

И к чему городить огород, если можно просто объявить их protected?

Чтоб было красиво)
Но, по большому счету, для своих проектов даже protected свойства не нужны. У меня еще ни разу не было случая, где их использование было реально необходимо. Все делалось исключительно из соображений "красоты" кода. Ведь использование _ на свойствах protected и private одновременно, ничем не лучше объявления свойства как public.

[Wolsh]

Наследование вообще не очень богато в AS3, обычно рекомендуется использовать композицию. Если посмотреть на другие языки, то да, там ради каждого нового свойства готовы создать новый класс (тех же GoF приходится постоянно интерпретировать хотя бы в интерфейсы, обилие наследований бросает в дрожь). Флэш таки ограничен размером предоставляемой памяти, да и профессиональным уровнем разработчиков тоже))) Я пользовался protected довольно массированно, однако это был, не побоюсь этого слова, настоящий хардкод — у меня была базовая кнопка и несколько ее наследников, отличающихся только цветом. Цвета и были захардкодены в protected-свойствах: я не собирался давать публичный доступ к цветам, но мог довольно быстро состряпать нового наследника, если понадобится какая-то серобуромалиновая кнопка — весь код наследника и состоял только из инициализации цветов. Ну и как бы ежу понятно, что это такой архитектурный бзик и можно сделать все совсем по-другому. Но меня такой вот простой и этим "красивый" вариант более чем устроил в условиях того проекта (набор контролов для быстрой сборки интерфейсов тестирования).

[ChuwY]

protected свойства не нужны

Понимаю, что вырываю из контекста, но ради интереса сейчас посчитал: на проекте используется 585 переопределенных защищенных методов (без учета сторонних библиотек)
На самом деле зря вы их так.
Использование в паре public final и protected override методов бывает очень удобно и полезно.

[in4core]

ChuwY - мы с Костиком синглтоны, у нас не командная игра, поэтому и протектед нет. У нас с вами просто разные пути и соотвественно разный код

[caseyryan]

Понимаю, что вырываю из контекста, но ради интереса сейчас посчитал: на проекте используется 585 переопределенных защищенных методов (без учета сторонних библиотек)

Да, именно, из контекста. Я же сказал, что для своих проектов можно без них обойтись, просто заменив на паблики. Все будет так же работать.
И я не сказал, что это не удобно. Я сказал, что без них можно обойтись, так же как можно обойтись без mvc, например.
Я лично использую protected свойства, но мне редко бывает нужно делать для них public геттеры, хотя, такую ситуацию можно легко представить