Hello
what is better (code, speed, clarity, ...) to use:
1) function
Data := FUN(x)
- where
Function FUN(argument)
// do calculation
output := xx
Return Output

or
2) object
Data := FUN{x}:Output
- where
Class FUN
Protect xx as ...
Access Output class FUN
RETURN xx
Init (Argument) Class FUN
// do calculation
Return SELF

If We need only one output function is more natural but if an output should be more complex data (ex: string + number + logic) then object is easier to use.

Generally what is "better" or when is better to use FUN vs OBJ (Class)?

Rgds
Gregory

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Gregory,

the fastest code is using strong typed functions.

Using a class has other advantages, but speed is not one of them. And
since you are passing the parameter in the Init() method, strong typing
is not possible.

If you have more parameter, it could be an option to use a class,
assign the parameter values to strong types variables (assign) and then
call a strong typed method.

Wolfgang

Grzegorz R. wrote:

Hello
what is better (code, speed, clarity, ...) to use:
1) function
Data := FUN(x)
- where
Function FUN(argument)
// do calculation
output := xx
Return Output

or
2) object
Data := FUN{x}:Output
- where
Class FUN
Protect xx as ...
Access Output class FUN
RETURN xx
Init (Argument) Class FUN
// do calculation
Return SELF

If We need only one output function is more natural but if an output
should be more complex data (ex: string + number + logic) then object
is easier to use.

Generally what is "better" or when is better to use FUN vs OBJ
(Class)?

Rgds
Gregory

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thank You Wolfgang

You mean something like:

CLASS ItemPrice
PROTECT nItemPrice
PROTECT nItemDscnt
PROTECT nItemTax

ACCESS Price() CLASS ItemPrice
RETURN SELF:nItemPrice

ACCESS Dscnt() CLASS ItemPrice
RETURN SELF:nItemDscnt

ACCESS Tax() CLASS ItemPrice
RETURN SELF:nItemTax

METHOD Init() CLASS ItemPrice
// do nothing or default values
RETURN SELF

METHOD Calc(cCustID as STRING, cItemID as STRING, dDate AS DATE) CLASS ItemPrice
// do calculations & operations with In-Args
lFound := SEEK(....)
// get/calc data and store in class vars
IF lFound
nItemPrice := ...
nItemDscnt := ...
nItemTax := ...
ENDIF
RETURN lFound

// ====

// main routine
// intermediate data storage
MyItemData := ItemPrice{}
lFoundFlag := ItemPrice:Calc(CustID, ItemID, TODAY())

IF lFoundFlag
// data use
... := MyItemData:Price
... := MyItemData:Dscnt
... := MyItemData:Tax

//------------------------------

Do I think correct?

Gregory

poniedziałek, 18 stycznia 2021 o 13:59:05 UTC+1 Wolfgang Riedmann napisał(a):

Hi Gregory,

the fastest code is using strong typed functions.

Using a class has other advantages, but speed is not one of them. And
since you are passing the parameter in the Init() method, strong typing
is not possible.

If you have more parameter, it could be an option to use a class,
assign the parameter values to strong types variables (assign) and then
call a strong typed method.

Wolfgang
Grzegorz R. wrote:

Hello
what is better (code, speed, clarity, ...) to use:
1) function
Data := FUN(x)
- where
Function FUN(argument)
// do calculation
output := xx
Return Output

or
2) object
Data := FUN{x}:Output
- where
Class FUN
Protect xx as ...
Access Output class FUN
RETURN xx
Init (Argument) Class FUN
// do calculation
Return SELF

If We need only one output function is more natural but if an output should be more complex data (ex: string + number + logic) then object
is easier to use.

Generally what is "better" or when is better to use FUN vs OBJ
(Class)?

Rgds
Gregory

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Gregory,

yes, this is what I meant. But I would strong type the entire code:

ACCESS Price() as float pascal CLASS ItemPrice
RETURN SELF:nItemPrice

METHOD Calc(cCustID as STRING, cItemID as STRING, dDate AS DATE) ;
as logic pascal CLASS ItemPrice
// do calculations & operations with In-Args

Many classes in the .NET Framework work this manner.
Such code is not only fast and imposes correct parameter types, but is
also clear and easy to read even after years.

Wolfgang

Grzegorz R. wrote:

Thank You Wolfgang

You mean something like:

CLASS ItemPrice
PROTECT nItemPrice
PROTECT nItemDscnt
PROTECT nItemTax

ACCESS Price() CLASS ItemPrice
RETURN SELF:nItemPrice

ACCESS Dscnt() CLASS ItemPrice
RETURN SELF:nItemDscnt

ACCESS Tax() CLASS ItemPrice
RETURN SELF:nItemTax

METHOD Init() CLASS ItemPrice
// do nothing or default values
RETURN SELF

METHOD Calc(cCustID as STRING, cItemID as STRING, dDate AS DATE)
CLASS ItemPrice // do calculations & operations with In-Args
lFound := SEEK(....)
// get/calc data and store in class vars
IF lFound
nItemPrice := ...
nItemDscnt := ...
nItemTax := ...
ENDIF
RETURN lFound

// ====

