[BR_forum] OOP and BR!

More advanced topics discussed.

Moderators: Susan Smith, admin, Gabriel

John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

I’d just like to say the theory about taking a BR! library and considering it an object and then when you need a second instance of that object copying it to another file, then renaming all the functions in it and then using that as a second instance is a complete waste of time. This is not a good way to pretend to have objects in BR!... cause from that point on you have two (or worse more) separate programs that must be maintained in parallel – except the fn names must be different. I know in the past we’d talked about this maybe being a good idea, but it isn’t. It’s terrible. Hopefully one day we’ll figure out a better way to do OOP like programming in BR!, because that’s just absurd.
I’d love to hear from anyone who’s done this successfully and likes it.

-john
John Bowman
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

[BR_forum] OOP and BR!

Post by Gabriel »

I have. But not by making copies of libraries and procedurally modifying them.
 
 
I implemented as-true-as-possible OOP in BR When I designed ScreenIO.
 
Each Screen is a complete object that has its own events that get triggered, its own code and variables, its own user interface, and many other things built in.
 
As far as I can tell, so far, ScreenIO is the ONLY place where you can see true event driven object oriented programming in BR. Even BR 4.2 doesn't eloquently handle events yet. Gordon has just made it possible to handle events at all (by trapping them like error numbers). And it still has nothing like objects.
 
 
 
And ScreenIO does it in such a way that your old procedurally based code will merge perfectly in with your new ScreenIO code. The two blend together perfectly to make it possible to begin implementing objects in the middle of your preexisting procedural programs. That blend of Procedural and Object Oriented Programming is unique to ScreenIO - its not even available in any other programming languages - all other programming languages are pretty much one or the other, right?
 
Gabriel


 
On Wed, May 20, 2009 at 2:02 PM, John Bowman <gothnerd@gmail.com (gothnerd@gmail.com)> wrote:

I’d just like to say the theory about taking a BR! library and considering it an object and then when you need a second instance of that object copying it to another file, then renaming all the functions in it and then using that as a second instance is a complete waste of time.  This is not a good way to pretend to have objects in BR!... cause from that point on you have two (or worse more) separate programs that must be maintained in parallel – except the fn names must be different.  I know in the past we’d talked about this maybe being a good idea, but it isn’t.  It’s terrible.  Hopefully one day we’ll figure out a better way to do OOP like programming in BR!, because that’s just absurd. 
I’d love to hear from anyone who’s done this successfully and likes it.
 
-john

 


_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

My themes project was written to illustrate OOP in BR! too. But when it comes time to need more than one instance of any object the whole theory just falls apart. Fortunately with screens there is probably never a need for more than one instance of those objects. This was almost true with my Themes – for a while I only needed to have one theme or one theme’s attribute in memory at a time… but then I started to need code to import settings from a second theme’s attributes… and so I had to cheat and break my rules… it was either that or make a copy of each of the libraries (objects) and rename all the functions inside (yuk).

-john



From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Gabriel Bakker
Sent: Wednesday, May 20, 2009 3:41 PM
To: Business Rules Forum
Subject: Re: [BR_forum] OOP and BR!


I have. But not by making copies of libraries and procedurally modifying them.





I implemented as-true-as-possible OOP in BR When I designed ScreenIO.



Each Screen is a complete object that has its own events that get triggered, its own code and variables, its own user interface, and many other things built in.



As far as I can tell, so far, ScreenIO is the ONLY place where you can see true event driven object oriented programming in BR. Even BR 4.2 doesn't eloquently handle events yet. Gordon has just made it possible to handle events at all (by trapping them like error numbers). And it still has nothing like objects.







And ScreenIO does it in such a way that your old procedurally based code will merge perfectly in with your new ScreenIO code. The two blend together perfectly to make it possible to begin implementing objects in the middle of your preexisting procedural programs. That blend of Procedural and Object Oriented Programming is unique to ScreenIO - its not even available in any other programming languages - all other programming languages are pretty much one or the other, right?



Gabriel





On Wed, May 20, 2009 at 2:02 PM, John Bowman <gothnerd@gmail.com (gothnerd@gmail.com)> wrote:
I’d just like to say the theory about taking a BR! library and considering it an object and then when you need a second instance of that object copying it to another file, then renaming all the functions in it and then using that as a second instance is a complete waste of time. This is not a good way to pretend to have objects in BR!... cause from that point on you have two (or worse more) separate programs that must be maintained in parallel – except the fn names must be different. I know in the past we’d talked about this maybe being a good idea, but it isn’t. It’s terrible. Hopefully one day we’ll figure out a better way to do OOP like programming in BR!, because that’s just absurd.
I’d love to hear from anyone who’s done this successfully and likes it.

