CType travesty

[matt Doig]

I have been working with the DOM in vb.net and am forced to explicitly convert
from a node to an element. This forces me to use the worst casting operator
ever invented; the CType function.

What were they thinking when they chose to implement casting as function
in an object oriented language?

Why not allow something like this:

dim x as XMLElement
x = nodelist(x).item as XMLElement

or
dim x as XMLElement
x = nodelist(x).item:XMLElement

Does anybody else find the CType function as obnoxious as i do?
matt

[Cali LaFollett]

> Does anybody else find the CType function as obnoxious as i do?

I agree but this has been discussed before. So I will refrain from further
comment. ;-)
Cal

[Robert Lantry]

I'm not understanding your issue...

Dim x As XmlElement
Dim y As XmlNodeList

Dim doc As New XmlDocument()

doc.LoadXml("<root><foo>Test</foo><foo>Test2></foo></root>")

y = doc.SelectNodes("root/foo")
x = y.Item(0)


This works...I guess I'm not understanding what it is you want?

--
- Robert

Being pestered by poltergeists? Possessed by demons? Having trouble
understanding .NET?
Then immediately Visit HillHouse Psychic Investigators!

http://www.psychicdetectives.com/main.htm

"matt Doig" <mattd@bt1.com> wrote in message news:3c88faa4$1@10.1.10.29...
>
> I have been working with the DOM in vb.net and am forced to explicitly
convert
> from a node to an element. This forces me to use the worst casting
operator
> ever invented; the CType function.
>
> What were they thinking when they chose to implement casting as function
> in an object oriented language?
>
> Why not allow something like this:
>
> dim x as XMLElement
> x = nodelist(x).item as XMLElement
>
> or
> dim x as XMLElement
> x = nodelist(x).item:XMLElement
>
> Does anybody else find the CType function as obnoxious as i do?
> matt

[Cali LaFollett]

> This works...I guess I'm not understanding what it is you want?

I think he means in more general terms vs. the exact example he provided.
Similar to C++/C# or even Object Pascal (Delphi) for that matter, there is
more af a Syntax casting than there is a function casting. (i.e.
(CSomeBaseObject)SomeSpecificObjectVariable vs.
CType(SomeSpecificObjectVariable, CSomeBaseObject))

Also note, there is another way to do casting in VB.NET althought it
ammounts to a simlar approach. For reference types, you can replace CType
with the DirectCast keyword. In the docs it states that it can ammount to a
slight performance increase over CType which does checking for conversions
in stead of a static cast.

Cal

[Robert Lantry]

His post said: "am forced to explicitly convert from a node to an element"

And I said, Huh? I don't see why he is forced to do this.

--
- Robert

Being pestered by poltergeists? Possessed by demons? Having trouble
understanding .NET?
Then immediately Visit HillHouse Psychic Investigators!

http://www.psychicdetectives.com/main.htm

"Cali LaFollett" <cali@no-spam-please-visionized.com> wrote in message
news:3c890382@10.1.10.29...
> > This works...I guess I'm not understanding what it is you want?
>
> I think he means in more general terms vs. the exact example he provided.
> Similar to C++/C# or even Object Pascal (Delphi) for that matter, there is
> more af a Syntax casting than there is a function casting. (i.e.
> (CSomeBaseObject)SomeSpecificObjectVariable vs.
> CType(SomeSpecificObjectVariable, CSomeBaseObject))
>
> Also note, there is another way to do casting in VB.NET althought it
> ammounts to a simlar approach. For reference types, you can replace CType
> with the DirectCast keyword. In the docs it states that it can ammount to
a
> slight performance increase over CType which does checking for conversions
> in stead of a static cast.
>
> Cal
>
>
>
>

[Jonathan Allen]

> dim x as XMLElement
> x = nodelist(x).item:XMLElement

That won't work because ":" already has a meaning. But you could use this...

x = nodelist(x).item?XMLElement

--
Jonathan Allen


"matt Doig" <mattd@bt1.com> wrote in message news:3c88faa4$1@10.1.10.29...
>
> I have been working with the DOM in vb.net and am forced to explicitly
convert
> from a node to an element. This forces me to use the worst casting
operator
> ever invented; the CType function.
>
> What were they thinking when they chose to implement casting as function
> in an object oriented language?
>
> Why not allow something like this:
>
> dim x as XMLElement
> x = nodelist(x).item as XMLElement
>
> or
> dim x as XMLElement
> x = nodelist(x).item:XMLElement
>
> Does anybody else find the CType function as obnoxious as i do?
> matt

[Jonathan Allen]

> And I said, Huh? I don't see why he is forced to do this.

Assuming that he wants the advantages of Option Strict, he is forced to do
that.

--
Jonathan Allen


