John W. Colby
jwcolby at colbyconsulting.com
Tue Mar 16 11:40:15 CST 2004
Yea, so I now understand. Sorry for the confusion. All I really know is that absolutely NONE of that stuff applies to Access, which was what I was attempting to point out. "Talk OOP stuff and you might as well take it to a list where that matters." John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Bob Hall Sent: Tuesday, March 16, 2004 12:03 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Framework Discussion - Dependent Objects Hi John, On Tue, Mar 16, 2004 at 10:54:40AM -0500, John W. Colby wrote: > 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. Overloading doesn't involve inheritence, and the syntax of the function call can change. The definition is that the same function name (or operator symbol) is used with different parameters (or operands). For example, I can overload DrawSolid() so that it draws a four-sided solid when passed four points, and a five-sided solid when passed five points. I don't do this by inheritence; I just write a new definition of DrawSolid(). What you describe above is polymorphism. Bob Hall -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com