// main routine
// intermediate data storage
MyItemData := ItemPrice{}
lFoundFlag := ItemPrice:Calc(CustID, ItemID, TODAY())

IF lFoundFlag
// data use
... := MyItemData:Price
... := MyItemData:Dscnt
... := MyItemData:Tax

//------------------------------

Do I think correct?

Gregory

poniedziałek, 18 stycznia 2021 o 13:59:05 UTC+1 Wolfgang Riedmann napisał(a):

Hi Gregory,

the fastest code is using strong typed functions.

Using a class has other advantages, but speed is not one of them.
And since you are passing the parameter in the Init() method,
strong typing is not possible.

If you have more parameter, it could be an option to use a class,
assign the parameter values to strong types variables (assign) and
then call a strong typed method.

Wolfgang
Grzegorz R. wrote:

Hello
what is better (code, speed, clarity, ...) to use:
1) function
Data := FUN(x)
- where
Function FUN(argument)
// do calculation
output := xx
Return Output

or
2) object
Data := FUN{x}:Output
- where
Class FUN
Protect xx as ...
Access Output class FUN
RETURN xx
Init (Argument) Class FUN
// do calculation
Return SELF

If We need only one output function is more natural but if an
output should be more complex data (ex: string + number + logic)
then object is easier to use.

Generally what is "better" or when is better to use FUN vs OBJ
(Class)?

Rgds
Gregory

--

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Gregory,

I'm working on my code that is nearly 20 years old when I was much
less advanced in object programming and there is a lot of mess to
clean-up. :( Last question concerning above example: If Init() does
nothing and my class is not inherited (ie no any SUPER:Init() ) must
it exist or may be omitted?

in VO you don't need an Init method, and I have many cases where I do
not added it intentionally.

But you should be aware that .NET needs a constructor (the Init method
in the .NET world), so you should add it for the case you like to
migrate your code later to X# (both the XPorter and the compiler have
an option to generate missing constructors).
Therefore I have started to add these methods to my VO code whenever I
touch a place where it is missing.

Wolfgang


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

wtorek, 19 stycznia 2021 o 07:43:56 UTC+1 Wolfgang Riedmann napisał(a):

Hi Gregory,

yes, this is what I meant. But I would strong type the entire code:

ACCESS Price() as float pascal CLASS ItemPrice
RETURN SELF:nItemPrice

METHOD Calc(cCustID as STRING, cItemID as STRING, dDate AS DATE) ;
as logic pascal CLASS ItemPrice
// do calculations & operations with In-Args
Many classes in the .NET Framework work this manner.
Such code is not only fast and imposes correct parameter types, but is
also clear and easy to read even after years.

Wolfgang
Grzegorz R. wrote:

Thank You Wolfgang

You mean something like:

CLASS ItemPrice
PROTECT nItemPrice
PROTECT nItemDscnt
PROTECT nItemTax

ACCESS Price() CLASS ItemPrice
RETURN SELF:nItemPrice

ACCESS Dscnt() CLASS ItemPrice
RETURN SELF:nItemDscnt

ACCESS Tax() CLASS ItemPrice
RETURN SELF:nItemTax

METHOD Init() CLASS ItemPrice
// do nothing or default values
RETURN SELF

METHOD Calc(cCustID as STRING, cItemID as STRING, dDate AS DATE)
CLASS ItemPrice // do calculations & operations with In-Args
lFound := SEEK(....)
// get/calc data and store in class vars
IF lFound
nItemPrice := ...
nItemDscnt := ...
nItemTax := ...
ENDIF
RETURN lFound

// ====

// main routine
// intermediate data storage
MyItemData := ItemPrice{}
lFoundFlag := ItemPrice:Calc(CustID, ItemID, TODAY())

IF lFoundFlag
// data use
... := MyItemData:Price
... := MyItemData:Dscnt
... := MyItemData:Tax

//------------------------------

Do I think correct?

Gregory

poniedziałek, 18 stycznia 2021 o 13:59:05 UTC+1 Wolfgang Riedmann napisał(a):

Hi Gregory,

the fastest code is using strong typed functions.

Using a class has other advantages, but speed is not one of them.
And since you are passing the parameter in the Init() method,
strong typing is not possible.

If you have more parameter, it could be an option to use a class,
assign the parameter values to strong types variables (assign) and
then call a strong typed method.

Wolfgang
Grzegorz R. wrote:

Hello
what is better (code, speed, clarity, ...) to use:
1) function
Data := FUN(x)
- where
Function FUN(argument)
// do calculation
output := xx
Return Output

or
2) object
Data := FUN{x}:Output
- where
Class FUN
Protect xx as ...
Access Output class FUN
RETURN xx
Init (Argument) Class FUN
// do calculation
Return SELF

If We need only one output function is more natural but if an
output should be more complex data (ex: string + number + logic)
then object is easier to use.

Generally what is "better" or when is better to use FUN vs OBJ (Class)?

Rgds
Gregory

--

--

Thank You,
I'm working on my code that is nearly 20 years old when I was much less advanced in object programming and there is a lot of mess to clean-up. :(
Last question concerning above example:
If Init() does nothing and my class is not inherited (ie no any SUPER:Init() ) must it exist or may be omitted?

Regards
Gregory

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)