Ну, я тоже начинал в 80-х с Наири-С

Мы здесь просто выражаем свои мнения, даем советы (и не факт что на 100% верные), делимся опытом.
Так что воля каждого принимать это все во внимание или нет.
Я вот продолжаю находить здесь что-то новое и полезное.

Меня тут недавно попросили внести изменения в мой же проект которому уже почти 20 лет.
Так считай над проектом работали два разных человека.
Вот тебе и командная работа.

Цитата:

Так считай над проектом работали два разных человека.

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

Как стандарт использую названиях полей:
- для таблиц справочников поле кода - ID, Название - Name
- для поля ссылки на справочник - имя таблицы справочника

Фреймворк - автоматом генерирует сначала Left Join, а потом в гридах форм комбобокс

Еще название поля Parent. Это ссылка на Парента для ID.



Исправлено 1 раз(а). Последнее : Ydin, 21.03.23 19:31

akvvohinc

of63
А как ты относишься к такому упрощению

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

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

С массивами есть и плюсы, по сравнению с курсором:
- можно записывать в ячейки значения произвольного типа, (и длины, если речь о типе "Цэ")
- можно записывать в ячейки и обьекты, тем самым немного превращая таблицу ранга 2 в многоранговую таблицу (типа, в элемент массива можно записать обьект, содержащий тоже массив(ы))
- не требует сохранения SELECT-а (кстати SELECT * FROM ... INTO ARRAY A - (не требует сохранения SELECT до и после операции)
- и проще создается и заполняется в случае, когда к похожести на курсор нет показаний... просто набор строк. Я для однострочного (в кодесе) наполнения написал подпрограмму (ADDMASS), которая, при определенных параметрах вызова делает операции: очистка, добавление, возврат размера (в строках...)

() доб. Именно, для передачи/приема обьекта через курсор (мемо-поле) пришлось запилить какой-то стандартный преобразователь "туда-в-сюда", оказался удобным и простым -JSON, демократичный "стандарт". Конечно, все типы - это строки, для фоксиста это неудобно. Немного приукрасил для нужд (дата, число)

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

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

Тоже упрощал общение с SQL-сленгом (фоксовым и не), пока есть такое

() мтк кнопка code и кнопка спойолер должна сработать негласно, или спросить юзера "не за спойрелить ли?"

() Для этого родил понятие "копировщик" (oCOPY(m.o)) обьекта,
а не
m.x = m.o
(вы знаете, что это не клонирование обьекта... надеюсь)



Исправлено 9 раз(а). Последнее : of63, 21.03.23 22:10

Цитата:

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

Ты привел пример массива:
iМатрешкиЦвет
iМатрешкиКод
iМатрешкиВес

А я и написал - "для такого случая я бы просто создал курсор, а не массив".

Цитата:

С массивами есть и плюсы, по сравнению с курсором

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

of63
подпрограмму (ADDMASS), которая, при определенных параметрах вызова делает операции: очистка, добавление, возврат размера (в строках...)

А для курсора для всего этого и писать ничего не нужно.

Цитата:

возврат размера (в строках...)

Вроде определение размерностей массива не требует написания UDF.

of63
- можно записывать в ячейки и обьекты

Наверно всё же не сам объект, а ссылку на него.

про последнее замечание - да, можно записать и просто ссылку на обьект, а можно и заморочяться на предмет создания его клона

() про обьекты в фокс, и в других ЯП, типа См, Серега, мы с тобой найдем ОЯ

Ты слышал про "счетчик ссылок" на "обьект" в среде фокса, про его контроль над обьектными переменными?



Исправлено 2 раз(а). Последнее : of63, 21.03.23 22:18

Цитата:

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

Что ты называешь клоном объекта?

Цитата:

Ты слышал про "счетчик ссылок" на "обьект" в среде фокса, про его контроль над обьектными переменными?

Краем уха.



Исправлено 1 раз(а). Последнее : akvvohinc, 22.03.23 03:15

Это хор. Важнейшая деталь в использовании (в понимании) обьекта в фоксе, да и в Си (в Си - это просто адрес, фокс же "отслеживает" использование, этого адреса в подпрограммах, и при обнулении "счетчика использования" очищает (удаляет из памяти) этот обьект, это большая помощь в с его стороны программировании с использованием "обьектов"). Фрагментация памяти - тоже хорошая головная боль у програмеров, в фоксе мы этим не болеем...

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

> Что ты называешь клоном объекта?
ссылка на обьект это:
m.o = CREATEOBJECT("Empty") && обьект
m.x = m.o && это ССЫЛКА на обьект, не клон

другой пример
m.o = CREATEOBJECT(@Empty") && обьект
m.x = oCOPY(m.o) && эта подпрограмма делает CREATEOBJECT("Empty") и наполняет его свойствами обекта m.o
это клон



Исправлено 5 раз(а). Последнее : of63, 22.03.23 17:11

of63
ссылка на обьект это:
m.o = CREATEOBJECT("Empty") && обьект
m.x = m.o && это ССЫЛКА на обьект, не клон

другой пример
m.o = CREATEOBJECT("Empty") && обьект
m.x = oCOPY(m.o) && эта подпрограмма делает CREATEOBJECT("Empty") и наполняет его свойствами объекта m.o
это клон

Ну уж нет.

1) В первом случае обе переменные - O и X - являются ссылками на один и тот же объект.
То есть они обе хранят одно и то же значение - адрес одного и того же объекта!
И ты можешь это легко проверить обычным сравнением:

? m.X == m.O   && .T.

2) Во втором случае переменная O является ссылкой на первый объект, а переменная X является ссылкой на второй объект, являющийся "клоном" первого.

