Public Property Get FirstName() As String
    FirstName = m_sFirstName
End Property
Public Property Let FirstName(sLet As String)
    m_sFirstName = sLet
End Property

Wouldn't it have been easier and more readable just to use the module
level variable m_sFirstName, and not bother with these unecessary 6
lines of code?

I think the programmer had the fool notion that anything
remotely "object oriented" is really "good" and should be used if at
all possible.

Property Let/Get should only be used if something else needs to be done
than merely changing one variable.  And even then, it should probably
be limited to REAL classes that other programmers are going to use and
as such require a higher degree of formality.

Bob

Sent via Deja.com http://www.*-*-*.com/
Before you buy.

Public variables are easier for the initial coder but make maintenance
more difficult down the road.  Do yourself a favor and stick to a
single, consistent method of exposing properties from your objects and
in the long run you will be better off.

--
Please reply via the newsgroup only

Sent via Deja.com http://www.deja.com/
Before you buy.

Your app should be object oriented.  If you don't see why, then you should
take an object oriented class or read a book on the topic.  However,  you
can just make a variable public in a class (Not Module!!) instead of
explicitly writing these simplistic Property Let/Get statements.  The VB
Property Let/Get statements map directly to IDL Put and Get methods.  When
you define a variable as Public in a class, VB automatically does this for
you.  So, in essence, it has the exact same affect with less VB code.

When should you use simple Property Let/Get statements like this....   When
you think that there is a possibility in the future that you may add
functionality or business rules to the let or get and don't want to break
Binary Compatibility.

Gary Chamberlain
http://VBRing.com

A Module level variable will not be available to clients outside of the
class.

A Global Variable would be available to EVERYONE you would have no control
(No Encapsulation)

Further, by using Property Let/Get you expose the property as part of the
classes TypeLib/Interface

Property Let/Get allow us to do things like this.

    >End Property

Cheers

Gregory A Jackson MCSD, MCT
Sr. Software Engineer
STEP Technology
PDX, OR

If only you put as much effort into helping people as you do tearing down
their code.  So SELECT * from that!

What about validation? Triggers? But more important, to be able to write code against an "interface" is key. What's behind the interface can change at any time, but without concern to who/what it is coding against it (hell, there may not be any code behind it yet). What if you only want to expose the Get or the Set? Do you write some members this way and some members that way?

I say expose your interface ... not your data.

IMO

--------------------------------------------------------------------------------

Monte Hansen
VB Yuk Yuk
http://KillerVb.com

  Why do people put code like this in a VB form?

  Public Property Get FirstName() As String
      FirstName = m_sFirstName
  End Property
  Public Property Let FirstName(sLet As String)
      m_sFirstName = sLet
  End Property

  Wouldn't it have been easier and more readable just to use the module
  level variable m_sFirstName, and not bother with these unecessary 6
  lines of code?

  I think the programmer had the fool notion that anything
  remotely "object oriented" is really "good" and should be used if at
  all possible.

  Property Let/Get should only be used if something else needs to be done
  than merely changing one variable.  And even then, it should probably
  be limited to REAL classes that other programmers are going to use and
  as such require a higher degree of formality.

  Bob

  Sent via Deja.com http://www.deja.com/
  Before you buy.

I'm talking about wasetfully using the Property Let/Get statements
internally--like I said before I see this overrused because somehow
programmers think it's "better" to be object oriented, but mere use of
these statements does NOT make the program object oriented.
Furthermore, object oriented is overused as well.  A COM object is
inherently an object, but within the COM object you can have non object
oriented code.  Therefore are you programming OOP or non-OOP???  What a
tough question to answer!

Java is supposed to be more object oriented than VB, bu you can easily
write non-OOP programs with Java by using "static methods" (or are
the "member" in Java... I forget).  Only Smalltalk is entirely object
oriented and no one progrmas with that because it sucks.

