» Вопросы по Embarcadero RAD Studio XE4

deks

Цитата:

with matching obj := TButton(Sender) do obj.Caption := 'ok';

Интересная конструкция. Немного запись страшновата, но ничего [more]так было бы прикольнее: with Sender matching obj as TButton do...ридабилити выше [/more] ... не знаю, я пытался на кислороде писать. Не пошло. Ну не чувствую я в нём дух Delphi. Сплошной C# с begin..end.

Месяц игрался и бросил это чудо. По мне уж так лучше на С# писать, чем на кислороде. Если натив, то Delphi-only.

deks

Цитата:

Нет, должно работать.

Не работает и не должно. Учим матчасть.

Добавлено:
Eternal_Shield

Цитата:

Ну не чувствую я в нём дух Delphi. Сплошной C# с begin..end

Абсолютно те же ощущения...

Цитата:

В Oxygene обнаружилась для похожих вариантов две конструкции

а в них можно явно добавить else-секцию ?

Добавлено:

Цитата:

В обоих случаях каст T() дает nil при невозможности каста.  

только в этих случаях (тогда это может разрушать целостность языка) или всегда (тогда это чревато ошибками, типа типичного в ява-программах NullReferenceException )

Добавлено:

Цитата:

> тайпкаст, централизованный в начале функции как absolute
Не ясно что имеется ввиду вообще. Разговор за begin инициализатор в методе чтоли?

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


Цитата:

Обобщенный тип:

Интересно, насколько это отличается по сути тот dyna-cast в C++ Builder

Можно немного по другому.


Код:
type
TCast = record
function Check<T: class>(Src: TObject; out Dst: T): Boolean; static; inline;
end;

....

class function TCast.Check<T>(Src: TObject; out Dst: T): boolean;
begin
Result := Src is T;
if Result then
TObject(Dst) := Src;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
btn: TButton;
begin
if TCast.Check(Sender, btn) then
btn.Caption := 'ok';
end;

valgreesh

Цитата:

Не работает и не должно

Разобрался, правда не должно. Дружно говорим спасибо COM за возможность в потомке НЕ РЕАЛИЗОВЫВАТЬ методы базового интерфейса. Нелогично, но почему то так принято..

COM - не объектное дерево. В нём нет понятия потомков.

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

Arioch1

В Оксигене T() всегда дает nil если каст не удался.

В случае опасений на nil reference, можно использовать colon operator. Подробнее про фичу: http://wiki.oxygenelanguage.com/en/Oxygene_by_Example_-_Colon_and_Null

Явно добавить секцию else нельзя.

Добавлено:

Цитата:

COM - не объектное дерево

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

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

А кому не надо платформенной зависимости - те делают на обычном interface, который поддерживает всякое наследование (и в реализации) и все что нужно, без нелогичных выкрутасов.

Arioch1,

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

Решения из Кислорода прикольные, однако очень непривычно выглядит/не очевидно и если нет возможности сделать else то уже не гуд.

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


Код:
procedure TForm1.Button1Click(Sender: TObject);
begin
if cast(Sender, TButton, var Btn) then
btn.Caption := 'ok';
end;

Цитата:

кому не надо платформенной зависимости - те делают на обычном interface,  который поддерживает всякое наследование

Об этом плакали столько, сколько сами интерфейсы были.
Поздно уже надеяться 15 лет спустя.

И если честно, никто не пробовал вносить этот отдельный тип. Смешивать объекты и интерфейсы и так не всегда просто, а новичкам просто крышу рвёт.
Представь Delphi построенную на трёх типах: классы, интерфейсы и компоненты (COM-интерфейсы). Не получилось ли бы еще хуже на практике ? уже не узнать.

Добавлено:

Цитата:

В случае опасений на nil reference, можно использовать colon operator

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

но как-то не по-Паскалевски. Одни грабли это уберёт, зато другие разложит. И не факт, что они будут лучше. больно мне это напоминает исправление оишбок абсолютным on-except-end

Добавлено:

Цитата:

2. var Btn - inplace объявление локальной переменной (в текущем блоке т.е. в блоке if) с авто выводом типа от типа параметра функции cast.

