Makes no sense! (I think) 
Author Message
 Makes no sense! (I think)

I am dynamically creating serilization formatters based on
a users choice.  Both object have a "Serialize" method.  
If I place the object creation with an if statement and
make the call outside of the if statement the compiler is
not capable of realizing at runtime that the "right"
serialize call will happen.  Is there a reason for this?  
It tells me on the call to "Serialize" that the object is
not declared yet ... but it is.  Of course I can get
around this, I was just looking for an explination.

Here is the code:

If Me.radBinary.Checked Then
   Dim objSerialize As New BinaryFormatter()
   Dim strExtension As String = ".bin"
ElseIf Me.radXML.Checked Then
   Dim objSerialize As New XmlSerializer(GetType(CDog))
   Dim strExtension As String = ".xml"
End If
Dim fstFileStream As New System.IO.FileStream("DigitalDog"
& strExtension, IO.FileMode.Open, IO.FileAccess.Read,
IO.FileShare.None)

x = objSerialize.Deserialize(fstFileStream)



Wed, 07 Apr 2004 06:13:22 GMT  
 Makes no sense! (I think)
I would really avoid having multiple declarations for a single variable (if
at all possible). I'm even a bit surprised it compiles (are you using Option
Strict and Option Explicit ?). At compile time the compiler can't know what
will be objSerialize.

If both types are inherited from the same class or if they implement the
same interface declare the object as being this class or this interface and
just put the initialization in those conditional branchs.

If they are not related at all one with another (which is possible even if
they have a method that just happens to use the same name), use a distinct
variable for each.

Patrice



Quote:
> I am dynamically creating serilization formatters based on
> a users choice.  Both object have a "Serialize" method.
> If I place the object creation with an if statement and
> make the call outside of the if statement the compiler is
> not capable of realizing at runtime that the "right"
> serialize call will happen.  Is there a reason for this?
> It tells me on the call to "Serialize" that the object is
> not declared yet ... but it is.  Of course I can get
> around this, I was just looking for an explination.

> Here is the code:

> If Me.radBinary.Checked Then
>    Dim objSerialize As New BinaryFormatter()
>    Dim strExtension As String = ".bin"
> ElseIf Me.radXML.Checked Then
>    Dim objSerialize As New XmlSerializer(GetType(CDog))
>    Dim strExtension As String = ".xml"
> End If
> Dim fstFileStream As New System.IO.FileStream("DigitalDog"
> & strExtension, IO.FileMode.Open, IO.FileAccess.Read,
> IO.FileShare.None)

> x = objSerialize.Deserialize(fstFileStream)



Thu, 08 Apr 2004 06:37:41 GMT  
 Makes no sense! (I think)
First of all, it is bad practice to not put all your Dim lines at the top of the function. If you scatter your declarations, then it makes it harder to find out what all the variables are in a particular function.

Secondly, mixing declarative and procedural code isn't generally a good idea. Consider the line...
    Dim objSerialize As New BinaryFormatter()
The "Dim objSerialize As BinaryFormatter" part is declarative, it describes the sate of the world. The "objSerialize = New BinaryFormatter()" part is procedural, it happens when the instruction pointer gets to that line. By mixing the two, you create a bit of confusion about what happens when.

But enough of the brow beating, on to the solution...

VB.Net uses what is known as Block Level variables. Simply put, the first "objSerialize" only exists between the "If" and "ElseIf" lines. The second "objSerialize" only exists between the "ElseIf" and "End If" lines. So when you get down to the "fstFileStream" line, neither version still exists.

What follows is what you code should look like if you followed the same pattern. Notice that I used two different variables for objSerialize. I did this because they were different type with no common ancestry.

   Dim objSerializeA As BinaryFormatter
   Dim strExtension As String
   Dim objSerializeB As XmlSerializer
    Dim fstFileStream As System.IO.FileStream

If Me.radBinary.Checked Then
   objSerializeA = New BinaryFormatter()
   strExtension As String = ".bin"
ElseIf Me.radXML.Checked Then
   objSerializeB = New XmlSerializer(GetType(CDog))
   strExtension As String = ".xml"
End If

fstFileStream = New System.IO.FileStream("DigitalDog"
& strExtension, IO.FileMode.Open, IO.FileAccess.Read,
IO.FileShare.None)

If Me.radBinary.Checked Then
    x = objSerializeA.Deserialize(fstFileStream)