"Robert Lantry" <mirth@mirthy.com> wrote in message
news:3c89048e$1@10.1.10.29...
> His post said: "am forced to explicitly convert from a node to an
element"
>
> And I said, Huh? I don't see why he is forced to do this.
>
> --
> - Robert
>
> Being pestered by poltergeists? Possessed by demons? Having trouble
> understanding .NET?
> Then immediately Visit HillHouse Psychic Investigators!
>
> http://www.psychicdetectives.com/main.htm
>
> "Cali LaFollett" <cali@no-spam-please-visionized.com> wrote in message
> news:3c890382@10.1.10.29...
> > > This works...I guess I'm not understanding what it is you want?
> >
> > I think he means in more general terms vs. the exact example he
provided.
> > Similar to C++/C# or even Object Pascal (Delphi) for that matter, there
is
> > more af a Syntax casting than there is a function casting. (i.e.
> > (CSomeBaseObject)SomeSpecificObjectVariable vs.
> > CType(SomeSpecificObjectVariable, CSomeBaseObject))
> >
> > Also note, there is another way to do casting in VB.NET althought it
> > ammounts to a simlar approach. For reference types, you can replace
CType
> > with the DirectCast keyword. In the docs it states that it can ammount
to
> a
> > slight performance increase over CType which does checking for
conversions
> > in stead of a static cast.
> >
> > Cal
> >
> >
> >
> >
>
>

[Jonathan Allen]

> In the docs it states that it can ammount to a
> slight performance increase over CType which does checking for conversions
> in stead of a static cast.

I checked the IL, and for object types there is no difference. However,
there is a difference when unboxing is involved.

--
Jonathan Allen


"Cali LaFollett" <cali@no-spam-please-visionized.com> wrote in message
news:3c890382@10.1.10.29...
> > This works...I guess I'm not understanding what it is you want?
>
> I think he means in more general terms vs. the exact example he provided.
> Similar to C++/C# or even Object Pascal (Delphi) for that matter, there is
> more af a Syntax casting than there is a function casting. (i.e.
> (CSomeBaseObject)SomeSpecificObjectVariable vs.
> CType(SomeSpecificObjectVariable, CSomeBaseObject))
>
> Also note, there is another way to do casting in VB.NET althought it
> ammounts to a simlar approach. For reference types, you can replace CType
> with the DirectCast keyword. In the docs it states that it can ammount to
a
> slight performance increase over CType which does checking for conversions
> in stead of a static cast.
>
> Cal
>
>
>
>

[Cali LaFollett]

> > In the docs it states that it can ammount to a
> > slight performance increase over CType which does checking for
conversions
> > in stead of a static cast.
>
> I checked the IL, and for object types there is no difference. However,
> there is a difference when unboxing is involved.

I am assuming that the difference in the "performance increase" that is
mentioned in the DirectCast help doc then huh?

Cal

[matt Doig]

I still think the ":" operator is a better choice since it's a bit easier
to read, seems related to the "." operator, and most importantly would prevent
horizontal programming that a programmer i work with is so fond of.

I guess what i'm dismayed about is that the mvp's who were so passionate
about getting "and" changed back to bitwise and declaring arrays with one
more item that they should have were not passionate about getting a real
casting mechanism.

matt

>That won't work because ":" already has a meaning. But you could use this...
>
>x = nodelist(x).item?XMLElement
>
>--
>Jonathan Allen

[Jonathan Allen]

> I guess what i'm dismayed about is that the mvp's who were so passionate
> about getting "and" changed back to bitwise and declaring arrays with one
> more item that they should have were not passionate about getting a real
> casting mechanism.

While CType may not be the best way, it is still better that C's method.


--
Jonathan Allen


"matt Doig" <mattd@bt1.com> wrote in message news:3c8917ea$1@10.1.10.29...
>
> I still think the ":" operator is a better choice since it's a bit easier
> to read, seems related to the "." operator, and most importantly would
prevent
> horizontal programming that a programmer i work with is so fond of.
>
> I guess what i'm dismayed about is that the mvp's who were so passionate
> about getting "and" changed back to bitwise and declaring arrays with one
> more item that they should have were not passionate about getting a real
> casting mechanism.
>
> matt
>
> >That won't work because ":" already has a meaning. But you could use
this...
> >
> >x = nodelist(x).item?XMLElement
> >
> >--
> >Jonathan Allen
>
>
>

[David Bayley]

matt Doig <mattd@bt1.com> wrote in message news:3c88faa4$1@10.1.10.29...

> or
> dim x as XMLElement
> x = nodelist(x).item:XMLElement
>
> Does anybody else find the CType function as obnoxious as i do?
> matt

Yes, it's ugly isn't it. The C# syntax isn't any better either.

How about leaving Option Strict Off, and writing unit tests instead. Then
you won't have this problem, and your code will be more reliable and easier
to maintain to boot.

Even better, you'll be able to taunt those Java/C# cowards (me) who don't
have the option of dynamic typing. If they give you any ****, then just
highlight some large Fortune-100 Smalltalk projects that have survived
without strict typing, and then point out that VB.NET is even better
(Smallscript withstanding) since it provides static typing as well whenever
you need it for clarity, performance and intellisense.

If all else fails, then a practical example of MS-Office automation will be
invaluable.

--
David.

[Cali LaFollett]

> I am assuming that the difference in the "performance increase" that is
> mentioned in the DirectCast help doc then huh?

Should have read:

I am assuming that IS the difference in the "performance increase" that is
mentioned in the DirectCast help doc then huh?

Sorry :(