Зачем нужна инструкция import?

[Яски]

import:
1) делает доступным использование имени класса вместо полного пути
2) указывает компилятору как найти классы
3) код становится проще поддерживать, потому что классы не включенные в import, не попадут в результирующий swf файл.

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

Яски
Компилятор может подключить необходимые классы и без инструкции import. Я же ему указываю:

new paket1.Class1();

Компилятором флекса пользуются огромное кол-во людей по всему миру. Вы предлагаете всем писать полные пути до класса?

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

не ждал бы никто ничего минутами, можно было бы адресовать пути по которым ищутся исходники, и один раз запомнить все расположения. под флексом этим бы занялся fcsh, под flash ide - она сама.

Хорошо, а как вы собираетесь отслеживать появление новых файлов, удаление файлов? Что делать в ситуации когда есть две папки a и b, в каждой из которых есть класс Text и мы используем этот класс? С использованием импорта такой проблемы бы не было.
Если Вам не нравится import, напишите что предлагаете Вы.

[sospamom]

kup
Насчет as вы правы. Насчет this - нет, потому что в замыкании функции она будет указывать на глобальный объект и как вы обратитесь к переменной экземпляра? Но это всё мы уходим в сторону и разводим философию. Давайте разберемся с import.

wvxvw

импорт говорит о том, что вы используете пакет, а не свойство

Я знаю, что new paket1.Class1(); может обозначать например локальную переменную со свойством Class1 типа Class. Но дело в том, что import никак не поможет разобраться компилятору что именно я хочу создать, потому что инструкция import обязательная.

Яски
1) Объясните тогда почему инструкция use namespace необязательная?
2) Нет, я и так указываю полный путь new paket1.Class1();
3) И без импорта можно реализовать я ведь указываю new paket1.Class1();

Что делать в ситуации когда есть две папки a и b, в каждой из которых есть класс Text и мы используем этот класс?

new a.Text();
new b.Text();

Кажется ldimat понял, что я хочу узнать.

[BlooDHounD]

sospamom, в некоторых случаях и use namespace обязателен.
Яски, наличие import'a никак не влияет на

Сообщение от Яски

3) код становится проще поддерживать, потому что классы не включенные в import, не попадут в результирующий swf файл.

[sospamom]

BlooDHounD
Давайте не будем сейчас усложнять и рассматривать случаи обязательного использования use namespace, потому что эти случаи не прольют свет на import.

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

[BlooDHounD]

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

[ldimat]

я не понял зачем импорт, напишите примеры еще раз пожалуйста

[sospamom]

BlooDHounD
Напишите зачем нужно обязательное использование import, чтобы я понял, что вы имеете ввиду.

[Яски]

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

Яски, наличие import'a никак не влияет на

Согласен, я это понял позже.

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

[wvxvw]

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

ackage {
import flash.display.Sprite;

public class T extends Sprite {
function T() {
var Sprite:Sprite = new Sprite;
}
}
}

^^^^ такой код тоже чудесно компилится и ни у кого не возникает вопрос что я дальше буду использовать в катчестве Sprite, мне там поможет только new flash.display.Sprite(), и если я еще сделаю объект flash со свойством display у котого будет свойство Sprite, то до конструктора спрайта я вообще не представляю как можно достучатся

поэтому опять вопрос: зачем нужна импорт если она ничего не делает?
З.Ы. кеширование даже 1000 файлов ты особо не заметишь

Нет, такой код не будет замечательно компилироваться... может во Флеше... Флекс говорит об ambigous reference... Точно то же самое будет, если вы будете создавать переменные / неймспейсы с именами импортированых пакетов.

Понимаете, например в Яве или С# не нужно ключевое слово var / function потому что любая декларация интерпретируется одинаково - но это не так в ES языках, вы не можете обойтись без var т.как создадите неоднозначность - не понятно будет, используете ли вы переменную, неймспейс или метод. Точно так же и с импортом, если вы его не используете - вас нельзя будет однозначно понять. И как бы это вам сказать... судя по вашим увереным заявлениям о скорости компиляции и что сколько времени займет - вы просто много теоретизируете... но вряд ли сталкивались с этим на практике... Понимаете, в среднем-большом проекте, как правило, подключено 3-5 библиотек, библиотеки могут быть совсем не маленькими, ну и соответственно, они лежат в зип архиве - разархивировать несколько таких библиотек только для того, чтобы поискать там необъявленую переменную (и это, предположим, после того, как пол проэкта уже скомпилировалось) - поверьте, вам очень быстро перехочется...
Ей богу, исходники у вас есть - перепишите и попробуйте, всегда есть возможность, что вы правы, а все остальные ошибаются.

Ну или еще такой вариант, дизайнер экспортировал какой то символ как класс mc1, а вы у себя в функции объявили локальную переменную cm1, и когда ее использовали - случайно опечатались. Далее, следуя вашей логике, код скомпилировался без ошибок, потому что все, что вы делали с этой переменной было что-нибудь в духе: if (mc1) {...} - код перестал работать, но причину вам не говорит.

[ldimat]

переписывать ничего не нужно, напиши import package.* и все заработает
я компилил тот код чертвертым флексом и все работало