VB Properties - private data member optional?

  • Thread starter Thread starter YellowDog
  • Start date Start date
Y

YellowDog

I want to use a property without a private data member. This is
supposed to be legal, except that I get an Stack Overflow Exception
when I implicity use the set method. Here's the code:

Option Explicit
Option Strict On

Imports System


Public Class PropertyT

' Private LocalAge as Integer = 24

Public Property LocalAge() As Integer

Get
Return LocalAge
End Get

Set (ByVal value As Integer)
LocalAge = value
End Set

End Property

End Class


Public Class PropertyConsumer

Public Shared Sub Main()

Try
Dim t As New PropertyT()
Console.WriteLine("t's Age is {0}", t.LocalAge)
t.LocalAge = 25
Console.WriteLine("t's Age is {0}", t.LocalAge)
Catch e As StackOverflowException
Console.WriteLine(e.Message)
End Try

End Sub

End Class



=========

And here's the output.

t's Age is 0
Exception of type System.StackOverflowException was thrown.
 
You are recursively calling your property until the StackOverflow exception
is thrown. I'm pretty sure that is not what you want to happen.
 
YellowDog said:
I want to use a property without a private data member.

That's fine - although you'll need *something* to back the member, if
you want to be able to set it.
This is
supposed to be legal, except that I get an Stack Overflow Exception
when I implicity use the set method. Here's the code:
Public Property LocalAge() As Integer

Get
Return LocalAge
End Get

Set (ByVal value As Integer)
LocalAge = value
End Set

That's effectively declaring two methods, each of which call themselves
recursively. Where were you expecting the data to be stored, without a
field of some description backing it?
 
from the ole class builder in VB6 I always follow the form
of a private local copy of the property. While you do
need this if its calculated, most of the time this is the
way I accomplish this. (You are calling the property from
within the property itself. Infinite recursion = stack
overflow)

Option Explicit
Option Strict On

Imports System


Public Class PropertyT

Public Class PropertyConsumer
'*****************
Private mvarLocalAge As Integer
'*****************

Get
Return mvarLocalAge '*******
End Get

Set (ByVal value As Integer)
mvarLocalAge = value '******
End Set
 
StackOverflow exception is thrown. <<


When I saw the Stack Overflow, I immediately thought "inifinite loop",
but then I immediately dismissed it (foolishly) because there are no
loops. After I posted and went and did something else, it came to mind
that I ought to check the IL. That's still an execrcise I plan to
pursue. I'm relatively new to .NET and learning how to disassemble IL
is definitely something I'll need to know.
themselves recursively. Where were you expecting the data to be
stored, without a field of some description backing it? <<

I come froma Java background, where a property is not so much a formal
language construct as it is a coding convention. C# it seems, follows
a similar pattern. Where did I expect the data to be stored? I thought
that VB, through the Property keyword, would behind-the-scenes define
a variable named and typed the same as declared in the Propetrry
statement itself. That belief was re-enforced when I read the docs and
saw that a private data member is optional. It was further re-enforced
when I tried to declare a private data member named and typed the same
as the property and the compiler complained he already had one of
those.
Infinite recursion = stack overflow. <<

From within the property itself ... I guess that's what I don't
understand. Then exactly what ~is~ a property; what does the Property
statement do; and where are you when you're "within the property"? I
mean can I assume any behavior other than what's coded in the get and
set methods?

I need to track down a more advanced text than the ones I have, either
that or dig into the IL.

The immediate solution is to code a private data member, or just
follow the Java convention of getter and setter methods.

Thanks folks!
 
It's exactly the same as in Java - you don't *have* to have a
private field for a property there either, but you almost always do.
If a field was provided for you by the property, why would anyone
bother including their own? <<

Exactly my thinking. Anyway, from examining the IL I can see that now.
It's just that I read way too much into the Property keyword, thinking
that it would automatically define a private member variable for me
and that that would be the real "syntactic sugar".
than VB.NET is, and the C# specification is pretty good on this kind
of thing. <<

Yeah, except that I got this certification thing going on, at least
that's the plan. I'm not totlly alien to MS technologies, having
worked in VB6 and ASP in the past. Now I'm concentrating on VB and the
Framework since C#, to me, is what Java would have been had Sun
devloped it in the late 90's instead of when they did. What I mean is
that C# seems like a natural evolution of Java, much like Java was a
natural evolution what came before it.
 
Back
Top