-john





_______________________________________________
BR_forum mailing list
BR_forum@ads.net (BR_forum@ads.net)
http://ads.net/mailman/listinfo/br_forum_ads.net
John Bowman
Kevin Klappstein

[BR_forum] OOP and BR!

Post by Kevin Klappstein »

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



John Bowman wrote:
My themes project was written to illustrate OOP in BR! too. But when
it comes time to need more than one instance of any object the whole
theory just falls apart. Fortunately with screens there is probably
never a need for more than one instance of those objects. This was
almost true with my Themes – for a while I only needed to have one
theme or one theme’s attribute in memory at a time… but then I started
to need code to import settings from a second theme’s attributes… and
so I had to cheat and break my rules… it was either that or make a
copy of each of the libraries (objects) and rename all the functions
inside (yuk).

-john

*From:* br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] *On
Behalf Of *Gabriel Bakker
*Sent:* Wednesday, May 20, 2009 3:41 PM
*To:* Business Rules Forum
*Subject:* Re: [BR_forum] OOP and BR!

I have. But not by making copies of libraries and procedurally
modifying them.

I implemented as-true-as-possible OOP in BR When I designed ScreenIO.

Each Screen is a complete object that has its own events that get
triggered, its own code and variables, its own user interface, and
many other things built in.

As far as I can tell, so far, ScreenIO is the ONLY place where you can
see true event driven object oriented programming in BR. Even BR 4.2
doesn't eloquently handle events yet. Gordon has just made it possible
to handle events at all (by trapping them like error numbers). And it
still has nothing like objects.

And ScreenIO does it in such a way that your old procedurally based
code will merge perfectly in with your new ScreenIO code. The two
blend together perfectly to make it possible to begin implementing
objects in the middle of your preexisting procedural programs. That
blend of Procedural and Object Oriented Programming is unique to
ScreenIO - its not even available in any other programming languages -
all other programming languages are pretty much one or the other, right?

Gabriel



On Wed, May 20, 2009 at 2:02 PM, John Bowman <gothnerd@gmail.com
<mailto:gothnerd@gmail.com>> wrote:

I’d just like to say the theory about taking a BR! library and
considering it an object and then when you need a second instance of
that object copying it to another file, then renaming all the
functions in it and then using that as a second instance is a complete
waste of time. This is not a good way to pretend to have objects in
BR!... cause from that point on you have two (or worse more) separate
programs that must be maintained in parallel – except the fn names
must be different. I know in the past we’d talked about this maybe
being a good idea, but it isn’t. It’s terrible. Hopefully one day
we’ll figure out a better way to do OOP like programming in BR!,
because that’s just absurd.

I’d love to hear from anyone who’s done this successfully and likes it.

-john


_______________________________________________
BR_forum mailing list
BR_forum@ads.net <mailto:BR_forum@ads.net>
http://ads.net/mailman/listinfo/br_forum_ads.net

------------------------------------------------------------------------

_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net
_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

Oh yes that would be required for recursion wouldn't it... usually I try to
avoid recursion to "keep it simple" but I suppose sometimes there is good need
for it. And declairing all your variables in the def is the only way to limit
the scope of any variables, now.

One thing I like to do to help with my scope issues is to make all the variables
inside a function start with a shortened from of the function name like

Fn_do_whatever_you_will
Would use variables like
Dwyw_file_name$

That way none of my function's variables bump into each other. Of course this
would not work in a recursion situation as you mentioned.

-----Original Message-----
From: br_forum-bounces@ads.net [mailto: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



John Bowman wrote:
My themes project was written to illustrate OOP in BR! too. But when
it comes time to need more than one instance of any object the whole
theory just falls apart. Fortunately with screens there is probably
never a need for more than one instance of those objects. This was
almost true with my Themes - for a while I only needed to have one
theme or one theme's attribute in memory at a time. but then I started
to need code to import settings from a second theme's attributes. and
so I had to cheat and break my rules. it was either that or make a
copy of each of the libraries (objects) and rename all the functions
inside (yuk).

-john

*From:* br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] *On
Behalf Of *Gabriel Bakker
*Sent:* Wednesday, May 20, 2009 3:41 PM
*To:* Business Rules Forum
*Subject:* Re: [BR_forum] OOP and BR!

