[AccessD] Framework Discussion - Dependent Objects

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






More information about the AccessD mailing list