а кроме функции cast у этого какие-то еще применения будут ?
менять язык ради одной функции...
лучше уж tuples вводить


Код: procedure TForm1.Button1Click(Sender: TObject);
begin
if (const T = cast(Sender, TButton)).Result then
T.obj.Caption := 'ok';
end;

deks

Цитата:

А еще лучше - ввести специальный тип com interface

И тем самым окончательно всех запутать... Нынешняя ситуация является хорошим компромиссом.

Arioch1
valgreesh

Я имел ввиду наоборот, упростить. Проблема интерфейсов в дельфи в том, что изначально они делались под COM, но потом стали некоей самостоятельной сущностью! В результате скрестился еж с ужом)

Идея была развести понятия: вот тут - реализуем COM-интерфейс, и работаем по правилам COM но только на windows. А вот тут - просто интерфейс, он для всего языка на всех платформах! Ведь реально глупо следовать поведению COM на Android?!

Это как со строковыми типами: никто ж не ругал дельфи за AnsiString, WideString и тп. Каждому применению - свое!)) Хочешь универсальное - юзай String, но никто не запрещает пользовать специализированный тип для своих случаев)

Добавлено:

Цитата:

исправление оишбок абсолютным on-except-end

А по мне так ок! Хочется больше контроля? Это возможно: просто нужно сделать явную проверку на nil и обработать этот случай. А если реакции то никакой нету на else? Не - как в примере с TButton? Просто делаем свое дело, если можем. Вот тогда такой синтаксис лаконичнее и вполне читаем. Я б не отказался от такого в дельфи.

Цитата:

Это как со строковыми типами

то-то их больше нету :-D


Цитата:

что изначально они делались под COM

Нет. Если бы так - то они бы поддерживали тоьлко OLE типы данных и начинались бы не с TInterfacedObject, а с COM-cервера.


Цитата:

просто нужно сделать явную проверку на nil

Так можно и вообще исключения отменить- проверяй возврат и не забывай проверять.

Это же потеря инфомрации, вместо конкретного Typecast Exception по месту облома, будет джокер Nil Dereference Exception хрен знает где потом


Цитата:

Я б не отказался от такого в дельфи.

Как опция - да. Тоже не отказался бы. Как дополнительный сахар, но не как базовый механизм. Базовый механизм должен оставаться fail early

deks

Цитата:

Ведь реально глупо следовать поведению COM на Android?!

Не могу согласиться. COM - бинарный стандарт, от платформы он не зависит, и хорошо, что дельфийские интерфейсы именно такие т.к. обеспечивается беспроблемный интероп с другим нативным (ну конечно же с C++, и таки Objective C, да ) кодом. То есть, правильность решений принятых в Delphi 3 (именно тогда появились интерфейсы в дельфях) подтверждается сегодняшними реалиями.


Цитата:

Это как со строковыми типами: никто ж не ругал дельфи за AnsiString, WideString и тп. Каждому применению - свое!))

Со строками все сильно проще - для них нет понятий наследования и реализации. Это законченный тип, и путаницы тут нет. Более того, если вы хотели работать с юникодом, WideString был в общем-то безальтернативен. С интерфейсами было бы по другому. Нарушалась бы консистентность.

Цитата:

от платформы он не зависит,

Вы прямо как Форд.

Не зависит от любой платформы, если это - платформа x86


Цитата:

дельфийские интерфейсы именно такие

Нет. Если бы в них были ТОЛЬКО те типы и calling conventions, которые есть в MS COM - тогда да. Но в них же вся дельфийская чехарда... Так что дельфийские интерфейсы - это несовместимое ни с языками ни с платформами НАДМНОЖЕСТВО MS COM


Цитата:

и таки Objective C

Он на OS X и iOS поддерживает MS COM ? или хотя бы XP COM ?

Добавлено:
ах, да... по преобразованию типов. Тут много говорили про восхитительный Sugar и прозрачный mapping... Так вот что-то такое м.б. и могло бы быть идеальным механизмом для преобразования типов. Правда для этого нужна возможность рассматривать все типы как объекты.... на так на то и расширенный record helper.

