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

Именно так.

Crispy
Вообще чисто логически - если уж я могу на лету создавать свойство класса, почему не могу создать ему метод

Потому что через AddProperty() создаётся не свойство класса, а свойство объекта (если бы это было свойством класса, то оно бы появилось у ВСЕХ объектов данного класса - и существующих, и создаваемых позднее). А методы в фоксе это таки члены класса, потому и не создаются они "для объектов" - но для класса - вполне можно и создать и использовать - и именно в рантайме.

Crispy
Да не ведет нисколько! Точнее - не вел бы.

Кому как...

Crispy
Был бы рядовой факт. И рядовой программистский ништяк для каких-то иногда возникавших бы ситуаций.

Crispy
Вот создай сначала фокспро с такими возможностями - а потом и поговорим!

Ну в JS есть это - ты ж должен знать. И даже не для "иногда возникающих" - а для любых по сути ситуаций
Но это АБСОЛЮТНО другой подход. Возможно кому-то он "прост и понятен", но я бы сказал что это ну очень убого и коряво придумано...

Simple777
Дак в процедурном подходе тоже есть нечто похожее на объекты.

Нет. Объекты есть лишь в объектном подходе.
Если подняться совсем уж высоко и отбросить всякие "нюансы реализации", то что мы имеем? Процедурные языки в которых есть код (процедуры/функции) и данные - данные либо "локальны" (даже если они через параметры передаются между процедурами, они всё одно остаются "локальными"), либо "глобальны" - т.е. доступны всем и каждому.
Объектный подход просто вводит ещё один уровень - набор процедур и функций, плюс "общие" данные, с которыми эти процедуры и функции работают. Что это даёт?
Ну как минимум резкое снижение семантической сложности - одно дело 100500 совершенно равноправных процедур, при том в общем пространстве имён (т.е. доступные все одновременно) - и где какая описана, а то и переопределена (если язык позволяет) - поди ещё найди, и совсем другое 100 объектов с сотней методов, "логически" группирующих этот код.
Потом решение проблемы "глобальных переменных" - теперь объект хранит данные наряду с кодом, и никто "слева" доступа к этим данным не получает. Даже если проект пишут 2 разработчика, один из которых аккуратный и, скажем, при помощи префиксов/суффиксов и правил именования все 100500 процедур и столько же глобальных переменных содержит в идеальном порядке, то второй может оказаться дол... неаккуратным, и писать абы как - влезая с совершенно "левыми" процедурами в стройный ряд DbDoThis, DbDoThat... портя "чужие" глобальные переменные ну и в общем превращая структурированный код в кучу г*на. классы позволяют "изолировать" код так, что любые извращения этого "гения" не повлияют на фунционирование правильно написанного класса.
Поэтому смешно звучит фраза о

Simple777
Такшта за надежность - заслуженный кол.

Объектный подход как раз и позволяет путём "разделения и изолирования" многократно повысить надёжность ПО.
Проверить как "внутренне" взаимодействует между собой 10 методов да 10 "переменных" (полей класса), плюс как это всё реагирует на "внешние воздействия" (а их как правило существенно меньше - public функций, т.е. "точек входа" в наш класс) - и после объявить сей класс "чёрным ящиком" (т.е. он РАБОТАЕТ а как, уже не имеет значения для внешнего мира). Ну это существенно проще нежели проверять потенциальное взаимодействие 100500 процедур и глобальных переменных, каждая из которых видит (и может вызвать/изменить/использовать, хотя это может быть просто катастрофическим) всех остальных.

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

Igor Korolyov
Процедурные языки в которых есть код (процедуры/функции) и данные - данные либо "локальны" (даже если они через параметры передаются между процедурами, они всё одно остаются "локальными"), либо "глобальны" - т.е. доступны всем и каждому.

А на процедурных языках нельзя ли как то сгруппировать функции по *.prg, т.е. DO prg1.prg::func1 и DO prg2.prg::func1 ?

Я таких языков не знаю. В большинстве языков имена файлов с исходным текстом вообще никак на получаемый код не влияют.
P.S. Опять же а что делать с общими данными, которыми манипулирует сей набор процедур? Как их отделять от наборов данных других процедур? "Переменные модуля"? Ну вот в итоге и получается своего рода класс...





Исправлено 1 раз(а). Последнее : Igor Korolyov, 26.04.17 18:28

Кстати, есть такое:
DO func1 IN prg1.prg
бывает полезно для использования редких (специфических) процедур func1, чтобы не загромождать среду подключением всех процедур файла в
SET PROCEDURE TO prg1 ADDITIVE
Жалко нет такого же вызова func1 как функции, т.е. возвращать результат приходится где-то в видимой переменной, или в параметре процедуры. Немного некрасиво.