If you have a public variable in a Form or a Class, and you need to
utilize the greater funcitonality of the Property Let/Get statements,
all you have to do is rename the variable, and then create the Property
Let/Get statements with the old variable name.  It's THAT easy!!!! But
until you need the Property Let/Get, I say keep it out of there and
make your code easier to read and debug.

Sent via Deja.com http://www.deja.com/
Before you buy.

So the personal attack is uncalled for.  But on the other hand, I'd be
geniunely sorry if my posts detrimentally affected this newsgroup.  But
I assumed this newsgroup was for general discussion about VB Enterprise
computing topics, and all of my posts fall within that category.  I
think this group would be really boring to read if the only kind of
posts allowed were "What ADO method do I use to exeute a stored
procedure", or "What API call do I used to read from the registry"
etc.  (Of course, there are legitimate cases of problems that aren't
covered in the online help or in the MSDN.  Undocumented bugs, that
kind of stuff.  These newsgroups are helpful for that stuff.)

And if I've given the impression that I hate VB.. I don't.  I think
that VB is a great development platform for "multi-tiered" database
applications (although I think that developers are too eager to stick
in extra tiers in order to be trendy and bleeding edge).  But VB also
has its flaws, which is true of most software.  Some of VB's flaws are,
in fact very frustrating.  I've seen a really big project that cost
large amounts of money blow up because of VB's flaws.

About VJ++: I think VJ++ is a better product than VB based upon small
work I've done with it, but I don't know how it would behave in a large
scale project.  Just because it's better technically doesn't mean you
should use it.  The advantages of VB is a large base of programmers you
can hire.  If you need a J++ WFC programmer that could be pretty hard
to find.  Microsoft hasn't been pushing J++.  And that's Sun's fault
for suing MS over it.  MS is waiting until the lawsuit completely
clears before they actively promote it.

Sent via Deja.com http://www.deja.com/
Before you buy.

--
Doug Marquardt (VB MVP)

If you just declare a variable like "Public varname" then it's public
and works EXACTLY the same was as if you used the more cumbersome
Property Let/Property Get statements.

If you want to limit access to the variables, then I agree 100% that
you need to use the Property Let/Property Get statements.  But usually
this isn't the case and usually it's not necessary to so limit access.
And I'm not talking about making objects that other programmers are
going to use.  I'm talking about the many differet modules within that
COM object that aren't exposed to the outside world, and you don't have
to make the internal code more complicated than it has to be.

Sent via Deja.com http://www.deja.com/
Before you buy.

For the simple cases you brought up, where none
of these things apply, the result is, as you said, identical
to a public variable. Whether the one style or the other
is easier to read depends on your point of view.

And there is another downside to using textbook
OOP methods without examining why and when
you should or shouldn't: it can lull you into a false
sense of security.

When VB 4 was still shiny new, another developer and
I were asked to review some code written by an outside
firm. Their programmers, with lots of C++ OOP exerience,
had produced an app that seems to have unpredictable,
intermittent problems as well as regular slow performance.

One big reason for the intermitten performance problems
was the use of Property Get/Set procedures. The
programmers had used these extensively, since
"it's good textbook encapsulation, right?"

Unfortunately they were unaware of the fact that VB
-doesn't- create a copy of all objects passed
back from a function or into a function, as C++
does.

I tend to favor property procedures myslef, but I also
tend to put validation or persistence logic in them.

--
Doug Marquardt (VB MVP)

For the same reason I like to use the IIf statement.

  x = IIf(a=b, y, z)

is a lot easer to read than

  If a = b Then
    x = y
  Else
    x = z
  End If

Of course by itself either statement appears easy to read.  And if you
are unfamiliar with the IIf syntax, then the first line seems more
complicated.  But, if you have have to have 10 of these kinds of
statements in a row, the 10 line aproach is easier to follow than the
60 line approach (5 lines of code plus one empty line between each If-
Then-Else).

Sent via Deja.com http://www.deja.com/
Before you buy.

Also, I find it easier to debug an If/Else statement.

--
Doug Marquardt (VB MVP)