ElseIf Me.radXML.Checked Then
    x = objSerializeB.Deserialize(fstFileStream)
End If

--
Jonathan Allen

Quote:

> I am dynamically creating serilization formatters based on
> a users choice.  Both object have a "Serialize" method.  
> If I place the object creation with an if statement and
> make the call outside of the if statement the compiler is
> not capable of realizing at runtime that the "right"
> serialize call will happen.  Is there a reason for this?  
> It tells me on the call to "Serialize" that the object is
> not declared yet ... but it is.  Of course I can get
> around this, I was just looking for an explination.

> Here is the code:

> If Me.radBinary.Checked Then
>    Dim objSerialize As New BinaryFormatter()
>    Dim strExtension As String = ".bin"
> ElseIf Me.radXML.Checked Then
>    Dim objSerialize As New XmlSerializer(GetType(CDog))
>    Dim strExtension As String = ".xml"
> End If
> Dim fstFileStream As New System.IO.FileStream("DigitalDog"
> & strExtension, IO.FileMode.Open, IO.FileAccess.Read,
> IO.FileShare.None)

> x = objSerialize.Deserialize(fstFileStream)



Thu, 08 Apr 2004 10:13:00 GMT  
 Makes no sense! (I think)
When you use a Dim statement within a code block, it is not accessible
outside that block
Blocks include If..End If , Do..Loop, etc , so on the line
    x = objSerialize.Deserialize(fstFileStream)
, objSerialize is not defined just as the compiler errors states

If you want to do this sort of thing, use the common interface/base class,
and declare a
variable of that type (assuming there is one..I haven't played with
Serialization yet) and
define it at a more appropriate scope (ie before the Dim statement)
--
Chris Anderson
(aka Merak on VISBAS-L)


Quote:
> I am dynamically creating serilization formatters based on
> a users choice.  Both object have a "Serialize" method.
> If I place the object creation with an if statement and
> make the call outside of the if statement the compiler is
> not capable of realizing at runtime that the "right"
> serialize call will happen.  Is there a reason for this?
> It tells me on the call to "Serialize" that the object is
> not declared yet ... but it is.  Of course I can get
> around this, I was just looking for an explination.

> Here is the code:

> If Me.radBinary.Checked Then
>    Dim objSerialize As New BinaryFormatter()
>    Dim strExtension As String = ".bin"
> ElseIf Me.radXML.Checked Then
>    Dim objSerialize As New XmlSerializer(GetType(CDog))
>    Dim strExtension As String = ".xml"
> End If
> Dim fstFileStream As New System.IO.FileStream("DigitalDog"
> & strExtension, IO.FileMode.Open, IO.FileAccess.Read,
> IO.FileShare.None)

> x = objSerialize.Deserialize(fstFileStream)



Thu, 08 Apr 2004 10:59:28 GMT  
 Makes no sense! (I think)
On Sat, 20 Oct 2001 19:13:00 -0700, "Jonathan Allen"

Quote:

>First of all, it is bad practice to not put all your Dim lines at the =
>top of the function. If you scatter your declarations, then it makes it =
>harder to find out what all the variables are in a particular function.

I don't think the Microsoft designers will agree with you here.
Because in VB.NET you can isolate the scope of a variable within, say,
an If/End If block, something you couldn't do in classic VB. They did
this for a reason. If you continue placing all Dim's at the top, any
intended benefit of isolated variable scope will be lost.

MM



Thu, 08 Apr 2004 19:02:09 GMT  
 Makes no sense! (I think)

Quote:
> On Sat, 20 Oct 2001 19:13:00 -0700, "Jonathan Allen"

> >First of all, it is bad practice to not put all your Dim lines at the =
> >top of the function. If you scatter your declarations, then it makes it =
> >harder to find out what all the variables are in a particular function.

> I don't think the Microsoft designers will agree with you here.
> Because in VB.NET you can isolate the scope of a variable within, say,
> an If/End If block, something you couldn't do in classic VB. They did
> this for a reason. If you continue placing all Dim's at the top, any
> intended benefit of isolated variable scope will be lost.

I agree
It *used* to be considered bad practise, but then it was also bad practise
to use data binding, etc

With new versions and new technologies, all the things we take for granted
or consider bad form
need to be re-addressed and re-analyzed IMHO
--
Chris Anderson
(aka Merak on VISBAS-L)