of63
Кстати, есть такое:
DO func1 IN prg1.prg
бывает полезно для использования редких (специфических) процедур func1, чтобы не загромождать среду подключением всех процедур файла в
SET PROCEDURE TO prg1 ADDITIVE

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

Что конкретно тебе мешает подключить prg1 как процедуру и вызвать ее функцию, если нужно вернуть значение?
Поясни, что ты подразумеваешь под абстрактным "загромождением среды подключением всех процедур"? В чем суть проблемы?



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

Чисто теоретический вопрос.
Вот допустим есть такая возможность как динамическая компиляция в какой-то среде разработки (речь не только о FoxPro). Понятный для человека код должен быть чем-то преобразован в понимаемый процессором код - трансляция. Потом скомпилирован чем-то. А это что-то, выполняющее вышеуказанные процессы, разных версий, допустим. Получается на одной машине с определенной версией ОС Ваша программа будет работать вот так, а на другой машине с такой же ОС - по-другому. Это "+" или "-"?

>Что конкретно тебе мешает подключить prg1 как процедуру и вызвать ее функцию, если нужно вернуть значение?
>Поясни, что ты подразумеваешь под абстрактным "загромождением среды подключением всех процедур"? В чем суть проблемы?

Если "подключить prg1 как процедуру" - это SET PROCEDURE TO prg1 ADDITIVE, то это подключает все процедуры модуля prg1.prg в область видимости. А мне конкрентно все не надо, а надо только func1, а всех остальных вообще не надо в области видимости, т.к. в этом модуле много других процедур, с именами, пересекающимися с моими штатными процедурами "фреймверка". Назвал эти неприятности от SET PROCEDURE TO prg1 ADDITIVE абстрактным словом "загромождение среды" [именами не нужных мне процедур]. Этот как народная "нелюбовь" к PUBLIC-переменным, типа "зачем де лишние общепроектные имена, если можно без них".

of63
Если "подключить prg1 как процедуру" - это SET PROCEDURE TO prg1 ADDITIVE, то это подключает все процедуры модуля prg1.prg в область видимости. А мне конкрентно все не надо, а надо только func1, а всех остальных вообще не надо в области видимости, т.к. в этом модуле много других процедур, с именами, пересекающимися с моими штатными процедурами "фреймверка".

Ok.
Положим, ты допускаешь пересекающиеся имена (!).

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

Или ты каким-то чудом можешь гарантировать, что внутри func1 вызовов "общих функций" не может быть?!

И еще вопрос - каким образом функции "фреймворка" доступны другим частям приложения?
Они прицеплены по SET PROCEDURE, находятся в одном из головных PRG, уже загруженных в память, или просто лежат как отдельные PRG?



Исправлено 1 раз(а). Последнее : akvvohinc, 27.04.17 10:54

> Предположим, что где-то во "фреймворке" и в prg1 есть одноименная функция - SomeFunc().
> Тогда каким образом ты обеспечиваешь вызов этой функции именно из фреймворка, а не из prg1, когда работает такой вызов:
> DO func1 IN prg1
Чудом вызвать SomeFunc из фреймверка (Ф) да, не получится. Задача скорее не испортить Ф подключениями сторонних PRG-шек. Сторонняя же ПРГшка как правило не знает о Ф, хотя может содержать одноименные с ним ф-ии, в этом случае в фоксе будет вызвана ф-ия из ПРГшки. Если ПРГшка знает о Ф, то она не будет содержать одноименные с ним ф-ии.

> каким образом функции "фреймворка" доступны другим частям приложения?
> Они прицеплены по SET PROCEDURE, находятся в одном из головных PRG, уже загруженных в память, или просто лежат как отдельные PRG?
- прицеплены по SET PROCEDURE
- также есть ПРГшки, которые вызываю по имени файла (внутри безымянные такие процедуры), они не подключены по SET PROCEDURE
- "находятся в одном из головных PRG" - и такие есть, лежат в модуле, содержащем READ EVENTS

of63
- прицеплены по SET PROCEDURE
- также есть ПРГшки, которые вызываю по имени файла (внутри безымянные такие процедуры), они не подключены по SET PROCEDURE
- "находятся в одном из головных PRG" - и такие есть, лежат в модуле, содержащем READ EVENTS

Тогда вызов
чреват теми же самыми проблемами, что и SET PROC TO prg1 ADDITIVE - одноименные c фреймфорком функции из prg1 будут иметь более высокий приоритет перед всеми функциями фреймворка, кроме тех, что цепляются по SET PROCEDURE.

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

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

> одноименные c фреймфорком (Ф) функции из prg1 будут иметь более высокий приоритет

мне так и надо, т.к.
"" Сторонняя же ПРГшка как правило не знает о Ф, хотя может содержать одноименные с ним ф-ии, в этом случае в фоксе будет вызвана ф-ия из ПРГшки. Если ПРГшка знает о Ф, то она не будет содержать одноименные с ним ф-ии.