Arioch1

Цитата:

Не зависит от любой платформы, если это - платформа x86

Казалось бы, причем тут x86? Что, нигде кроме x86 нельзя соблюсти формат vtbl?


Цитата:

Нет. Если бы в них были ТОЛЬКО те типы и calling conventions, которые есть в MS COM - тогда да. Но в них же вся дельфийская чехарда... Так что дельфийские интерфейсы - это несовместимое ни с языками ни с платформами НАДМНОЖЕСТВО MS COM

Обращаю внимание на то, что речь идет о бинарной совместимости интерфейсов. Это подразумевает только общий формат их описания, т.е. формат той самой vtbl. Почему я говорю именно об этом. Потому что имей дельфийские интерфейсы понятие наследования, в формат COM-интерфейсов им было бы не уложиться - vtbl была бы несовместима. А так конечно, дельфийские интерфейсы это больше чем чистые COM-интерфейсы т.к. в отличии от них могут вообще не иметь GUID (т.е. они его имеют конечно, но он нулевой).


Цитата:

Он на OS X и iOS поддерживает MS COM ? или хотя бы XP COM ?

О поддержке инфраструктуры речь не идет.

гляжу я в http://blogs.msdn.com/b/oldnewthing/archive/2004/02/05/68017.aspx и читаю "The Win32 COM calling convention" - т.е. COM очень даже учитывает как на конкрентой платформе должен оформляться вызов функции, очень даже.

Читаю дальше. "The layout of a COM object is made explicit in the header files" и не могу отделаться от ощущения, что HRESULT, STDMETHODCALLTYPE, void * - они все платформо-зависимые.

"The magic to all this is that since your function gets p as its first parameter"
Упс! размещение указателя на vtable первым параметром - это обязательное свойство COM-интерфейса.
А раз так, явно или неявно но частью COMa становится именно "как передать функции первым параметров указатель" на выбранной платформе. Без фиксированной calling convention на даннной платформе COM просот перестаёт быть стандартом.


Цитата:

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

Описание - это IDL. Его в двоичном коде вообще не существует.


Цитата:

т.е. формат той самой vtbl.

array [0 .. High(integer) div sizeof(pointer) ] of pointer

и это что, весь стандарт? не-а.


Цитата:

дельфийские интерфейсы именно такие т.к. обеспечивается беспроблемный интероп с другим нативным (ну конечно же с C++, и таки Objective C, да ) кодом.

Угу, да, так и вижу ObjC "беспроблемно" вызывающий метод интерфейса

Код: function GetInstance(const name: ShortString; const params: array of const): TPersistent; register;

У меня такой вопрос:
Можно ли реализовать при помощи бесплатных библиотек генерацию javascript прокси и маршаллинга XMLHTTP/JSON (из веб страницы в приложение) для произвольного Delphi класса, используя RTTI?
То есть получить Datasnap REST без необходимости покупать Enterprise версию Delphi? Из коробки?
Если есть такая библиотека, то может и демка есть?

Цитата:

javascript прокси

что это и зачем это в Дельфи ? (JSON не JS)


Цитата:

получить Datasnap REST

Именно DataSnap REST - вряд ли. А вообще REST - в известных статьях Datasnap Performance Analyzis лидировал REST-сервер на mORMot

Цитата:

что это и зачем это в Дельфи ? (JSON не JS)

затем, чтобы создать кросс-платформенный веб-интерфейс, скажем в UIWebView =
js/jquery/jquery.DataTables+ сгенерированные прокси/зеркальные классы отдельных классов/интерфейсов движка ->XMLHTTPREQUEST(в формате JSON- имя метода,параметры) -> socket/port listener движка-> RTTI +JSON ->проверка прав доступа-> вызов нативных методов -> СУБД.


Это реально, я делал такое под заказ на Datasnap, теже DataTables с сортировкой и фильтром на стороне дельфи сервера, ADO MS SQL, и т.д.
Но там меня не интересовала чистота лицензии, так что я использовал DataSnap REST, а там все уже сделано. Пост билд степ там как раз генерация проксирующих *.js + деплой шаблонов.

