John W. Colby
jwcolby at colbyconsulting.com
Tue Mar 16 09:54:40 CST 2004
Jim, I certainly don't want to squash discussion and I don't want to hurt your feelings or anyone else's. I am not exactly taking it personally, however it does feel as if I am "defending" trying to extend the capabilities of Access using a class and frameworks using comparison against tools that simply don't compare. IT simply isn't useful to discuss Access in terms of FoxPro, or .NET, C++, VB. I mean it is useful to do that, if the objective is to decide whether or not to use Access or simply move to something else for the capabilities that the something else provides. What isn't useful is to compare what can be done "in terms of" that something else. >I'm not sure what you think I mean by "overloading" Overloading means inheriting a parent class, then taking a defined method in the parent class, and writing the exact same syntax function call replacing the functionality with something different. Dog "Barks", Daschund "barks" but entirely differently. I inherit dog, and then write a new "bark" method changing the code (usually but not always writing entirely new code) to change what happens when the user calls my bark method. I then save that as a Daschund object of the dog lineage. If you are going to use OO phrases and keywords I am going to respond that that isn't useful. While defining "overloading" as adding more methods and properties to a class is a humorous definition (makes me envision a poor boat class sinking under the waves) it is not what the word means, and I was responding to an apparent (to me) attempt to apply OO terminology to a patently non OO environment. >And this was exactly my point. Your choice was either to create a new class in the Framework to handle a text control with a popup calendar or add properties and methods to a single class so it can do both jobs. Let's be clear (I think I already have but...) I don't add 13 different text box classes. There is a single textbox class and my form's control scanner loads that class for every text box it encounters. You could if you desired use a system of 13 different text box classes if you wanted to use a naming convention where you used something like txtAXXX txtBXXX etc and then in the scanner parsed the first 4 characters of the text box to discover which class to load. The problem with doing this is that now the framework only works with your specific naming convention. >I'm not telling you do to anything. I was trying to add to the discussion, pointing out that performance is based on design decisions that are made in the framework. You are taking an OOP approach and the same fundamentals apply no matter which language your dealing with. And I am trying to point out that to a large extent my design decisions are made for me by Microsoft's denial of OO capabilities to Office programmers. I am not taking an OOP approach, I am using a pitiful tool to the best of my abilities. I am NOT taking an OOP approach. I am using a class to wrap an object. I am NOT taking an OOP approach. Access and Office does NOT have OOP tools in any significant meaning of the word. It does have classes, and it has Withevents. These devices (along with the forms and controls) are called objects, so you could say I am doing OBJECT PROGRAMMING, but that is not the same as OBJECT ORIENTED PROGRAMMING. Those classes and controls cannot be inherited, I can't overload their methods (since I can't inherit them), these classes are just an object defined in and of themselves and stand alone. I am doing nothing more or less than wrapping an object in a class and adding new methods and properties using the class. That is NOT an OOP approach because I don't have OOP tools to approach the task with! As for some fundamentals applying... I will grant you that a developer could design 13 text box classes if they wished. Or take all of that functionality and put it in a single text box class. So whereas you as a FoxPro developer can sit there for months trying to define which level of inheritance you want to put the bark method at, I get to make a decision (in about 15 minutes) as to whether I use 13 text box classes or one. I did think about this long ago ad decided (in about 15 minutes) that it ultimately did not make sense to maintain 13 text box classes, that the additional code and properties in a single class was not excessive overhead and that was that. >I would love to see someone do a commercial framework for Access. But after 10 years of existence, one has to ask themselves why there are not a truck load of them already. There are many reasons. 1) Programmers who use frameworks expect a system that they can just inherit and add their own stuff to - see your own posts!!! That simply isn't possible with Access. Thus they are left with using the framework as is and funneling change requests to the developer, and perhaps never seeing their requests implemented, or "rolling their own". 2) Access as an environment is entirely different form other development environments in that data stores are done in MDBs, there is the FE/BE split issue, and where do you put the table data for the framework, the framework relative to the FE (application), back end (it can talk to SQL Server and other data stores as well) so that changes aren't overwritten by the next rev of the framework. Little problems that get in the way. Most Access developers don't want to have to think about these things because it can make your head hurt. 3) There are so many "access developers" who don't have a clue what a library is much less what a framework is, and so few (percentage wise) that do understand all of these issues. Where is the market? What are the support costs? Imagine selling a thousand copies and then getting 900 phone calls (or emails) a day for the rest of your life asking how to do something. The unfortunate reality is that Access has a huge percentage of "power users calling themselves developers", and a miniscule percentage of IT trained professionals selecting Access as their primary tool. >You asked for input about the design of frameworks and I've brought up a few issues (performance and distribution of new versions). If you don't want to address them and explore these areas then fine. But if that's the case, then don't ask for the input in the first place. And I have responded re performance. As far as I can tell (and I have been using my framework for many years in various implementations) performance simply isn't an issue for all the reasons I outlined. I encourage you and anyone else to explore this for themselves. I did extensive timings of classes loading and unloading, using forms that loaded a TON of controls (not useful forms, just forms that I copied hundreds of controls onto for testing purposes). I then timed the open (with NO FORM / CONTROL DATA LOADING) so that I could get a sense of the load / unload times of classes. My conclusion using an OLD SLOW computer was that each class took under 1/2 millisecond to load. With my current workstation a form with 288 control classes plus the form class took 60 milli-seconds to run the control scanner and load the classes for those controls (I just built a test form to time that)! Sure, further performance analysis is always welcome but that should at least give a rough feeling for the speed of things. As for distributions (I guess I missed that in your previous post) that is only an issue if the developer who buys the framework expects to "overload it". If they do then they need to be gently reminded that Access is not OO and to go elsewhere if that is their expectation! "What you get is what you get" and if you need additional things you request hooks or simply do things that aren't framework supported on a form by form, control by control basis. After all, if they are not using a framework, they are already doing exactly that except with ALL of their functionality! Or build their own framework. My article series is showing this list exactly how to do that. So Jim, lets discuss frameworks by all means. Just don't bother trying to discuss it in comparison to things it isn't. As some famous philosopher once said (roughly): "It isn't useful to try and teach a pig to sing. It won't work and you'll just piss off the pig". Access can do a very few things to make your life better when it comes to frameworks. I will discuss for hours the merits of building 13 text box classes vs. one, why you would do one, why you would do the other, how you would implement the system if you chose to do so. But to try to cast it in the light of OOP programming just obfuscates the reality... it ain't. Please don't go away mad, in fact don't go away at all. Just approach the subject from an angle that allows us to perform a useful engineering analysis of what can be done with the tools we have. We have classes, and we have withevents. We have objects (controls and classes), none of which can be inherited or anything that goes along with inheritance. Those are the ground rules. How can we do something useful with that in the context of a framework? John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Jim Dettman Sent: Tuesday, March 16, 2004 9:07 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Framework Discussion - Dependent Objects John, I'm not sure what you think I mean by "overloading", but what I'm saying is that you have a choice: You either build numerous classes to handle specific behavior or you overload a single class with more properties and methods to make it handle more then one type of behavior. <<If a popup calendar floats your boat, build one and tie it in to the text box class. Have a UseCalendar property that you set the "turns on" using that calendar for exactly the instances where you want a calendar. However it is that you managed to program the text box to use the calendar in some form somewhere, that same exact code will work in the text box class. Except that once added to the class it is available to any text box anywhere in the app. Set your UseCalendar property and boom... that text box will use the calendar. This isn't magic, just engineering effort applied to the system rather than to one control on one form.>> And this was exactly my point. Your choice was either to create a new class in the Framework to handle a text control with a popup calendar or add properties and methods to a single class so it can do both jobs. <<Or are you perhaps telling ME THAT I SHOULD NOT DO THIS but it is just fine that Microsoft does it?>> I'm not telling you do to anything. I was trying to add to the discussion, pointing out that performance is based on design decisions that are made in the framework. You are taking an OOP approach and the same fundamentals apply no matter which language your dealing with. I don't understand why your taking this so personally. I never said that what you were doing was not worth it. I was discussing frameworks in general. This has nothing to do with me leaving Access for VFP, which I have not (I still use both tools on a regular basis). I would love to see someone do a commercial framework for Access. But after 10 years of existence, one has to ask themselves why there are not a truck load of them already. You asked for input about the design of frameworks and I've brought up a few issues (performance and distribution of new versions). If you don't want to address them and explore these areas then fine. But if that's the case, then don't ask for the input in the first place. Jim (315) 699-3443 jimdettman at earthlink.net