[BR_forum] OOP and BR!
Posted: Wed May 27, 2009 1:22 pm
Sure, but why not just use the standard syntax used in other languages:
Def fnSomething(a1$,b1$;optional$)
dim local X$
dim local Y$
dim local index
for index=1 to 5
! do something
next index
...
fnend
Of if there's a problem with the word DIM, how about just doing it the way VB does it (drop the word dim, just use local to dim something locally).
Def fnSomething(a1$,b1$;optional$)
local X$
local Y$
local index
for index=1 to 5
! do something
next index
...
fnend
On Wed, May 27, 2009 at 2:20 PM, George Tisdale <GTISDALE@tisdalecpa.com (GTISDALE@tisdalecpa.com)> wrote:
Def fnSomething(a1$,b1$;optional$)
dim local X$
dim local Y$
dim local index
for index=1 to 5
! do something
next index
...
fnend
Of if there's a problem with the word DIM, how about just doing it the way VB does it (drop the word dim, just use local to dim something locally).
Def fnSomething(a1$,b1$;optional$)
local X$
local Y$
local index
for index=1 to 5
! do something
next index
...
fnend
On Wed, May 27, 2009 at 2:20 PM, George Tisdale <GTISDALE@tisdalecpa.com (GTISDALE@tisdalecpa.com)> wrote:
Good point. Thinking out loud here, if it were possible to somehow refer to a named list of local variables in the function def, rather than listing them all out would that mitigate them problem (I have no idea whether this is possible at all of course)? Something like
Def library FNSOMETHING(a1$,a2$,a,b,c;dim(LISTNAME))
Do something
Do something
End def
DIM LISTNAME:
Listdim _A$*25
Listdim _B$*30
Listdim Mat AB$(5)*20
END varLIST
And all parameters in the named list were set to null and added to the local stack when FNSOMETHING were called. Would that make it easier to read, fit within the line length constraints? The dim(listname) would always have to be after the semicolon and never referred to by the call.
George L. Tisdale, CPA
Tisdale CPA
75 Junction Square Drive
Concord, MA 01742
(978) 369-5585
From: br_forum-bounces@ads.net (br_forum-bounces@ads.net) [mailto:br_forum-bounces@ads.net (br_forum-bounces@ads.net)] On Behalf Of John Bowman
Sent: Wednesday, May 27, 2009 2:56 PM
To: 'Business Rules Forum'
Subject: Re: [BR_forum] OOP and BR!
And there are limits to the length of a line… this limits the name lengths/number of variables that you can have defined within the scope of a function. That’s another problem with this being the only way to make variables within the scope of a function. And as was pointed out earlier, in recursive functions EVERY variable used must be in the def statement. Let’s hope they use small variables like O and F and not Payee_Name_Last$ and Account_Balance$.
-john
From: br_forum-bounces@ads.net (br_forum-bounces@ads.net) [mailto:br_forum-bounces@ads.net (br_forum-bounces@ads.net)] On Behalf Of George Tisdale
Sent: Wednesday, May 27, 2009 1:45 PM
To: Business Rules Forum
Subject: Re: [BR_forum] OOP and BR!
I don’t think I see the problem. If the “local” variables are all optional after the semi-colon and therefore not referenced in the call adding a variable/parameter to be passed is as simple as adding it either before or after the semi-colon.
If added before the semicolon then all calls must reference the parameter or you will get an error on the call. If added immediately after the semi-colon then only those calls that need to pass the parameter need to be changed. All of the trailing optional parameters are left off the call and default to NULL.
George L. Tisdale, CPA
Tisdale CPA
75 Junction Square Drive
Concord, MA 01742
(978) 369-5585
From: br_forum-bounces@ads.net (br_forum-bounces@ads.net) [mailto:br_forum-bounces@ads.net (br_forum-bounces@ads.net)] On Behalf Of John Bowman
Sent: Wednesday, May 27, 2009 12:07 PM
To: Business Rules Forum
Subject: Re: [BR_forum] OOP and BR!
but the functions get too long so quickly and with no overloading going back and adding a variable that needs to be passed could be a real p.i.t.a. after you've put a huge list of scope-variables.
I don't understand what you mean by documenting the parameters? i just comments at the top of the function to do this.
On Wed, May 27, 2009 at 11:35 AM, Gordon Dye <gordon.dye@ads.net (gordon.dye@ads.net)> wrote:
I realize it would be useful to have a way to declare local variables. However, in the final analysis optional parameters can be used, with proper naming conventions, for local variables. And functionally nothing is lacking because all such variables are created fresh on the stack each time a function is called. What is needed, in my opinion, is some way to document parameters better than what is presently available.
gordon
On Wed, May 27, 2009 at 8:39 AM, John Bowman <gothnerd@gmail.com (gothnerd@gmail.com)> wrote:
Kenvin - today doing a recursive function - I got to apply your tip (below).
Thank you!
-john
-----Original Message-----
From: br_forum-bounces@ads.net (br_forum-bounces@ads.net) [mailto:br_forum-bounces@ads.net (br_forum-bounces@ads.net)] On Behalf Of
Kevin Klappstein
Sent: Wednesday, May 20, 2009 4:14 PM
To: Business Rules Forum
Subject: Re: [BR_forum] OOP and BR!
Another way to fake OOP (or more specifically variable scope) is to put
any variable that needs to remain in scope for the duration of a
function into the parameter list. This is the only place where BR has
proper variable scope, and will allow for the same function to be run
while the previous copy remains uncorrupted. This does cause problems in
that it makes your function calls look like a dog's breakfast, and you
can't cheat with using global variables between functions any more, but
it will work. We use this technique any time we need to use recursion.
Kevin Klappstein
Western Canadian Software
kevin@wcs.ab.ca (kevin@wcs.ab.ca)
_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net
_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net