> По этим причинам я "забыл" о вызовах DO ... IN ..., так как задачу - отслеживать уникальность имен всех функций в проекте - не ставлю, а на грабли обращения "не к тем функциям" наступать приходилось.
А у меня куча древних и сторонних "модулей"-пргшек, в которых надо что-то вызывать (ну окуклив как-то в его древнюю "среду"), с десятками внутренних подпрограмм с экзотическими именами, но и с упоминанием Ф. И полно просто внешних пргшек, нетривиальных, вещей в себе, с экраном, на основе класса-формы, который лежит в EXE... Иногда есть и SET PROC TO prg1 ADDITIVE с последующим RELEASE PROCEDURE prg1 по завершению процесса. Обычный винегрет из старой и новой программы.

Я к тому, что SET PROC TO prg1 ADDITIVE не всегда полезна. Опция DO..IN вполне годится для особых случаев.

of63
Если "подключить prg1 как процедуру" - это SET PROCEDURE TO prg1 ADDITIVE, то это подключает все процедуры модуля prg1.prg в область видимости. А мне конкрентно все не надо, а надо только func1, а всех остальных вообще не надо в области видимости, т.к. в этом модуле много других процедур, с именами, пересекающимися с моими штатными процедурами "фреймверка". Назвал эти неприятности от SET PROCEDURE TO prg1 ADDITIVE абстрактным словом "загромождение среды" [именами не нужных мне процедур]. Этот как народная "нелюбовь" к PUBLIC-переменным, типа "зачем де лишние общепроектные имена, если можно без них".

Вот ВСЕ эти проблемы/неудобства и решает ООП. Заменив prg на класс получаем "изоляцию внутренностей" - как "процедур" ставших методами класса, так и "глобальных переменных" ставших свойствами класса.
При том можно полноценно управлять видимостью и тех и других для "наружного" кода. Вот надо чтобы func1() и поле UserName были видимы (доступны для вызова/чтения/модификации), а getSalary() и Manager - НЕ были доступны - пожалуйста.

Как можно заменить
чем то приближённым к вызову функции?
Ведь с помощью DO..IN можно обращаться только к процедуре, не так ли?
А как к функции?:
типа
Local L_RESULT_INT
L_RESULT_INT = myprg.myfunc()



Исправлено 1 раз(а). Последнее : AdamAry, 27.04.17 14:14

AdamAry
Как можно заменить

DO..IN myprg.prg

чем то приближённым к вызову функции?
Ведь с помощью DO..IN можно обращаться только к процедуре, не так ли?
А как к функции?:
типа
Local L_RESULT_INT
L_RESULT_INT = myprg.myfunc()

В подавляющем большинстве случаев, на мой взгляд, в VFP удобнее пользоваться не модулями prg, а методами - формы или объектов. Практически все то же самое, ну за редкими исключениями, можно делать и методами. А работать с ними из объектов намного удобнее, чем с prg и его процедурами или функциями.
Единственное, что к сожалению не сделано в Фоксе - нельзя добавлять свои методы к объектам формы. Приходится придумывать всякие обходные пути. При этом биндить - на мой взгляд, все же не самый удобный. Я обычно предпочитаю "нелегальное" использование уже имеющихся методов объектов. Намного проще и удобнее.

Вообще само отсутствие возможности вставки методов в визуальные объекты, как мне кажется, тоже как-то связано с отсутствием возможности добавления метода в классы на лету, обсуждавшимся несколько ранее.





Исправлено 1 раз(а). Последнее : Crispy, 27.04.17 14:35

Чой-то криспу опять понесло незнамо-куда. Методы без проблем добавляются и в классы (визуальные или не визуальные - без разницы) и даже в "формы" (как своего рода sealed класс - т.е. класс не допускающий от себя наследования).
Естественно не "в объекты", и не во время работы программы

А так - если бы ещё в фоксе были статические методы, т.е. не требовалось сначала создавать экземпляр класса, а можно было писать прямо result = MyClass.Func1(param1,param2) где MyClass имя класса, а не ссылка на объект этого класса... Ну тогда надобности в "просто процедурах и функциях" не было бы вообще никакой

Обьекты, с методами - это замечательно, за исключением одной "маленькой" заковыки: при написании кода метода нельзя применять подпрограммы, годящиеся исключительно для этого метода. Приходится создавать дополнительные ничтожные "методы", или выносить код в те же ПРГшки, если код большой. А в остальном ... все хорошо.

Igor Korolyov
Чой-то криспу опять понесло незнамо-куда.

Поддерживаю

Crispy
Я обычно предпочитаю "нелегальное" использование уже имеющихся методов объектов. Намного проще и удобнее.

А это ещё как?

Берешь и пишешь в Click кнопки