I have. But not by making copies of libraries and procedurally
modifying them.

I implemented as-true-as-possible OOP in BR When I designed ScreenIO.

Each Screen is a complete object that has its own events that get
triggered, its own code and variables, its own user interface, and
many other things built in.

As far as I can tell, so far, ScreenIO is the ONLY place where you can
see true event driven object oriented programming in BR. Even BR 4.2
doesn't eloquently handle events yet. Gordon has just made it possible
to handle events at all (by trapping them like error numbers). And it
still has nothing like objects.

And ScreenIO does it in such a way that your old procedurally based
code will merge perfectly in with your new ScreenIO code. The two
blend together perfectly to make it possible to begin implementing
objects in the middle of your preexisting procedural programs. That
blend of Procedural and Object Oriented Programming is unique to
ScreenIO - its not even available in any other programming languages -
all other programming languages are pretty much one or the other, right?

Gabriel



On Wed, May 20, 2009 at 2:02 PM, John Bowman <gothnerd@gmail.com
<mailto:gothnerd@gmail.com>> wrote:

I'd just like to say the theory about taking a BR! library and
considering it an object and then when you need a second instance of
that object copying it to another file, then renaming all the
functions in it and then using that as a second instance is a complete
waste of time. This is not a good way to pretend to have objects in
BR!... cause from that point on you have two (or worse more) separate
programs that must be maintained in parallel - except the fn names
must be different. I know in the past we'd talked about this maybe
being a good idea, but it isn't. It's terrible. Hopefully one day
we'll figure out a better way to do OOP like programming in BR!,
because that's just absurd.

I'd love to hear from anyone who's done this successfully and likes it.

-john


_______________________________________________
BR_forum mailing list
BR_forum@ads.net <mailto:BR_forum@ads.net>
http://ads.net/mailman/listinfo/br_forum_ads.net

------------------------------------------------------------------------

_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net
_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net


_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net
John Bowman
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

Kenvin - today doing a recursive function - I got to apply your tip (below).
Thank you!

-john

-----Original Message-----
From: br_forum-bounces@ads.net [mailto: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



John Bowman wrote:
My themes project was written to illustrate OOP in BR! too. But when
it comes time to need more than one instance of any object the whole
theory just falls apart. Fortunately with screens there is probably
never a need for more than one instance of those objects. This was
almost true with my Themes - for a while I only needed to have one
theme or one theme's attribute in memory at a time. but then I started
to need code to import settings from a second theme's attributes. and
so I had to cheat and break my rules. it was either that or make a
copy of each of the libraries (objects) and rename all the functions
inside (yuk).

-john

*From:* br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] *On
Behalf Of *Gabriel Bakker
*Sent:* Wednesday, May 20, 2009 3:41 PM
*To:* Business Rules Forum
*Subject:* Re: [BR_forum] OOP and BR!

I have. But not by making copies of libraries and procedurally
modifying them.

I implemented as-true-as-possible OOP in BR When I designed ScreenIO.

Each Screen is a complete object that has its own events that get
triggered, its own code and variables, its own user interface, and
many other things built in.

As far as I can tell, so far, ScreenIO is the ONLY place where you can
see true event driven object oriented programming in BR. Even BR 4.2
doesn't eloquently handle events yet. Gordon has just made it possible
to handle events at all (by trapping them like error numbers). And it
still has nothing like objects.

And ScreenIO does it in such a way that your old procedurally based
code will merge perfectly in with your new ScreenIO code. The two
blend together perfectly to make it possible to begin implementing
objects in the middle of your preexisting procedural programs. That
blend of Procedural and Object Oriented Programming is unique to
ScreenIO - its not even available in any other programming languages -
all other programming languages are pretty much one or the other, right?

Gabriel



On Wed, May 20, 2009 at 2:02 PM, John Bowman <gothnerd@gmail.com
<mailto:gothnerd@gmail.com>> wrote:

I'd just like to say the theory about taking a BR! library and
considering it an object and then when you need a second instance of
that object copying it to another file, then renaming all the
functions in it and then using that as a second instance is a complete
waste of time. This is not a good way to pretend to have objects in
BR!... cause from that point on you have two (or worse more) separate
programs that must be maintained in parallel - except the fn names
must be different. I know in the past we'd talked about this maybe
being a good idea, but it isn't. It's terrible. Hopefully one day
we'll figure out a better way to do OOP like programming in BR!,
because that's just absurd.