Fri, 09 Apr 2004 03:00:04 GMT  
 Makes no sense! (I think)
Until they build full support for block-level variables, I don't care what MS says.

--
Jonathan Allen

Quote:

> On Sat, 20 Oct 2001 19:13:00 -0700, "Jonathan Allen"

> >First of all, it is bad practice to not put all your Dim lines at the =
> >top of the function. If you scatter your declarations, then it makes it =
> >harder to find out what all the variables are in a particular function.

> I don't think the Microsoft designers will agree with you here.
> Because in VB.NET you can isolate the scope of a variable within, say,
> an If/End If block, something you couldn't do in classic VB. They did
> this for a reason. If you continue placing all Dim's at the top, any
> intended benefit of isolated variable scope will be lost.

> MM



Fri, 09 Apr 2004 04:07:02 GMT  
 Makes no sense! (I think)
Ahhh I see.  Well explained ... thanks.

Quote:
>-----Original Message-----
>First of all, it is bad practice to not put all your Dim

lines at the top of the function. If you scatter your
declarations, then it makes it harder to find out what all
the variables are in a particular function.
Quote:

>Secondly, mixing declarative and procedural code isn't

generally a good idea. Consider the line...
Quote:
>    Dim objSerialize As New BinaryFormatter()
>The "Dim objSerialize As BinaryFormatter" part is

declarative, it describes the sate of the world.
The "objSerialize = New BinaryFormatter()" part is
procedural, it happens when the instruction pointer gets
to that line. By mixing the two, you create a bit of
confusion about what happens when.
Quote:

>But enough of the brow beating, on to the solution...

>VB.Net uses what is known as Block Level variables.

Simply put, the first "objSerialize" only exists between
the "If" and "ElseIf" lines. The second "objSerialize"
only exists between the "ElseIf" and "End If" lines. So
when you get down to the "fstFileStream" line, neither
version still exists.
Quote:

>What follows is what you code should look like if you

followed the same pattern. Notice that I used two
different variables for objSerialize. I did this because
they were different type with no common ancestry.
Quote:

>   Dim objSerializeA As BinaryFormatter
>   Dim strExtension As String
>   Dim objSerializeB As XmlSerializer
>    Dim fstFileStream As System.IO.FileStream

>If Me.radBinary.Checked Then
>   objSerializeA = New BinaryFormatter()
>   strExtension As String = ".bin"
>ElseIf Me.radXML.Checked Then
>   objSerializeB = New XmlSerializer(GetType(CDog))
>   strExtension As String = ".xml"
>End If

>fstFileStream = New System.IO.FileStream("DigitalDog"
>& strExtension, IO.FileMode.Open, IO.FileAccess.Read,
>IO.FileShare.None)

>If Me.radBinary.Checked Then
>    x = objSerializeA.Deserialize(fstFileStream)
>ElseIf Me.radXML.Checked Then
>    x = objSerializeB.Deserialize(fstFileStream)
>End If

>--
>Jonathan Allen




- Show quoted text -

Quote:
>> I am dynamically creating serilization formatters based
on
>> a users choice.  Both object have a "Serialize"
method.  
>> If I place the object creation with an if statement and
>> make the call outside of the if statement the compiler
is
>> not capable of realizing at runtime that the "right"
>> serialize call will happen.  Is there a reason for
this?  
>> It tells me on the call to "Serialize" that the object
is
>> not declared yet ... but it is.  Of course I can get
>> around this, I was just looking for an explination.

>> Here is the code:

>> If Me.radBinary.Checked Then
>>    Dim objSerialize As New BinaryFormatter()
>>    Dim strExtension As String = ".bin"
>> ElseIf Me.radXML.Checked Then
>>    Dim objSerialize As New XmlSerializer(GetType(CDog))
>>    Dim strExtension As String = ".xml"
>> End If
>> Dim fstFileStream As New System.IO.FileStream
("DigitalDog"
>> & strExtension, IO.FileMode.Open, IO.FileAccess.Read,
>> IO.FileShare.None)

>> x = objSerialize.Deserialize(fstFileStream)

>.



Fri, 09 Apr 2004 22:31:11 GMT  
 Makes no sense! (I think)
Actually he is still correct, though I would word it as all Dim's should be
declared at the beginning of any scope for which they are needed. His point
being, that declaring them at the beginning of their scope follows a more
structured programming style and declaring them where you need them this is
bad form. I totally agree with this...


