Curiously, the VB compiler doesn't hurl on this code, although it does
violence to the distinction between properties and methods.
Object-oriented theory considers a property to be a representation of some
notion of the state of an object, and a method (function or, in VB, sub) to
represent some behavior of the object that the method carries out.
A property may be simply a means of exposing the value of a state variable,
such as a string or numerical value held in the object's instance memory, or
it may be a transformation or calculated result based on the state of the
object. For example, you might have a Temperature class, with properties
named Fahrenheit and Centigrade. The class holds a single data field
containing the temperature value (in a representation that's no one's
business but that of the class - maybe it's in Kelvin), but returns the temp
in Fahrenheit or Centigrade by performing a calculation on the internal
temperature value.
By convention, a class that contains a list or collection of other objects
may expose an indexed property like Item, where a single input argument
represents the index in the contents, and the return value of the property
is the object at that location in the collection. This is about the only
parameterized property that the theorists approve of.
So, in general, properties don't have arguments, except for indexers.
Functions and (in VB) Subs may or may not, depending on their design.
HTH,
Tom Dacon
Dacon Software Consulting
Surely, I can have arguments on a property and calculate a result
Public Readonly Property Calc(ByVal X as integer, ByVal Y as integer) as
long
Get
Return X * Y
End Get
End Property
