Компоненты для Delphi-2

Вверх ↑

Форумы Новые пакетыКомпоненты для Delphi-2 ← Ctrl1 2 3 4 5 6 789 10 11 12 13 14 15 16Ctrl →

Этот топик читают: Гость

Ответов: 9906

Рейтинг: 351

#106: 2007-07-02 20:44:18 ЛС | профиль | цитата

Мне не показалось что "можно" звучит очень надежно.
GetTypeForPoint - это тоже входит в разряд можно

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#107: 2007-07-02 20:48:40 ЛС | профиль | цитата

пока нет примеров обратного - значит надежно.

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#108: 2007-07-02 20:56:07 ЛС | профиль | цитата

Dilma, ты так и не рассказал, что это за напряг: GetTypeForPoint

Про надежно
Меня жизнь другому учила: если нет примеров обратного, значит мало искал.
ОСОБЕННО, если это нововведение.
Многократно проверенное наблюдение.

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#109: 2007-07-02 22:38:01 ЛС | профиль | цитата

Galkov писал(а):

GetTypeForPoint

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

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#110: 2007-07-02 22:49:14 ЛС | профиль | цитата

Dilma писал(а):

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

И кто у нас на этот раз "компилятор"...

[size=-2]------ Добавлено в 22:49

Dilma писал(а):

нужно сделать нормальное задание типов точек по индексу типа. Так же как у св-тв

Вот это и есть нововведение.
Спорное причем.
Потому-что посылом к нему является не знание как сделать что-то, а наоборот: НЕзнание, как выйти из какой-то ситуации.
Сегодня не знаем, завтра знаем, а пути назад уже отрезаны...
Может быть.

Нельзя на основании "может быть" делать интерфейсные изменения...
Для меня - это просто основополагающая аксиома...

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#111: 2007-07-03 00:57:21 ЛС | профиль | цитата

Galkov писал(а):

И кто у нас на этот раз "компилятор"...

his файлу компилятор не нужен

Galkov писал(а):

Вот это и есть нововведение.
Спорное причем.

не спорное. Наличие 3х основных типов+bmp и arr вот это действительно спорный момент

[size=-2]------ Добавлено в 00:57
Предварительная версия доступна для скачивания

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#112: 2007-07-03 10:09:58 ЛС | профиль | цитата

Dilma писал(а):

his файлу компилятор не нужен

про his я догадался.
но в этом же пакете еще и dll есть, как мне показалось

Dilma писал(а):

не спорное. Наличие 3х основных типов+bmp и arr вот это действительно спорный момент

Спорное.
Есть элементы, не фиксирующие типа.
Теперь начнем им фиксировать.
Появится понятие "синтаксической" ошибки, типа: нет, так писать нельзя.
И появятся опять соообщения: "был HiAsm для всех, а теперь для продвинутых". И они уже будут иметь основания, в отличие от предыдущих.

Вопрос - зачем

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

Хорошо еще, если просто трата...

Меня больше настораживает, что мы окажемся с замороченным интерфейсом, и обратного пути не будет. Или он будет очень сложен.
Есть у элемента IndexToChanel св-во Data
Во-первых, это какой же тип мы должны назначать при Data=NUL
И пусть подключена верхняя точка и с нее всегда идет String.
Оппа, а пользователь зыбыл что Data = real(1.0). И что характерно - и не надо до этого ему было помнить.
Заморочка ведь.
Именно ее я называю пляской в бубном. Работает не так раньше и требует дополнительного напряга от пользователя.

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

Вообще, если присмотреться к использованию linked, то получится что это просто прогноз для block.Empty до создания этого блока. И зачем все это, если на втором проходе и так будет все ясно напрямую без прогнозов...

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

Создали в тот момент, когда сказали: ой, с многопроходностью есть проблемы, отложим это на потом.
И из-за этого "потом" все и проблемы
Понятно что мало ресурсов, но именно поэтому не следует самому себе создавать трудности.
Можно не беспокоиться, они и сами возникнут.

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

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#113: 2007-07-03 10:51:28 ЛС | профиль | цитата

Galkov, вот чесно не понимаю о чем речь-то... Какая синтаксическая ошибка

Где-то написано, что среда проверяет валидность соединенных точек? Или компонент обязан это делать? Ну не желаете вы пользоваться автоматической конвертацией пишите в стиле:

 if(typeof(_data) = 1)
    event(onEvent, _data)
  else if(typeof(_data) = 2)
    event(onEvent, 'Str2Int(' && _data && ')')
  else if(typeof(_data) = 3)
    event(onEvent, 'Round(' && _data && ')')
  else
    event(onEvent, 0)
  end

кто мешает-то так делать не понимаю? или если совсем не хочется заморачиваться с типами всегда можно вернуться к TData:

    event(onEvent, 'MakeData(' && _data && ')')[/code]
перекрываем MakeData для всех мыслемых типов и жизнь будет прекрасна.

В связи с этим я никак не могу понять, почему расширение возможностей, позволяющих делать "и так и так" расценивается как усложнение интерфейса для пользователя... Вроде не раз уже говорилось, как разработчик спроектирует свой пакет настолько сложным или простым будет его использование. Пока же мне понятны будут только [u]конкретные[/u] примеры ошибочной конвертации, решить которые невозможно.

[size=-2]------ Добавлено в 10:51 [/size]
[quote=Galkov]про his я догадался.
но в этом же пакете еще и dll есть, как мне показалось[/quote]
пока Delphi. С mingw только ознакамливаюсь.

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#114: 2007-07-03 10:52:25 ЛС | профиль | цитата

Это разве не конкретный пример

Galkov писал(а):