I'd love to hear from anyone who's done this successfully and likes it.

-john


_______________________________________________
BR_forum mailing list
BR_forum@ads.net <mailto:BR_forum@ads.net>
http://ads.net/mailman/listinfo/br_forum_ads.net

------------------------------------------------------------------------

_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net
_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net


_______________________________________________
BR_forum mailing list
BR_forum@ads.net
http://ads.net/mailman/listinfo/br_forum_ads.net
John Bowman
gordon
Posts: 358
Joined: Fri Apr 24, 2009 6:02 pm

[BR_forum] OOP and BR!

Post by gordon »

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)


John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

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
John Bowman
George Tisdale

[BR_forum] OOP and BR!

Post by George Tisdale »

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 [mailto: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
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

[BR_forum] OOP and BR!

Post by Gabriel »

The only problem is it doesn't support Arrays.
 
Also, its messy and difficult to read.
 
Gabriel


On Wed, May 27, 2009 at 10: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
Christopher Shields

[BR_forum] OOP and BR!

Post by Christopher Shields »

My thoughts, exactly. I was expounding this point in another email but you beet me to the punch. OOP is necessary when creating complex graphical interfaces. Procedural programming becomes to difficult to read and maintain for this.

That being said, we can and should create an object abstraction for BR. We don't need Gordon to change syntax. We can do it with our own stacks and functions. I've yet to see this done in the traditional manner for BR. But that would be really cool.

Gabriel Bakker wrote:
The only problem is it doesn't support Arrays.

Also, its messy and difficult to read.

Gabriel


On Wed, May 27, 2009 at 10: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
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

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 [mailto: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 [mailto: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
John Bowman
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

[BR_forum] OOP and BR!

Post by Gabriel »

I declare every variable I use in a function as a local parameter by listing it in the def statement. I only ran into line length problems once but its a pretty significant problem.
 
Declaring every temp variable used in a function as a local parameter is a really good practice to get into. It keeps your functions from stepping on each others toes in random ways, and it encourages the use of cleaner code.
 
Of course, I have had to resort to major workarounds when I want to use an array in a function recursively. For that I have had to make my own stack and write functions for placing arrays on it and popping arrays off of it.
 
 
Also, I have found MyEdit's CTRL+SHIFT+UP/DOWN (search for next/prior occurrence of current word) can also be a useful tool when determining if a variable is unique or not.
 
Gabriel


On Wed, May 27, 2009 at 1:55 PM, John Bowman <gothnerd@gmail.com (gothnerd@gmail.com)> wrote:

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
George Tisdale

[BR_forum] OOP and BR!

Post by George Tisdale »

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 [mailto: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 [mailto: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 [mailto: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
John
Posts: 555
Joined: Sun Apr 26, 2009 8:27 am

[BR_forum] OOP and BR!

Post by John »

That functionality is very useful. In Notepad+ it is Ctrl+F3/Ctrl+Shift+F3, but both allow you to change the shortcut keys.

Another trick I use to keep variables unique to my function is I make every variable begin with a prefix that denotes the function name… for example if I wanted a name$ in fn_what_ever, I’d probably call it We_Name$. It doesn’t help with recurision, but I can tell at a glance that it’s meant for that function and shouldn’t be used anywhere else.

-john

From: br_forum-bounces@ads.net [mailto:br_forum-bounces@ads.net] On Behalf Of Gabriel Bakker
Sent: Wednesday, May 27, 2009 3:11 PM
To: Business Rules Forum
Subject: Re: [BR_forum] OOP and BR!


I declare every variable I use in a function as a local parameter by listing it in the def statement. I only ran into line length problems once but its a pretty significant problem.



Declaring every temp variable used in a function as a local parameter is a really good practice to get into. It keeps your functions from stepping on each others toes in random ways, and it encourages the use of cleaner code.



Of course, I have had to resort to major workarounds when I want to use an array in a function recursively. For that I have had to make my own stack and write functions for placing arrays on it and popping arrays off of it.





Also, I have found MyEdit's CTRL+SHIFT+UP/DOWN (search for next/prior occurrence of current word) can also be a useful tool when determining if a variable is unique or not.



Gabriel

On Wed, May 27, 2009 at 1:55 PM, John Bowman <gothnerd@gmail.com (gothnerd@gmail.com)> wrote:
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
John Bowman
Post Reply