Classes and (dis)amiguation

[Jack Leach]

Hello,

I'm in process of trying to write my first class and have a fairly general
question... do we need to disambiguate property/routine names in class
modules as we would in standard modules? I've done some looking through a
few imported classes that I have, and none of the authors seem to take any
particular pains to do so, and I'm not sure if this is considered bad
practice or not....


[clsReportInfo]
Option Explicit
Option Compare Database

Privtate pPrinter As Printer

Public Property Set Printer(prt As Printer)
Set pPrinter = prt
End Property

Public Property Get Printer() As Printer
Printer = pPrinter
End Property




Is code inside a class module treated differently than code outside of one?
Do we need to only disambiguate names from the Class module and not be
concerned with vba reserved words or conflicts with other standard module
public item names or other Class properties and routines? I see on Chip
Pearson's website that he gives a beginning class example with a property
named "Name", which is clearly a reserved word (as is Printer obviously,
though the above code compiles without error....)

Any insight would be greatly appreciated!


--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

 

[Marshall Barton]

I'm in process of trying to write my first class and have a fairly general
question... do we need to disambiguate property/routine names in class
modules as we would in standard modules? I've done some looking through a
few imported classes that I have, and none of the authors seem to take any
particular pains to do so, and I'm not sure if this is considered bad
practice or not....


[clsReportInfo]
Option Explicit
Option Compare Database

Privtate pPrinter As Printer

Public Property Set Printer(prt As Printer)
Set pPrinter = prt
End Property

Public Property Get Printer() As Printer
Printer = pPrinter
End Property

Is code inside a class module treated differently than code outside of one?
Do we need to only disambiguate names from the Class module and not be
concerned with vba reserved words or conflicts with other standard module
public item names or other Class properties and routines? I see on Chip
Pearson's website that he gives a beginning class example with a property
named "Name", which is clearly a reserved word (as is Printer obviously,
though the above code compiles without error....)

Not sure what you are concerned about. Inside your class
module, the names (variables) you use have the scope you
declared them with and that will override any other use of
the same name.

Outside your class, you must use an instance of the class to
refer to its properties/methods so there is no conflict.
This is different from public variables in a standard module
that have scope across your entire VBA project.

For example, Name is a very common property of almost every
object in the Access Object Model. There is no confilct
unless you use Name without qualifying it. Unqualified, you
may intend to refer to something you declared (e.g. table
field, form control, ...) and Access may think you want the
name of a **default** built-in object. The syntax to refer
to a field in a table/query is identical to the syntax to
refer to a property of a table so the quandry about the
meaning of table.Name refering to the table's Name peoperty
or the field Name in the table.

Maybe you are unaware that class module public variables are
properties of the class, whether you use PropertyGet/Set
procedures or not. That means you must use the class
instance dot syntax to refer to them.

 

[Jack Leach]

Thank you Marshall, that's exactly what I was hoping to have confirmed.


--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

I'm in process of trying to write my first class and have a fairly general
question... do we need to disambiguate property/routine names in class
modules as we would in standard modules? I've done some looking through a
few imported classes that I have, and none of the authors seem to take any
particular pains to do so, and I'm not sure if this is considered bad
practice or not....


[clsReportInfo]
Option Explicit
Option Compare Database

Privtate pPrinter As Printer

Public Property Set Printer(prt As Printer)
Set pPrinter = prt
End Property

Public Property Get Printer() As Printer
Printer = pPrinter
End Property

Is code inside a class module treated differently than code outside of one?
Do we need to only disambiguate names from the Class module and not be
concerned with vba reserved words or conflicts with other standard module
public item names or other Class properties and routines? I see on Chip
Pearson's website that he gives a beginning class example with a property
named "Name", which is clearly a reserved word (as is Printer obviously,
though the above code compiles without error....)

Not sure what you are concerned about. Inside your class
module, the names (variables) you use have the scope you
declared them with and that will override any other use of
the same name.

Outside your class, you must use an instance of the class to
refer to its properties/methods so there is no conflict.
This is different from public variables in a standard module
that have scope across your entire VBA project.

For example, Name is a very common property of almost every
object in the Access Object Model. There is no confilct
unless you use Name without qualifying it. Unqualified, you
may intend to refer to something you declared (e.g. table
field, form control, ...) and Access may think you want the
name of a **default** built-in object. The syntax to refer
to a field in a table/query is identical to the syntax to
refer to a property of a table so the quandry about the
meaning of table.Name refering to the table's Name peoperty
or the field Name in the table.

Maybe you are unaware that class module public variables are
properties of the class, whether you use PropertyGet/Set
procedures or not. That means you must use the class
instance dot syntax to refer to them.