Очевидно, никаких проблем с FMX не будет(ибо кроме UIWebView ничего на форме не будет), и на Адрюшу порт будет очень простым. Очевидное же решение.


Цитата:

Именно DataSnap REST - вряд ли. А вообще REST - в известных статьях Datasnap Performance Analyzis лидировал REST-сервер на mORMot

Я использую уже mormot для SQLIte, но опыта REST-сервера, если он есть в мормоте, никакого. Может, демка какая есть.


Добавлено:

Цитата:

А раз так, явно или неявно но частью COMa становится именно "как передать функции первым параметров указатель" на выбранной платформе. Без фиксированной calling convention на даннной платформе COM просот перестаёт быть стандартом.

ну вот 7-zip фронтэнд для либы 7za.dll полностью соответсвует COM-vtable, и STDMETHODCALLTYPE (на Windows), методы возвращают integer aka HRESULT, хотя там не используются специфичные механизмы. А ведь он кросс-платформен. Если COM интерфейс и не является стандартом, то , наверное, это самое близкий к этому понятию способ interoperability ( в нативе ).

Цитата:

демка какая есть.

Цитата:

в известных статьях Datasnap Performance Analyzis

ну и он, кстати, пытался со SmartMobile Studio задружиться как раз для похожих сценариев

возвращаясь nextgen ARC:
я думаю многие используют TStringlist, и его метод AddObject(string,TObject) , засовывая вместо TObject простой указатель, или число. Дешево и сердито.
Вот только как новый компилятор на это посмотрит?

Arioch1
Ты похоже не понял о чем я говорю. Разумеется, COM это и формат vtbl и соглашения о вызовах и прочие детали. Но у меня нет задачи описывать COM. Я говорю о применяемом в дельфях формате vtbl, совместимом с COM, только для того, чтоб показать почему в интерфейсах нет наследования и почему это хорошее решение (нет наследования т.к. формат vtbl жестко задан, и это хорошее решение т.к. сильно облегчается интероп). В свою очередь я совсем не понимаю твоих речей о зависимости COM от платформы.

Добавлено:
AlekXL
Если судить по коду из XE4 - плохо посмотрит. Такой код придется переписывать.

System.pas
Времнные рекоммендации, писать так

Код:
if InitContext.OuterContext = nil then
begin
ExitProcess(ExitCode); //2004 system wait secondary thread
TerminateThread(GetCurrentThread)) //Without dos compatibility
end;
InitContext := InitContext.OuterContext^ //<-- exception if debug

Как правильно русифицировать rad studio XE4 . Сделал как написано:"... содержимое архива распаковать в каталог, прописанный в Library Path, либо в папку с проектом". Ни что не русифицировалось. Добрые люди подскажите.

ЗАЧЕМ?! Так работай.
Всё равно все справки, все подсказки, снимки экранов в интернете для IDE на английском.

pashenkoNP


Цитата:

Как правильно русифицировать rad studio XE4 . Сделал как написано:"... содержимое архива распаковать в каталог, прописанный в Library Path, либо в папку с проектом". Ни что не русифицировалось. Добрые люди подскажите.

Цитата:

ЗАЧЕМ?! Так работай.
Всё равно все справки, все подсказки, снимки экранов в интернете для IDE на английском.

+1 Abbyy Lingvo лучше поищи. Непонятные слова переводить. Так лучше будет, инфа 146%


Цитата:

я думаю многие используют TStringlist, и его метод AddObject(string,TObject) , засовывая вместо TObject простой указатель, или число. Дешево и сердито.
Вот только как новый компилятор на это посмотрит?

Цитата:

Если судить по коду из XE4 - плохо посмотрит. Такой код придется переписывать.

Если такой и много еще подобного придется переписывать для десктопа, то интересно, кто купит Delphi? А если не придется, то зачем вводить несовместимость между платформами? Они в эмбе отдают себе отчет, что делают?


Добавлено:
deks


Цитата:

Разобрался, правда не должно. Дружно говорим спасибо COM за возможность в потомке НЕ РЕАЛИЗОВЫВАТЬ методы базового интерфейса. Нелогично, но почему то так принято..

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