? m.X == m.O   && .F.

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

А поэтому тему одного из озвученных преимуществ массива считаю по-прежнему не раскрытой

of63
можно записывать в ячейки и объекты

Ну, или оно должно звучать иначе:
можно записывать в ячейки и ссылки на объекты



Исправлено 2 раз(а). Последнее : akvvohinc, 22.03.23 18:58

1) В первом случае обе переменные - O и X - являются ссылками на один и тот же объект.
То есть они обе хранят одно и то же значение - адрес одного и того же объекта!
И ты можешь это легко проверить обычным сравнением:
? X == O && .T.

2) Во втором случае переменная O является ссылкой на первый объект, а переменная X является ссылкой на второй объект, являющийся "клоном" первого.
? X == O && .F.

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

А поэтому тему одного из озвученных преимуществ массива считаю по-прежнему не раскрытой.

> Понял вопрос так - "массив - это как курсор, в курсор я сохранить обьект не могу, а оппонент говорит, что в массив это можно"
Примерно ты прав - обьект сохранит в ячейку курсора невозможно. Я про это и говор.ю - что сохранить. В ячейку массива можно сохранить ссылку на обьект, и потом ее прочитать и использовать (если обьект жив), в ячейку курсора же нельзя сохранить ссылку на обьект ни под каимм видом, ссылка на обьект не имеет типа (тип "О", но это ни о чем)...

То, что можно (если обьект простой) сохранить и восстановить его через Мемо-поле (ЖиСоном)Ю то это "клонирование"...

> одного из озвученных преимуществ массива
если ты об этом одном... )

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



Исправлено 1 раз(а). Последнее : of63, 22.03.23 19:09

Цитата:

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

В принципе верно.

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

Когда-то (ещё в ДОСе) я сам дописывал необходимые мне функции для Фокса с помощью пакета LCK (Library Construction Kit).
Создавать FLL-файлы не приходилось, но люди-то пишут.

Интересно, что по какой-то причине сами разработчики решили исключить сохранение переменных, содержащих ссылки, из обработки команд SAVE TO и RESTORE FROM:
Object type variables cannot be saved to a variable file or memo field.



Исправлено 1 раз(а). Последнее : akvvohinc, 22.03.23 20:04

of63
> Что ты называешь клоном объекта?
ссылка на обьект это:
m.o = CREATEOBJECT("Empty") && обьект
m.x = m.o && это ССЫЛКА на обьект, не клон

другой пример
m.o = CREATEOBJECT(@Empty") && обьект
m.x = oCOPY(m.o) && эта подпрограмма делает CREATEOBJECT("Empty") и наполняет его свойствами обекта m.o
это клон

Это не клон. Это копия свойств объекта. А использованный тобой способ "клонирования" называется подгонкой результата с помощью частного случая.

А клон тогда что такое? Как сделать клон обьекта в твоей терминологии )

() не спускаемся на некий "запрет клонирования квантовых обьектов", шутка ( ru.wikipedia.org )



Исправлено 2 раз(а). Последнее : of63, 22.03.23 20:11

akvvohinc
Но уверен, что умельцы найдут способ получать адреса объектов в виде фоксовых строк (чисел) и сохранять в таком виде куда угодно.

Не найдут.

Цитата:

Ну, и обратная операция не должна быть сложнее.

Ибо вот эта самая обратная операция бессмысленна. Ссылка на объект есть адрес в ОПЕРАТИВНОЙ памяти компа. Чтение из поля таблицы этого адреса в общем случае никак не создаст объект, ссылка на который сохранялась. Особенно в системе, в которой этот самый адрес постоянно плавает/меняется менеджером памяти и вычисляется непосредственно перед использованием этой ссылки. Вспомни, в LCK перед использованием всяких штук надо было сначала получить адрес этих штук по их хендлеру.

