[AccessD] Class Rebuttal was: Basic Unbound Form ...

Deep breath.....

Okay, that is what I am getting a bit frustrated about.  WHY are public
variables in a class 'bad practice'.  Yes, they are limited, but their
purpose is to create a straight place holder, a simple property.

I have written a ton of projects where I need a collection of a class where
the class is strictly a data holder.  It doesn't write to a recordset, it
doesn't need to manipulate or check the data, it just needs to hold the
data.  In those cases, Public works perfectly and is the right tool to use.
Creating Get/Let statements is a waste of time.

The main argument I am hearing is that Public is limited, which it is.  It's
not designed to do anything more then hold a value.  If you are getting
snared by it's limitations, then you didn't design the class right. That's
not Public's fault, that's your fault.  If you design it right, and the
property needs nothing more then to hold a value, Public is the right tool
for the job.  You don't open your computer case with a jack hammer, you
could, but it's not the right tool for the job.  You could put a hole in the
street with a screwdriver (eventually), but again, it's not the right tool
for the job.

I say again, I have yet to hear a single VALID argument explaining an actual
FAULT of using public in a class.  Fault being something that breaks under
normal use.  Saying what it is limited by is a limitation, not a fault.
It's like saying that VB is faulty because it doesn't allow for true
inheritance.  It's a limitation of VB, not a 'fault'.

Drew

-----Original Message-----
From: Kenneth Ismert [mailto:kismert at sbcglobal.net]
Sent: Tuesday, June 13, 2006 9:05 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Class Rebuttal was: Basic Unbound Form ...



OK, lets see... 

Lambert is correct in that using public variables to create class
properties is 'bad practice', or at least non-standard.

Drew is correct in that because it can be done in the language, it is
'right', or at least allowable. 

But the interesting thing to me is no one talks about what is missing
in VB objects: 

 * No true class-level variables. All member variables of a class are
instance variables. Class variables would eliminate most of the need
for globals in VB.
 * No true constructor. You'd like to create objects like this, but you
can't: 
     Set Obj = New clsPerson("Ken", "123 Any St", 789)
 * No true singleton object. You can simulate it using modules with
properties, or public object variables, but neither approach is a
complete solution.
 * No inheritance model, whether it be single, multiple, or mixin. 

Finally, if you want compact and correct property declarations, look at
this Ruby example: 

  Class MyClass
    attr_accessor :name, :address, :emplID
  End

This creates the instance variables, getters and setters for the three
named properties, all in one line. 

I bring Ruby up because, in arguements over what are essentially
limitations of a language, it is valid to suggest alternatives.

-Ken
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com