Код:
IParent=interface
end;

IChild=interface(IParent)
end;

сделай Use Debug DCUs и пройди это в CPU Window

сильно подозреваю тут тайпкаст с автоматическим вызовом QueryInterface

т.е. фактически трeтья строка компилируется как

Код: i_parent:=IParent(i_child);

Цитата:

сильно подозреваю тут тайпкаст с автоматическим вызовом QueryInterface

нет, там этого нет, да и с чего бы?

Я больше скажу, если даже явно сделать

Код:
TChild=class(TInterfacedObject, IChild,IParent)

Цитата:

Мне нет, и я не понимаю причин такой нелепой убогости такой архитектуры!

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

Добавлено:

Цитата:

Разобрался, правда не должно. Дружно говорим спасибо COM за возможность в потомке НЕ РЕАЛИЗОВЫВАТЬ методы базового интерфейса. Нелогично, но почему то так принято..

Добавлено:
[more] Это как раз очень логично и почему так принято - грамотно объясняется в книжке "Сущность технологии COM" (если не ошибаюсь).
Если кратко то интерфейс - это абстрактный протокол, который описывает только взаимодействие с объектом и не содержит детали его реализации. Возьмём класс X, реализующий некоторый функционал, класс X могут наследовать несколько других классов XA, XB, XC, в этом случае они наследуют и расширяют функционал родительского класса X, но никак его не замещают и не ограничивают, работает принцип подстановки Лисков, мы можем создать объект любого из дочерних классов, привести его к базовому и спокойно работать. Теперь возьмём интерфейс Y, описывающий некоторый абстрактный протокол, этот интерфейс могут реализовывать несколько классов YA, YB, YC, в этом случае они "наследуют" и реализовывают протокол взаимодействия и т.к. никакой базовой реализации у интерфейса нет - YA, YB, YC реализовывают протокол взаимодействия полностью сами, при этом теперь никем не гарантируется, что будет работать принцип подстановки Лисков, даже несмотря на схожесть сигнатур интерфейса, семантика его реализаций может быть различной (собственно в COM даже рекомендуется давать наименования методам с неопределённым смыслом, чтобы каждая реализация интерфейса могла их интерпретировать по своему). Тоже самое касается и наследования интерфейсов, должен соблюдаться не только сигнатурный контракт, но и гарантированно семантический, а для этого класс A, должен содержать реализацию интерфейсов и child и parent. [/more]

Добавлено:

Цитата:

Проблема интерфейсов в дельфи в том, что изначально они делались под COM, но потом стали некоей самостоятельной сущностью!

Проблем у интерфейсов в дельфи нет. Интерфейсы - это не просто фича MS COM, перекачивавшая в Delphi, это прежде всего идеология, это стиль компонентно-ориентированного программирования. И это очень удачная идея реализации понятия интерфейс, дающая такую гибкость, какая неведома в других языках (Джава, Шарп, С++), где интерфейсы фактически представляют из себя абстрактные классы, не имеющие каких либо особенностей.

ego666

Цитата:

TList выполняет ровно то, что в него заложено и никакой убогости в этом нет

Еще раз - TList<T> невозможно расширить так, чтобы изменить поведение - в этом имхо убогость его архитектуры. В .NET/Java/ObjC можно менять поведение, а в Дельфи нет, причем сделано искусственно и причины лично мне непонятны. Если нравится такая закрытость TList - ок, спор бессмысленен, это имхо.


Цитата:

Проблем у интерфейсов в дельфи нет

Проблему интерфейсов дельфи, которую тут обсуждаем - в особенностях реализации. На Win это обсуловлено спецификой поддержки COM. И непонятно чем это обсуловлено на OSX/iOS. Почем нельзя "достать" из объекта, который поддерживает IChild родительский интерфейс IParent? Мне такое поведение кажется нелогичным.

Нужно проверить как там с таким поведением у Oxygene и DWS )))

Цитата:

Вот только как новый компилятор на это посмотрит?

C укором. Нужно использовать TDictionary<string, T>.