Динамическая типизация [re: А какие технологии сейчас модные?]
нормальную динамическую типизацию
что это? можно объяснить для непосвященных на пальцах
Это когда в языке есть объекты, которые можно менять по ходу работы, т.е. добавлять/удалять интерфейсы, методы, поля и т.д.
При этом экземпляр остается тем же самым, но у объекта меняется тип.
ps
Под типом понимается совокупность поддерживаемых интерфейсов, методов и т.д.
При этом экземпляр остается тем же самым, но у объекта меняется тип.
ps
Под типом понимается совокупность поддерживаемых интерфейсов, методов и т.д.
это не ограничивается приведением типа?
Вопрос не понял. Переформулируй его чуть-чуть по другому, пожалуйста.
Динамическая типизация это больше чем
? (или вообще a=b; в зависимости от того, кто от кого отнаследован)
a=(Type2)b;
? (или вообще a=b; в зависимости от того, кто от кого отнаследован)
Иногда хочется, вообще, ничего не добавлять, а просто уметь выполнить или не выполнить любой внешний запрос (как на приведение к определенному типу, так и на вызов метода с определенной сигнатурой).
В некотором приближение, да, можно ограничить только запросами на преобразование к определенному типу.
ps
Но после того, как преобразовались к определенному типу надо же еще выполнять каждый из методов, если мы их не умеем выполнять в общем виде, то придется генерить налету все методы target-типа, а это уже тоже геморрой.
ps
Но после того, как преобразовались к определенному типу надо же еще выполнять каждый из методов, если мы их не умеем выполнять в общем виде, то придется генерить налету все методы target-типа, а это уже тоже геморрой.
Возможно, то, что я сейчас скажу - глупость, но разве это делается не при помощи Map и какой-то матери?
И чем поможет Map?
зы
Напиши, например, с помощью Map адаптер на типизированную коллекцию , адаптер например должен отфильтровывать все отрицательные элементы
зы
Напиши, например, с помощью Map адаптер на типизированную коллекцию , адаптер например должен отфильтровывать все отрицательные элементы
Это когда в языке есть объекты, которые можно менять по ходу работы, т.е. добавлять/удалять интерфейсы, методы, поля и т.д.
При этом экземпляр остается тем же самым, но у объекта меняется тип.
Какая-то очень странная фича, зачем это нужно?
В JDK 1.5 кстати гораздо более интересная возможность - bytecode transformation.
Поищи, например, в интернете на Java Code Generator.
Большая часть таких генераторов - генерят код для всяких разных адаптеров (адаптер к базе, адаптер к сохранению/Загрузке, адаптер к web-сервису и т.д.)
Все эти адаптеры пишутся в пару строчек, если есть возможность динамически обслуживать внешние запросы.
ps
"bytecode transformation" - нацелен на оптимизацию быстродействия работы программы, а не на ускорение написания программ.
Большая часть таких генераторов - генерят код для всяких разных адаптеров (адаптер к базе, адаптер к сохранению/Загрузке, адаптер к web-сервису и т.д.)
Все эти адаптеры пишутся в пару строчек, если есть возможность динамически обслуживать внешние запросы.
ps
"bytecode transformation" - нацелен на оптимизацию быстродействия работы программы, а не на ускорение написания программ.
Адаптер или прокси? Динамические прокси в Java существуют уже года 3. Что касается адаптеров, то для них есть такая штука как CGLIB. Bytecode transformation - это именно CGLIB на уровне JDK.
> Адаптер или прокси?
Разница между адаптером и прокси чисто логическая.
Единственная разница - Адаптер - адаптирует прикладной функционал, а прокси - системный функционал (например, поддерживая какой-либо транспорт).
> Динамические прокси в Java существуют уже года 3
Они не динамические, они скорее просто runtime-овые - но это не интересно, это можно сделать и руками.
Разница между адаптером и прокси чисто логическая.
Единственная разница - Адаптер - адаптирует прикладной функционал, а прокси - системный функционал (например, поддерживая какой-либо транспорт).
> Динамические прокси в Java существуют уже года 3
Они не динамические, они скорее просто runtime-овые - но это не интересно, это можно сделать и руками.
Единственная разница - Адаптер - адаптирует прикладной функционал, а прокси - системный функционал (например, поддерживая какой-либо транспорт).huh? это принципиально разные вещи
> Динамические прокси в Java существуют уже года 3В runtime хрен что руками сделаешь.
Они не динамические, они скорее просто runtime-овые - но это не интересно, это можно сделать и руками.
> huh? это принципиально разные вещи
И что же в ниже указанном коде такого разного?
Код для прокси:
Код для адаптера:
> В runtime хрен что руками сделаешь.
Генерить текстовые файлы Java умеет.
Компилировать текстовые файлы тоже умеет
Загружать скомпилированные сборки тоже умеет
Все это вместе позволяет генерить в runtime-е все что угодно.
Поэтому я не понял твое высказывание.
И что же в ниже указанном коде такого разного?
Код для прокси:
class UserProxy: IUser
{
public string GetName
{
return Transport.GetString;
}
}
Код для адаптера:
class UserAdapter: IUser
{
public string GetName
{
return Какой-тоДругойUser.GetName;
}
}
> В runtime хрен что руками сделаешь.
Генерить текстовые файлы Java умеет.
Компилировать текстовые файлы тоже умеет
Загружать скомпилированные сборки тоже умеет
Все это вместе позволяет генерить в runtime-е все что угодно.
Поэтому я не понял твое высказывание.
Читай классиков. Кстати, примеры для адаптера и для прокси у тебя перепутаны.
В том числе и то, чего тебе изначально хотелось
типа самомодифирующихся классов
Все это вместе позволяет генерить в runtime-е все что угодно.
В том числе и то, чего тебе изначально хотелось
типа самомодифирующихся классов> Читай классиков. Кстати, примеры для адаптера и для прокси у тебя перепутаны.
В честь чего это они перепутаны?
> В том числе и то, чего тебе изначально хотелось типа самомодифирующихся классов
И как? Тип уже созданного экземпляра же менять нельзя....
В честь чего это они перепутаны?
Все это вместе позволяет генерить в runtime-е все что угодно.
> В том числе и то, чего тебе изначально хотелось
типа самомодифирующихся классовИ как? Тип уже созданного экземпляра же менять нельзя....
а можно про bytecode transformation подробнее
Это новый пакет java.lang.instrumentation. Фактически позволяет создавать нечто вроде плагинов (ClassFileTransformer) к любым ClassLoader-ам, т.е. при загрузке класса можно его каким-то хитрым образом поменять. Что сильно упрощает использование таких библиотек как CGLIB.
> И как? Тип уже созданного экземпляра же менять нельзя....
Ясное дело, это же не Smalltalk. Но это решается, например, агрегацией.
Ясное дело, это же не Smalltalk. Но это решается, например, агрегацией.
прикольно
> Но это решается, например, агрегацией.
Да, можно, но только придется тогда придумывать свою конструкцию приведения типов и полностью неиспользовать стандартые приведения типов.
Да, можно, но только придется тогда придумывать свою конструкцию приведения типов и полностью неиспользовать стандартые приведения типов.
ну в ATL есть CComQIPtr
CComQIPtr<IUnknown> p;
CComQIPtr<IStorage> q = p; // вызывается QueryInterface
еще один + в пользу VC++ 2005
CComQIPtr<IUnknown> p;
CComQIPtr<IStorage> q = p; // вызывается QueryInterface
еще один + в пользу VC++ 2005
Это можно и на Generic-ах сделать.
> еще один + в пользу VC++ 2005
Я восхищаюсь возможностями связки .Net+C++, но меня просто в дрожь бросает, когда я вспоминаю, что C++ является однопроходным (может быть двухпроходным) языком....
Я восхищаюсь возможностями связки .Net+C++, но меня просто в дрожь бросает, когда я вспоминаю, что C++ является однопроходным (может быть двухпроходным) языком....
нет, нельза
по крайней мере в C#, там операторы статические, а с ним дженерики не работают
хотя может с помощью конструкторов
можно думаю в С++ если сделать вируальный оперетор приведения (хотя не уверен, что можно в ref class иметь виртуальные опереаторы)
по крайней мере в C#, там операторы статические, а с ним дженерики не работают
хотя может с помощью конструкторов
можно думаю в С++ если сделать вируальный оперетор приведения (хотя не уверен, что можно в ref class иметь виртуальные опереаторы)
Так проще что-то такое сделать
Зачем в .Net-е заводить такой класс, как CComQIPtr?
public class Cast
{
public static T From<T>(IServiceProvider provider)
{
return (T)provider.GetService(typeof(T;
}
}
void main
{
IA2 a2 = Cast<IA2>.From(a1);
}
Зачем в .Net-е заводить такой класс, как CComQIPtr?
но это не тоже самое
там smart указатели
ptr<IA1> a1 = ....
ptr<IA2> a2 = ....
...
a2 = a1; // конвертация, здесь даже не нужно знать как конветрить
там smart указатели
ptr<IA1> a1 = ....
ptr<IA2> a2 = ....
...
a2 = a1; // конвертация, здесь даже не нужно знать как конветрить
Самое главное, что все это работает только на уровне компилятора.
А маза в том, что иногда хочется полной свободы во время runtime-а.
А маза в том, что иногда хочется полной свободы во время runtime-а.
Оставить комментарий
Dasar
> Т.е. если микроскопом не забивать гвоздей, а использовать все по назначению, то джава удобней.С этим - полностью согласен.
ps
Но вот в Java-е часто хочется иметь нормальную динамическую типизацию - при написании всяких проксей, адаптеров и т.д. Сейчас обычно это решается, через написание большого числа генераторов кода.