tedd@... wrote: > >Yes. The idea of the front end/back end is interesting. Passing the data via > >handles or records would give it maximum flexibility. This can also exploit > >FB's multitude of handle-type variables. For example, the caller and > >recipient might both know that what they are getting is "element as handle > >to myrecordtype1", while the generic middleman routines only need to be told > >that the parameter they are passing to and fro is a generic handle or long > >integer. > >-- > >Robin > > Robin: > > Now you're venturing into Object Orientated Programming, where when you > call a function, you don't care what variables you send it, because at the > other end, the function that is used to process your data is dependant > upon, or chosen by, the variables you sent it. > > For example, let's say I want to sort a group of numbers in an array -- so > I place the number array into a function called "FN sort(array(0))". The > function that is used to sort the array is determined by the variable > contained in the call. Now, I could do the same thing with an array of > strings and use the identical same function, namely "FN sort(array$(0)). > Why? Because I have sent the function an array of strings. You see, the > actual function used to sort the array, on the back-side, is different than > the preceding example because I sent it an array of strings instead of > numbers. > > In other words, it goes like this. I want to sort anything -- I always use > FN sort(). At the other end of the call, there are many different sort > functions. However, the function that is used in my specific call is > determined by the variables that are contained within the () portion of the > call. > > This type of programming makes the back-end complicated because you have to > account for every type of sort one could think of. While on the front end, > it's an easy call. > > Now, consider that there are numerous programmers that could write hundreds > of different sort routines, each with a different set of variables to sort. > If one could combine all those different sort routines into one back-end, > then a single front-end call would suffice for all sorts -- therein lies > the beauty of OOP and libraries -- as I understand it. Hi tedd/Robin, Frankly, this is one of the things that I like least about OOP AND the English language, having the "context" determine the meaning. Of course this concept of "overloading" is more tolerable with programming than it is with the language that human beings need to "interpret". How many times have you read a sentence, thinking it meant one thing about half way through, only to find - when you reach the end of the sentence that it means something totally different? I find using the same word to mean both nouns and verbs (for example) to be totally unacceptable, and hope that one day we will revise our language to eliminate this "overloading". I'm not so sure I like it in OOP, either. It may make the languages more versatile, but it puts a hell of a strain on the brains of the feeble programmers. Opens things up for all sorts of mistakes too. In Visual Basic, they allow the concept of "variant" variable types. They too slow things down and create opportunities for all sorts of programming errors. Makes for great "lazy" programmers. For M$ that just seems so natural. I hope this is one thing that FB avoids like the plague when we finally get around to developing our our OOP version. IMHO, Joe Wilkins Vote Nader for President - he's no variant - you know what you're getting in advance!