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

[ldimat]

опять же, я бы ее юзал только и исключительно для объявления зависимостей, а за нью пакет.подпакет.класс() отрывал бы конечности - это все равно что не писать код елочкой

[iflamberg]

Хотите знать правду - напишите письмо разработчику. А иначе вы - троль и место этой теме во флейме.

[sospamom]

iflamberg
1) Правду могут знать не только разработчики.
2) Разработчики тоже могут обмануть.
3) Я хочу услышать если не правду, то более-менее правдоподобное объяснение, а не те, что предъявлялись.

[Яски]

Зачем вам правда? Не мудите, напишите уже свой компилятор флеша — в байткоде нет импортов.

[BlooDHounD]

sospamom, Вам уже 3жды ответили, но Вы упор не видите. так что не вижу смысла в том, что бы "лично Вам" отвечать.

[iNils]

В какой то момент надо остановится и этот момент настал.

[sospamom]

Ниже описана причина по которой компилятор хочет, чтобы программист обязательно использовал инструкцию import, даже если указывается полный путь к классу наподобие

new paket1.Class1();

Причина:
Так как в следующем коде нет строчки:

import a.Class1;

то компилятор не ищет класс Class1 из пакета a в файловой системе. Компилятор считает a локальной переменной, а Class1 - её свойством.

Таким образом ускоряется компиляция, ведь компилятор не обращается к файловой системе когда не надо.

package 
{
	public class Main
	{
		public function Main()
		{
			var a = new A();
			var b = new a.Class1();	
		}
	}
}
 
class A
{
	var Class1:Class;
}

P.S.
Были указаны и другие предположения о необходимости обязательного использования инструкции import, даже когда указывается полный путь к классу наподобие:

new paket1.Class1();

Но эти предположения неверны.

Предположение 1:
import указывают, чтобы не указывать полный путь к классу.

Почему предположение ошибочно:
Это не объясняет обязательность использования инструкции import


Предположение 2:
import указывают, чтобы показать зависимости кода в данном классе, от классов в других пакетах.

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

В компиляторе добавили бы новый параметр, например:
mxmlc.exe -addImports

И компилятор в результате компиляции добавлял бы в исходные файлы комментарии по типу:

package 
{
	/*
	Этот код зависит от:
	paket1.Class1
	paket1.paket2.Class1
	*/
	public class  SomeClass
	{
 
	}
 
}

Данные вариант лучше, чем использование инструкции import по двум причинам:
1) Это комментарии, а не инструкции языка
2) Никто не сможет написать import *; а значит мы лучше будем видеть зависимости.

То есть использование инструкции import наоборот ухудшает видимость зависимостей в коде.



Предположение 3:
Инструкция import используется, чтобы при наличии одноименных классов в разных папках узнать какой именно мы класс создаём.

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

new paket1.Class1();
new paket2.Class1();

Предположение 4:
Если мы имеем следующий код, то import поможет нам разобраться что именно создавать компилятору, экземпляр класса Class1 который лежит в пакете a или экземпляр класса Class1, который является свойством переменной a.

package 
{
	import a.Class1;
	import b.Class1;
 
	public class Main
	{
		public function Main()
		{
			var a = new A();
			var b = new a.Class1();	
		}
	}
}
 
class A
{
	var Class1:Class;
}

Почему предположение ошибочно:
В данном случае нам приходится писать полный путь так как импортируются два одноименных класса:
import a.Class1;
import b.Class1;

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

[wvxvw]

Предположение 2:
import указывают, чтобы показать зависимости кода в данном классе, от классов в других пакетах.

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

В компиляторе добавили бы новый параметр, например:
mxmlc.exe -addImports

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

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

[AL.exe]

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

А вот кстати, если я импортирую что-то, что реально не использую, оно все равно будет вшито в конечный SWF-файл?

[ramshteks]

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