Robustness of Functional Global pattern at large scales?

[jgcode]

This is the way I code my AEs. I usually have single input accessors...

I tend to make a distinction here. An accessor (for me) will be of the ilk "do one thing, do it properly" (get name, get value set name, set value etc). But a wrapper would be a simplifier of a more complex function or "wrap" several "Methods" to yield a new function.

I agree with Shaun to make the distinction for the purpose of discussion.

And yes, if you define accessors then they should get/set one piece of the internal state data. (because that's what accessors do).

In the examples I have posted I haven't mentioned accessors - I have been talking about supplying inputs/outputs for methods (I guess that's a distinction made there) - and the issues I have with that in the past and trying to make it more robust.

I wanted to present other way of creating an AE using a DVR-IPE.

[Mechatroner]

Thanks for all of your comments. I'm glad to hear that there appear to be no known problems with FG and USRs. It's also been interesting to hear about the different variations of FGs that have been developed.

Regards,

John Bergmans

[Val Brown]

So if I'm following this, jgcode you would "approve" of FGVs as an accessor but not as a wrapper, whereas others are OK with using FGVs as wrappers, using either a (large) typedef cluster for the inputs and outputs, in that sense turning the FGV into an "accessor" if you will to a collection of methods, properties, etc.

[jgcode]

So if I'm following this, jgcode you would "approve" of FGVs as an accessor but not as a wrapper, whereas others are OK with using FGVs as wrappers, using either a (large) typedef cluster for the inputs and outputs, in that sense turning the FGV into an "accessor" if you will to a collection of methods, properties, etc.

I don't 100% follow the above (I think our definitions of things are different - but that's ok).

If it helps here are my posts in summary:

• I agree with using FGV/MFVI/AE's etc... on a module per module basis
  
• I think all approaches discussed are valid - there are good reasons for both (I particularly find ShaunR's perspective in his last post above very interesting)
  
• I just personally prefer creating an API for a module
  
• I really like the 'LV2009' approach and hence wanted to post it in this thread to share with the OP
  

[Val Brown]

I don't 100% follow the above (I think our definitions of things are different - but that's ok).

If it helps here are my posts in summary:

• I agree with using FGV/MFVI/AE's etc... on a module per module basis
  
• I think all approaches discussed are valid - there are good reasons for both (I particularly find ShaunR's perspective in his last post above very interesting)
  
• I just personally prefer creating an API for a module
  
• I really like the 'LV2009' approach and hence wanted to post it in this thread to share with the OP
  

Yeah, jargon can always get in the way. Like Shaw said: "England and America are two countries separated by a common language."

Thanks for the confirmation of that and my (I think I got it) understanding.