Серега, мы не о таком буквальном смысле обьекта (как ссылка на пддрес/область в оперативной памяти) имели ввиду, ну... я имел... Я имел ввижу обьек в фоксовом смсле, которые можно копировать, читать..., но нельзя получить "адрес" в си/ассемблерном смысле, его нет...

> Но уверен, что умельцы найдут способ получать адреса объектов в виде фоксовых строк (чисел) и сохранять в таком виде куда угодно.
Не найдут.

Есть еще в ЯП фокса указатель - улитка "@"

> в виде фоксовых строк (чисел) и сохранять в таком виде куда угодно.
() естественно, это лежит в памяти компа, по какому-то адресу, в открытом виде, как у всех программ.



Исправлено 2 раз(а). Последнее : of63, 22.03.23 20:25

Цитата:

Ссылка на объект есть адрес в ОПЕРАТИВНОЙ памяти компа. Чтение из поля таблицы этого адреса в общем случае никак не создаст объект, ссылка на который сохранялась.

Речь шла о другом:
1) объект существует;
2) ссылка на него может храниться в скалярной переменной;
3) эту же ссылку можно "положить" в элемент массива, свойство чего-то там...
4) но нельзя сохранить ссылку в поле курсора (таблицы).

Цитата:

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

Я уже не помню всё настолько хорошо.

Пришлось посмотреть исходники (один из них - под спойлером), и, насколько я успел вспомнить и понять, хендлеры использовались лишь для доступа к значениям строковых переменных (если вести речь только о переменных).
То есть цепочка получается такая - ссылка на переменную, которую принимает твоя функция - это лишь ссылка на то место (структуру), где лежит описание переменной, одним из полей которого (parm->p[1].val.EV_HANDLE) является адрес, где находится собственно значение.
И изменение адреса, где лежит собственно значение, не обязательно скажется на адресе самой переменной.

И это при желании можно было бы проверить на досовском Фоксе, если компилятор Watcom C и сейчас будет работать на какой-то системе.

ssa
Не найдут.

Если адрес действительно меняется, то найти способ его извлечь всё равно можно, хоть и бессмысленно.

Думаю, я и сам мог бы это сделать при наличии пакета, аналогичного Library Construction Kit, и инструкции пользователя.
Вот одна из наших функций, использовавшаяся в некоторых случаях вместо родной SEEK() (была переделана из обычного PRG для ускорения работы - тогда это было актуально - расчеты шли всю ночь):
Любой, кто сталкивался с Си и знает Фокс (функция _Evaluate() может выполнять родные команды Фокса), разберется в коде.

Но даже если ссылку на объект сохранить в файле/поле, и даже если адрес объекта не изменится, то без доработки Фокса (может, Чен?) это всё равно бессмысленно - ведь если ссылка на объект не будет параллельно храниться и там, где требуется Фоксу (в переменной и проч.), то объект самоликвидируется.



[i]Исправлено 5 раз(а). Последнее : akvvohinc, 23.03.23 05:19

> Но даже если ссылку на объект сохранить в файле/поле, и даже если адрес объекта не изменится,
Сергей, ты не прав )

Доб
Какой в ж. "адрес" "если ссылку на объект сохранить в файле/поле"

> и даже если адрес объекта не изменится
как он может измениться, в ЯП?

> может, Чен?)
Чен тут не при делах, дело в понимании программирования на чужих ЯП... просто, надо их понять



Исправлено 2 раз(а). Последнее : of63, 24.03.23 22:27

of63
> и даже если адрес объекта не изменится
как он может измениться, в ЯП?

Молча. Ты вообще хоть как-то знакомился с устройством фокса внутри?
Если думаешь, что фокс работает с переменными как С, Pascal и иже с ними компилируемые языки, то очень сильно ошибаешься.

ssa

of63
> и даже если адрес объекта не изменится
как он может измениться, в ЯП?

Молча. Ты вообще хоть как-то знакомился с устройством фокса внутри?
Если думаешь, что фокс работает с переменными как С, Pascal и иже с ними компилируемые языки, то очень сильно ошибаешься.

Куда уж нам уж Епусь на нем много лет.
> Ты вообще хоть как-то знакомился с устройством фокса внутри?
Не интригуй, просто говори, то, чего мы еще не знаем.

Если про систематическую "очистку памяти" - это не важно... (хотя важно, но не очень... ) )

()() хоть как-то знакомился с устройством фокса внутри?
Серега! И снаружи, и внснутри, как с бабой...

З_аодно, раз ты знаешь про внутренности фокса, расскажи, как устроена память ОС , когда мы начинаем плодить/уничтожать "обьекты/переменные", выскажи свою версию, как надо было делать, и как не надо... )... Это про "фокс"... Ребята сделали рабочий "продукт", все работает... и не надо гнать, что "я мог бы сделать более збс".. ну сделай, это делает пока только Чен...



Исправлено 2 раз(а). Последнее : of63, 25.03.23 02:08