Quote:
> On Sat, 20 Oct 2001 19:13:00 -0700, "Jonathan Allen"

> >First of all, it is bad practice to not put all your Dim lines at the =
> >top of the function. If you scatter your declarations, then it makes it =
> >harder to find out what all the variables are in a particular function.

> I don't think the Microsoft designers will agree with you here.
> Because in VB.NET you can isolate the scope of a variable within, say,
> an If/End If block, something you couldn't do in classic VB. They did
> this for a reason. If you continue placing all Dim's at the top, any
> intended benefit of isolated variable scope will be lost.

> MM



Fri, 09 Apr 2004 22:52:05 GMT  
 Makes no sense! (I think)
Full support for block-level variables? Are you talking about the fact that
the variable isn't deallocated when it goes out of block scope? If so, I
agree. Seems to me this behavior causes undue confusion and could lead to
some hard-to-find bugs. If they're going to implement block-level scoping,
they should do it all the way.

Then again, while I'm no fan of C/C++/C#, I am kinda partial to most the
C-inspired changes like zero-based arrays, conditional short circuiting,
etc...

Tim Overbay


Until they build full support for block-level variables, I don't care what
MS says.

--
Jonathan Allen


Quote:
> On Sat, 20 Oct 2001 19:13:00 -0700, "Jonathan Allen"

> >First of all, it is bad practice to not put all your Dim lines at the =
> >top of the function. If you scatter your declarations, then it makes it =
> >harder to find out what all the variables are in a particular function.

> I don't think the Microsoft designers will agree with you here.
> Because in VB.NET you can isolate the scope of a variable within, say,
> an If/End If block, something you couldn't do in classic VB. They did
> this for a reason. If you continue placing all Dim's at the top, any
> intended benefit of isolated variable scope will be lost.

> MM



Sat, 10 Apr 2004 06:26:50 GMT  
 Makes no sense! (I think)

Quote:
> Are you talking about the fact that
> the variable isn't deallocated when it goes out of block scope?

I wasn't, but I will definitely consider adding that to my list. (There may
be a problem with that if the user is Goto Happy. )

My concerns include the fact that you cannot declare variables in the
construct header. For example..

    For X As Integer = 1 To 10
    For Each Y As Object In MyArrayList
    Catch Z as Exception When A > 0

Actually, they support the last one. So why not the others?

Also, there are no arbitrary blocks. I would like to be able to write...

Block
    //Dim variables only needed right here

    //use said variables
End Block

I can fake it with a phony If statement, but it isn't really worth it.

--
Jonathan Allen


Quote:
> Full support for block-level variables? Are you talking about the fact
that
> the variable isn't deallocated when it goes out of block scope? If so, I
> agree. Seems to me this behavior causes undue confusion and could lead to
> some hard-to-find bugs. If they're going to implement block-level scoping,
> they should do it all the way.

> Then again, while I'm no fan of C/C++/C#, I am kinda partial to most the
> C-inspired changes like zero-based arrays, conditional short circuiting,
> etc...

> Tim Overbay



> Until they build full support for block-level variables, I don't care what
> MS says.

> --
> Jonathan Allen



> > On Sat, 20 Oct 2001 19:13:00 -0700, "Jonathan Allen"

> > >First of all, it is bad practice to not put all your Dim lines at the =
> > >top of the function. If you scatter your declarations, then it makes it
=
> > >harder to find out what all the variables are in a particular function.

> > I don't think the Microsoft designers will agree with you here.
> > Because in VB.NET you can isolate the scope of a variable within, say,
> > an If/End If block, something you couldn't do in classic VB. They did
> > this for a reason. If you continue placing all Dim's at the top, any
> > intended benefit of isolated variable scope will be lost.

> > MM



Sat, 10 Apr 2004 06:54:06 GMT  
 Makes no sense! (I think)

Quote:
> Also, there are no arbitrary blocks. I would like to be able to write...

> Block
>     //Dim variables only needed right here

>     //use said variables
> End Block

I had this conversation with someone the other day and I had difficulty seeing where something like this is necessary.  I can see the point of local procedures, but what kind of benefits would you get from something like this?

--
Jacob Grass
Microsoft .NET MVP



Sat, 10 Apr 2004 22:22:37 GMT  
 Makes no sense! (I think)
