Hi all,

So as you might have seen if you checked the source for my RexxTUI code *which I am still having fun improving I might add* where to further my reputation as the laziest programmer alive, I created a Data Object which if you make a request to get or set
an attribute, and the attribute does not exist, it simply creates the appropriate methods (all done using the unknown method)...

If you haven't seen it the reason was to allowing the following to work (note, DADT class does not have a method, or attribute called setMood... that would be silly).

/*
Example of my DADT class ...
*/
LazyProgrammer = .DynamicAttributeDataType~new("LazyProgrammer") LazyProgrammer~setMood("Happy")
say "The Lazy Programmer is " || LazyProgrammer~getMood()
exit

::requires "DADT.cls"

Will display...

The Lazy Programmer is Happy
and then exit.

A further example using DADT...

cat2 = .DynamicAttributeDataType~new("PUSSY") /* some people are boring */ cat2~setpaws(4)
say cat2~paws /* prints 4 */
cat2~noise = "miow" /* finally we make some sense */
say cat2 cat2~getpaws() cat2~noise /* now prints PUSSY 4 miow */
say cat2~colour /* .nil */
exit

Anyway, that was helpful, at least I thought it was... so I then decided to take things to the next level...

And so, we have my latest abomination to the Rexx language ... the CircumstanceSpecificExecutionObject

What is this monstrosity, I hear you ask... and why should I be interested.

Let us consider the following problem...

Suppose you want to use command line commands (rather than sysfiletree for some reason) on Windows you need to use the command dir to display a directory, and on Linux you want ls, and if it's some other platform you'll use SysFileTree instead...

Or suppose you have a method which you want run one way when running in "Production" and a different way when running on your "Development" environment...

That's the problem I am trying to solve...
and using my new object here is a little example.

/*
an example of code which uses a Circumstance Specific Execution Object
*/

ExampleObject = .MyProg~New

ExampleObject~printFiles() /* bases path on os and platform */ ExampleObject~printPlatform() /* just on platform */


/*
Plus some functions for assisting when debugging
*/

/* returns .false if we can determine that certain conditions could lead to a dead end or cannot run */




valid = ExampleObject~validateLogicPaths()

/* returns a list in the current condition order */
conditionorderlist = ExampleObject~getConditionOrder()


/*
provides a full breakdown of what code will be called in which circumstance including highlighting anything which won't run and circumstances where due to the lack of a defined "default" applying to one or more circumstances, the code is liable to fail.
*/

ExampleObject~showExecutionPaths()

/*
Allow a condition to be forced as appplying
*/ ExampleObject~forceCondition(ExampleObject~Platform,ExampleObject~DevelopmentPlatform)


/*
and because sometimes you want to have your code not use the default condition order, you can specify to use a specific alternative order instead
*/
ExampleObject~setConditionOrder(ExampleObject~Platform,ExampleObject~OS)

/*
and now we have interfered with the order...
*/
ExampleObject~printFiles() /* Now it will use platform first, then OS */



exit

/*
And here is the example object based on the CSEO object ...

I may make CircumstanceSpecificExecutionObject a mixin class... thinking about it but at the moment it isn't.
*/

::class MyProg subclass CircumstanceSpecificExecutionObject
::method printFilesOnLinux
'ls /prod'

::method printFilesOnWindows
'dir'

::method printFilesOnDefault
filelist = sysFileTree("*") /* yes, I know this doesn't work... I got lazy and I couldn't be bothered to actually look it up but you get the idea don't you */
do i = 1 to
say filelist.i
end

::method printFilesOnLinuxInDevelopment
say "you've asked me to print files... remember the file location is different" 'ls /development/versionDev1211'

::method printFilesInDevelopment
say "this method won't run because the default setting gives priority to platform"


::method printPlatformInDevelopment
say "I am the Dev environment"

::method printPlatformInTest
say "I am the Test environment"

::method printPlatformInProduction
say "I am the Live environment"

...

So here is how it works... and what it will do.


Now if the environment is set to Development and we are on linux, it will run printFilesOnLinuxInDevelopment

If it is linux but it is on the Prod or Testing environment it will run printFilesOnLinux

If it is set to Windows it will always run printFilesOnWindows

If it is on Mac (?) or Mainframe ... (or something which isn't windows and isn't linux) then it will be running printFilesOnDefault

The calls to printPlatform won't error because all platform states are covered...

For the second run of printFiles (after altering the priority for the rules)

On linux it will run printFilesOnLinuxInDevelopment
On windows etc it will run printFilesInDevelopment

...



I am in the process of finishing the development of this object, including allowing the order of rules conditions to be set... for dealing with conflicts.



I'll post it up (link to github or something) reasonably shortly... (once I've made sure that it works) ... but just thought that people might like to go "oh, ah" in the meantime... as when I spoke to my loving partner, she somehow managed to show less
enthusiasm towards the topic than she did when one of our cats tried to come into the house, carrying a very much still alive baby sparrow this morning...

Marginally...

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

Hi Bob,

LazyProgrammer~setMood("Happy")
say "The Lazy Programmer is " || LazyProgrammer~getMood()

to be even more ooRexx-ish this could be
LazyProgrammer~mood = "Happy"
say "The Lazy Programmer is " || LazyProgrammer~mood


P. S. Regarding the thing with the cats .. it's pretty much the same over here :-)

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