Есть у элемента IndexToChanel св-во Data
Во-первых, это какой же тип мы должны назначать при Data=NUL
И пусть подключена верхняя точка и с нее всегда идет String.
Оппа, а пользователь зыбыл что Data = real(1.0). И что характерно - и не надо до этого ему было помнить.
Заморочка ведь.

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

карма: 9

Ответов: 2125

Рейтинг: 159

#115: 2007-07-03 10:55:03 ЛС | профиль | цитата

Я давно предлагал ввести тип точек. Там, где тип не важен - использовать variant, причём сначала в Design-Time, а уж потом, если мы не смогли определить/ограничить тип при генерации кода, в Run-Time. Однако, придётся сделать в скрипте объявления входных/выходных данных для точек (типизированные аргументы и результат) и разрешить в скрипте объявлять несколько точек с одинаковым именем, но разными типами аргументов, так сказать overload

[size=-2]------ Добавлено в 10:55
Опять-же, решается проблема конвертации типов, если типы точек заданы жёстко.

карма: 1

Ответов: 9906

Рейтинг: 351

#116: 2007-07-03 10:55:42 ЛС | профиль | цитата

Dilma писал(а):

пока Delphi. С mingw только ознакамливаюсь.

ну для одного пакета все проекты разве не одним компилятором пользуются

Т.е., непонятно, как одним компилятором воспользуются his и dll

карма: 9

Ответов: 2125

Рейтинг: 159

#117: 2007-07-03 10:58:14 ЛС | профиль | цитата

При желании можно разрешить иметь точкам несколько входных/выходных данных, надо лишь придумать как конвертировать разные кортежи данных, например объявлением оператора конвертации одного кортежа в другой (в простейшем случае кортежи из одного аргумента, например int2str).

карма: 1

Ответов: 9906

Рейтинг: 351

#118: 2007-07-03 11:01:58 ЛС | профиль | цитата

tsdima писал(а):

Опять-же, решается проблема конвертации типов, если типы точек заданы жёстко

Очень много можно решить, если переложить с больной головы на здоровую.
Сказал: можно только так и так. И больше никак.
И нет проблемы - пусть пользователь сам решает какой тип данных проходит через HUB (ChangeMon и т.п..)
Всегда можно потом ему сказать: сам же дурак написал не правильно (не оптимально, и т.п..)

Но не поворачивается у меня язык называть это решением проблемы

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#119: 2007-07-03 11:33:02 ЛС | профиль | цитата

Galkov писал(а):

Это разве не конкретный пример

решение писал уже:

println(saved_data, ' := makedata(', _data_, ');')[/code]

если не устраивает делаем св-во data и пишем в хелпе маленьким шрифтом для тех, кому не пофигу на качество их схемы:
[quote=Help]Если на левые точки вы всегда подаете данные одного типа, то рекомендуется явно указывать тип данных в св-ве data[/quote]
и модифицируем код:

 if( typeof(Data) = 1)
    lang(saved_data:int)
  else if( typeof(Data) = 2)
    lang(saved_data:str)
  else if( typeof(Data) = 3)
    lang(saved_data:real)
  end
...
  println(saved_data, ' := ', [e_int|e_str|e_real](_data_), ';')
никаких проблем. И все зависит только от степени ленивости разработчика элемента и уровня пофигизма пользователя. 

[quote=Galkov]Т.е., непонятно, как одним компилятором воспользуются his и dll[/quote]
никак. В одном случае ошибку компиляции получим в другом *.dll с исходным кодом проекта... Тут пока решения никакого не найдено.

[size=-2]------ Добавлено в 11:33 [/size]
=== FTCG ===
[tab] Между тем доделал последний оператор цепочки: ручное задание подтипа. Синтаксис:
<expression> @ <data type>[/code]

применяется так:

func CurDir()
  return('GetCurrentDir' @ str)
end

...

func doStrCat
  ecent(onStrCat, (Str1 & Str2) @ str)
end

пока писал, понял, что и эти оба примера можно упростить, если автоматически назначать тип выходных данных равным типу соответствующей Var или Event точки. Тогда ручная работа с типами через e_xxx и @ понадобится совсем уж в очень редких случаях.

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#120: 2007-07-03 11:57:19 ЛС | профиль | цитата

Dilma, вопрос же не в том, что чего-то стало нельзя сделать принципиально

А в том, что для этого мы теперь наезжаем на пользователя.

Dilma писал(а):

если не устраивает делаем св-во data и пишем в хелпе маленьким шрифтом для тех, кому не пофигу на качество их схемы:

help писал(а):

Если на левые точки вы всегда подаете данные одного типа, то рекомендуется явно указывать тип данных в св-ве data

((если неустраивает - это было просто введение вариантного типа в коды, насколько я понял))

Вот я считаю, что мы тоже самое качество можем сделать БЕЗ этих наездов.
Вот ты считаешь ноборот - чтобы достигнуть качества надо наехать.
Аргументов к этому наоборот, кроме "не спорное" не приводишь.

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

Меня удивляет одна вещь. Вроде согласились: многопроходность может дать значительно более качественный продукт.
За каким тогда лядом тратить свои мозги и время, чтобы сделать СНАЧАЛА менее качественный, а потом - более

Именно это является причиной огорчения. Ну ленивый я, что бы делать работу 2 раза.
А на самом деле - больше. Возможны побочные явления, устранять которые на втором этапе это тоже не подарок

Это если он будет... А то можно так все силы на гудок и потратить...

карма: 9

Форумы Новые пакетыКомпоненты для Delphi-2 ← Ctrl1 2 3 4 5 6 789 10 11 12 13 14 15 16Ctrl →


Сообщение ...
Прикрепленные файлы (файлы не залиты)