Quote:
> I can see the point of local procedures, but what kind of benefits would

you get from something like this?

I would get the same benefit as one gets from regular block-level scoping,
the ability to segment code into logical sections and isolate of variables
to just where they are used.

Lets say I needed some file handling in a long function.

Dim oFile
Try
    oFile.Open
    //use the file
Catch
    //handle the error
Finally
    if oFile.IsOpen then oFile.Close
End Try

I can't use block-level scoping because the Dim lines must be outside the
Try block. What's the point of  having block level scoping if it cannot be
used in a general way?

--
Jonathan Allen



Quote:
> Also, there are no arbitrary blocks. I would like to be able to write...

> Block
>     //Dim variables only needed right here

>     //use said variables
> End Block

I had this conversation with someone the other day and I had difficulty
seeing where something like this is necessary.  I can see the point of local
procedures, but what kind of benefits would you get from something like
this?

--
Jacob Grass
Microsoft .NET MVP



Sun, 11 Apr 2004 02:39:20 GMT  
 Makes no sense! (I think)
Sounds good. . . I hadn't even noticed about not being able to access variables Dimmed in the Try block from the Catch block.  That seems rather silly. . .

--
Jacob Grass
Microsoft .NET MVP

Quote:

> > I can see the point of local procedures, but what kind of benefits would
> you get from something like this?

> I would get the same benefit as one gets from regular block-level scoping,
> the ability to segment code into logical sections and isolate of variables
> to just where they are used.

> Lets say I needed some file handling in a long function.

> Dim oFile
> Try
>     oFile.Open
>     //use the file
> Catch
>     //handle the error
> Finally
>     if oFile.IsOpen then oFile.Close
> End Try

> I can't use block-level scoping because the Dim lines must be outside the
> Try block. What's the point of  having block level scoping if it cannot be
> used in a general way?

> --
> Jonathan Allen



> > Also, there are no arbitrary blocks. I would like to be able to write...

> > Block
> >     //Dim variables only needed right here

> >     //use said variables
> > End Block

> I had this conversation with someone the other day and I had difficulty
> seeing where something like this is necessary.  I can see the point of local
> procedures, but what kind of benefits would you get from something like
> this?

> --
> Jacob Grass
> Microsoft .NET MVP



Sun, 11 Apr 2004 03:17:16 GMT  
 Makes no sense! (I think)
Others have, the hard way. At least once a week I see a problem that turns
out to be a variable Dimmed in the wrong place. In fact, this was the first
thread I can remember where it wasn't a Try block that caused the problem.

--
Jonathan Allen



Sounds good. . . I hadn't even noticed about not being able to access
variables Dimmed in the Try block from the Catch block.  That seems rather
silly. . .

--
Jacob Grass
Microsoft .NET MVP


Quote:
> > I can see the point of local procedures, but what kind of benefits would
> you get from something like this?

> I would get the same benefit as one gets from regular block-level scoping,
> the ability to segment code into logical sections and isolate of variables
> to just where they are used.

> Lets say I needed some file handling in a long function.

> Dim oFile
> Try
>     oFile.Open
>     //use the file
> Catch
>     //handle the error
> Finally
>     if oFile.IsOpen then oFile.Close
> End Try

> I can't use block-level scoping because the Dim lines must be outside the
> Try block. What's the point of  having block level scoping if it cannot be
> used in a general way?

> --
> Jonathan Allen



> > Also, there are no arbitrary blocks. I would like to be able to write...

> > Block
> >     //Dim variables only needed right here

> >     //use said variables
> > End Block

> I had this conversation with someone the other day and I had difficulty
> seeing where something like this is necessary.  I can see the point of
local
> procedures, but what kind of benefits would you get from something like
> this?

> --
> Jacob Grass
> Microsoft .NET MVP



Sun, 11 Apr 2004 13:14:39 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. VBX makes sense, OCX makes sense - What is OCA?

2. making sense of access form design

3. Making sense out of binary data

4. Does it makes any sense? (Working with MSComm)

5. Making sense of AVI_COMPRESS_OPTIONS

6. IE5 Thinks its made by Netscape

7. making a program think it isnt open

8. making a program think it isnt open

9. Thinking about WinHelp Tools? Think $$$

10. Rediculous error makes no sense! Please help!

11. this makes NO SENSE! help...

12. Help! This Makes No Sense!

 

 
Powered by phpBB® Forum Software