VB and implicit conversions

[Chad Z. Hower aka Kudzu]

I have an implicit conversion set up in an assembly from a Stream to
something else. In C#, it works. In VB it does not.

Does VB support implicit conversions? And if so any idea why it would work in
a C# program but not VB?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Klaus Löffelmann]

Chad,

no, VB doesn't support implicit castings in the current version. That is, it
doesn't support implicit castings from non-primitive types. Only Whidbey
will support that (and hopefully it will be produce code that is compatible
with the code generated by C# when using the implicit operator); in the
meanwhile, you have to use the DirectCast keyword to unbox an object.

Klaus

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb im Newsbeitrag
news:Xn******************@127.0.0.1...

I have an implicit conversion set up in an assembly from a Stream to
something else. In C#, it works. In VB it does not.

Does VB support implicit conversions? And if so any idea why it would work in a C# program but not VB?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in
news:40**********************@news.freenet.de:

Whidbey will support that (and hopefully it will be produce code that is
compatible with the code generated by C# when using the implicit
operator); in the meanwhile, you have to use the DirectCast keyword to
unbox an object.

Ack. :(

I understand that there are differences between VB and C#. But how can MS
leave someting like this out? Esp from VB, the king language of anti type
safety. Where you could string = integer. :(

Can you give me an example of DirectCast?

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Armin Zingler]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb

I have an implicit conversion set up in an assembly from a Stream to
something else. In C#, it works. In VB it does not.

Does VB support implicit conversions? And if so any idea why it would
work in a C# program but not VB?

Code?
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Cor]

Hi Kudzu,

Inclusive the integer to string, although it is originaly Armin territory
because of that sample.
:-))

Dim a As Object
a = 1
Dim b As Integer
b = DirectCast(a, Integer)
MessageBox.Show(b.ToString)

Cor

[Klaus Löffelmann]

Chad,

I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set

Option Strict True

at the beginning of each source file or in the project settings.With this
setting, you can only cast those types implicitly, which are implicitly
castable in C#, too.

To provide more background: VB internally uses a special flag to recognize a
type for casting implicitly. When you write a static operator implicit
function with C#, C# generates a procedure called op_implicit, if I remember
correctly. You can use this function from VB, too, but only by this name (so
it's not implicitly usable, obviously...)

However, you can't set the flag from C# (and, unfortunately, neither from
VB), so a type conversion could be done implicitly from VB.

But DirectCast works fine in VB:

Dim var as mySpecialObject=DirectCast(specialObjectBoxedInWha tEverType,
mySpecialObject)

Keep in mind, that DirectCast only does the same as the cast operator does
in C#: (In this example specialObjectBoxedInWhatEverType boxed an object of
type mySpecialObject). It just unboxes a type. If you really want to do a
type conversion from one type to another, you should provide a constructor
with a parameter for your class, you could use like this:

Dim var as new mySpecialObject(OtherSpecialObjectToCastFrom).

In the constructor for mySpecialObject provide the code for the actual
conversion.

Klaus.


"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb im Newsbeitrag
news:Xn******************@127.0.0.1...

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in
news:40**********************@news.freenet.de:

Whidbey will support that (and hopefully it will be produce code that is
compatible with the code generated by C# when using the implicit
operator); in the meanwhile, you have to use the DirectCast keyword to
unbox an object.

Ack. :(

I understand that there are differences between VB and C#. But how can MS
leave someting like this out? Esp from VB, the king language of anti type
safety. Where you could string = integer. :(

Can you give me an example of DirectCast?

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Cor" <no*@non.com> wrote in news:uS**************@TK2MSFTNGP12.phx.gbl:

Dim a As Object
a = 1
Dim b As Integer
b = DirectCast(a, Integer)
MessageBox.Show(b.ToString)

Thanks. A direct conversion will be much easier than that. :(

But thanks for the answer.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Armin Zingler" <az*******@freenet.de> wrote in news:uiS5Hoy5DHA.2392
@TK2MSFTNGP11.phx.gbl:

Does VB support implicit conversions? And if so any idea why it would
work in a C# program but not VB?

Code?

Its the very last VB example here:
http://www.atozed.com/indy/Texts/VSIntro.iwp

You can see the C# version directly above it. The parameter type to the Get
method is Borland.VCL.Classes.TStrings, which has an implict operator added
to it that allows conversion to it from System.IO.Stream.

It looks like VB users might have to do direct conversions, which at least is
easyer than the DirectBox exmaple posted here.

That is something like:

new TCLRStream(MyStream)

instead of just:

MyStream

whenever TStrings is needed.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in
news:40**********************@news.freenet.de:

I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set
Yes, its been cleaned up in .net. I just find it ironic that traditionaly
VB has been anything but typesafe, in fact explicitly breaking it. And now
that they've cleaned it up, they gave C# implicit covnersion, but not VB.
Option Strict True
Yes I have this. But its my understanding that this applies to being able
to put integers into short ints, and the type off poor variations that VB
used to be rampant with.
at the beginning of each source file or in the project settings.With
this setting, you can only cast those types implicitly, which are
implicitly castable in C#, too.
But it applies only to ordinals, etc AFAIK.
To provide more background: VB internally uses a special flag to
recognize a type for casting implicitly. When you write a static
operator implicit function with C#, C# generates a procedure called
op_implicit, if I remember correctly. You can use this function from VB,
too, but only by this name (so it's not implicitly usable, obviously...)
Yes, exactly. :)
However, you can't set the flag from C# (and, unfortunately, neither
from VB), so a type conversion could be done implicitly from VB.
Exactly the problem it seems. :(
But DirectCast works fine in VB:

Dim var as mySpecialObject=DirectCast(specialObjectBoxedInWha tEverType,
mySpecialObject)
specialObjectBoxedInWhatEverType would be in my case System.IO.Stream
(Source) or Borland.VCL.Classes.TStrings (Destination)?
Keep in mind, that DirectCast only does the same as the cast operator
does in C#: (In this example specialObjectBoxedInWhatEverType boxed an
object of type mySpecialObject). It just unboxes a type. If you really
Is this the destination type or the source tyep though?
want to do a type conversion from one type to another, you should
provide a constructor with a parameter for your class, you could use
like this:

Already have that, and thats what the implicit operator does. However the
point is that this conversion is used often to pass in an argument, and the
idea was to free the user from needing to know there was even a difference.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Armin Zingler]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb

"Armin Zingler" <az*******@freenet.de> wrote in
news:uiS5Hoy5DHA.2392 @TK2MSFTNGP11.phx.gbl:

Does VB support implicit conversions? And if so any idea why it
would work in a C# program but not VB?

Code?

Its the very last VB example here:
http://www.atozed.com/indy/Texts/VSIntro.iwp

You can see the C# version directly above it. The parameter type to
the Get method is Borland.VCL.Classes.TStrings, which has an implict
operator added to it that allows conversion to it from
System.IO.Stream.

It looks like VB users might have to do direct conversions, which at
least is easyer than the DirectBox exmaple posted here.

That is something like:

new TCLRStream(MyStream)

instead of just:

MyStream

whenever TStrings is needed.

What is an "implicit operator"? Currently I don't understand the problem.
I'm happy now that I have to cast explicitly, otherwise casting errors might
occur at runtime because I don't get a error message at compile time.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Chad Z. Hower aka Kudzu]

"Armin Zingler" <az*******@freenet.de> wrote in
news:Or**************@TK2MSFTNGP11.phx.gbl:

What is an "implicit operator"? Currently I don't understand the
problem. I'm happy now that I have to cast explicitly, otherwise casting
errors might occur at runtime because I don't get a error message at
compile time.

An implicit conversion is performed by an implicit operator in C#.

That is when I need to convert between two types, .net "asks" the destination
if it know how to convert the source into a compatible type. This is how the
ordinal types work internally.

You could never get them at runtime - C# resolves them at compile time and
only allows conversions that have "handlers" to do so. Basically C# auto
"casts" (its not truly cast in the traditional sense, but more of a
conversion) to the other type.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Klaus Löffelmann]

Chad,

see inlines...

Klaus

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb im Newsbeitrag
news:Xn******************@127.0.0.1...

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in
news:40**********************@news.freenet.de:

I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set
Yes, its been cleaned up in .net. I just find it ironic that traditionaly
VB has been anything but typesafe, in fact explicitly breaking it. And now
that they've cleaned it up, they gave C# implicit covnersion, but not VB.

Option Strict True

Yes I have this. But its my understanding that this applies to being able
to put integers into short ints, and the type off poor variations that VB
used to be rampant with.

at the beginning of each source file or in the project settings.With
this setting, you can only cast those types implicitly, which are
implicitly castable in C#, too.

But it applies only to ordinals, etc AFAIK.

To provide more background: VB internally uses a special flag to
recognize a type for casting implicitly. When you write a static
operator implicit function with C#, C# generates a procedure called
op_implicit, if I remember correctly. You can use this function from VB,
too, but only by this name (so it's not implicitly usable, obviously...)

Yes, exactly. :)

However, you can't set the flag from C# (and, unfortunately, neither
from VB), so a type conversion could be done implicitly from VB.

Exactly the problem it seems. :(

But DirectCast works fine in VB:

Dim var as mySpecialObject=DirectCast(specialObjectBoxedInWha tEverType,
mySpecialObject)

specialObjectBoxedInWhatEverType would be in my case System.IO.Stream
(Source) or Borland.VCL.Classes.TStrings (Destination)?

Keep in mind, that DirectCast only does the same as the cast operator
does in C#: (In this example specialObjectBoxedInWhatEverType boxed an
object of type mySpecialObject). It just unboxes a type. If you really

Is this the destination type or the source tyep though?

mySpecialObject is the one, you like other types being casted to.
Further provide Toxxx-Methods for your "Special"-Object, to cast them back
to other types, and your done!

want to do a type conversion from one type to another, you should
provide a constructor with a parameter for your class, you could use
like this:
Already have that, and thats what the implicit operator does. However the
point is that this conversion is used often to pass in an argument, and

the idea was to free the user from needing to know there was even a difference.

But wouldn't you then create a "new old Visual Basic" behaviour, that you
don't like? I think, explicit casting does more for type safety than
implicit casting?!

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Armin Zingler]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb

"Armin Zingler" <az*******@freenet.de> wrote in
news:Or**************@TK2MSFTNGP11.phx.gbl:

What is an "implicit operator"? Currently I don't understand the
problem. I'm happy now that I have to cast explicitly, otherwise
casting errors might occur at runtime because I don't get a error
message at compile time.

An implicit conversion is performed by an implicit operator in C#.

That is when I need to convert between two types, .net "asks" the
destination if it know how to convert the source into a compatible
type. This is how the ordinal types work internally.

You could never get them at runtime - C# resolves them at compile
time and only allows conversions that have "handlers" to do so.
Basically C# auto "casts" (its not truly cast in the traditional
sense, but more of a conversion) to the other type.

Thanks for the explanation. I know too little about C#
--
Armin

[Chad Z. Hower aka Kudzu]

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in news:401a61d7$0
$1************@news.freenet.de:

mySpecialObject is the one, you like other types being casted to.
Further provide Toxxx-Methods for your "Special"-Object, to cast them back

Defeats the purpose unfortunately. It requires the user to interact
directly with the destination type.
But wouldn't you then create a "new old Visual Basic" behaviour, that you
don't like? I think, explicit casting does more for type safety than
implicit casting?!

No, because behaviour is well defined and among truly convertible types.
Formerly in VB you could do 2 + 2 + 1 and sometimes get 23 because of the
rules of conversion of data types when added / concatted. And the fact that
concat and add were the same symbol. | was only added later and they still
preverved +.

These conversions are well defined with rules about what can go where, and
do not create commonly abmigous circumstance. They also do not allow data
loss, or if they do they have strict rules about it and only at the
override of the user.

Im all too well acquainted with VB prior to .net.

I know I will offend some people - but VB *was* a horrible mess of a
language. VB.net finally fixed things - but unfortunately MS also seems to
have just tinkered in some spots too for no reason.

I started work in VB 1 for DOS, long before most of you probably ever heard
of VB. Prior to that in PDS which was VB's successor, at least in language.

I've worked very heavily in VB all the way up to 4 and did some work in 5
and 6 as well.

VB 3 was a decent language with some pitfalls. As a very active VB person
at the time and regular VB magazine contributor I was with the rest of the
community hopeful. But then MS totally let us down with 4.

VB4 was not only incredibly buggy (Curse of MS and version 4) but it was
abboration. They should have taken this opportunity to fix some of the
issues in VB3 as a langauge. Instead they did not fix them, but actually
took the language BACKWARDS.

I went Delphi as it came out at the same time. It had everything VB4 should
have had and more.

Its nice to see that VB.net has finally "Fixed" VB.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

And dont even get me started on the fact that VB had a "Option Implicit" in
it - let alone that it was the DEFAULT.

The number of bugs that this leads to is truly incredible, and only has a
place in scripting languages, if that.

Any mispelled variable becomes a new instance and instantly evaluates to 0.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in news:401a61d7$0
$1************@news.freenet.de:

> But DirectCast works fine in VB:
>
> Dim var as mySpecialObject=DirectCast(specialObjectBoxedInWha tEverType,
> mySpecialObject)

Thanks. This works, but its not really much better.

LHTTP.Get("http://www.atozed.com", DirectCast(LOutput,
Borland.Vcl.Classes.TStream))

As to you question of "isnt this the behaviour you hate?". The above would
not work if the two types were not compatible right? Well in C#, the same is
possible - but it does it automatically (And again, only if permitted):

LHTTP.Get("http://www.atozed.com", LOutput);

The difference is that C# does the direct cast automatically, while in VB the
user must perform it manually. Its still not desirable, but the other option
is:

LHTTP.Get("http://www.atozed.com", new Borland.Vcl.Classes.TCLRStream
(LOutput))

Im assuming the DirectCast is more preferable to a VB.net user? The one
disadvantage is not they must reference the Borland unit directly which as
you can see in the C# example is completely eliminated.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in
news:Xn******************@127.0.0.1:

And dont even get me started on the fact that VB had a "Option Implicit"
in it - let alone that it was the DEFAULT.

Ack. I just found out VB still has this option. :(

At least MS now reversed the default to explicit.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Armin Zingler" <az*******@freenet.de> wrote in news:Oea9wmz5DHA.2252
@TK2MSFTNGP10.phx.gbl:

Thanks for the explanation. I know too little about C#

No problem.

BTW - sorry if sounded forceful in my other replies. No disrespect intended -
Im just a very forceful in debates. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Cor]

Hi Kudzu,

And dont even get me started on the fact that VB had a "Option Implicit" in it - let alone that it was the DEFAULT.

The number of bugs that this leads to is truly incredible, and only has a
place in scripting languages, if that.

Should be, but it is introduced as a full upgradable product from VB6.

And it is widely is, but with a lot of disadvantages from VB6, and to make
it faster, you have to do a lot.

VB6 programs where never as fast as C++ and that is nowhere written.

The ones who start with a new program should set option Strict On in the
VS.net options, than you have not even to declare it and behaviour is as
you wish.

Just my 2Eurocent

Cor

[Cor]

Hi Kudzu,

Start a debat that is about VB.net without C# with Armin, than you will see
what is forceful
:-) although for this I can use the one Armin sometimes uses :->

Cor

[Chad Z. Hower aka Kudzu]

Ok. New question, same thread as its related. Take a look at the code
below. The line with the .Get is really the only one of importance.

Imports System.IO
Imports System.Text
Imports Indy.Sockets.IndyHTTP

Module Module1

Sub Main()
Dim LResult As String
Dim LHTTP As New HTTP

Dim LStream As New MemoryStream
Dim LOutput As New FileStream( _
New FileInfo
(System.Windows.Forms.Application.ExecutablePath). DirectoryName _
+ "\index.html", FileMode.Create)
LHTTP.Get("http://www.atozed.com", DirectCast(LOutput,
Borland.Vcl.Classes.TStream))
End Sub

End Module

Now I can chaneg it to:

LHTTP.Get("http://www.atozed.com", DirectCast(LOutput, TStream))

If the user adds:
Imports Borland.Vcl.Classes;

In C# neither of these are necessary because of implicit coversion, its all
done transparently. They dont even need the Imports (using in C#). We've
esatablished that.

That being said - there are 3 options to present to VB users. Can you tell
me which do you think would be the most desirable to VB users?

a) The solution above. Either with fully qualified TStream or adding it to
the Imports.

b) Same issue as above, but instead of DirectCast calling:

LHTTP.Get("http://www.atozed.com", new TCLRStream(LOutput))

This still needs to be fully qualified - or have the namespace added to
Imports.

c) We add a Convert function that is overloaded to Indy. Im pretty sure we
can do an overload (has different result types, but also different
arguemnts, should be fine for .net).

ie:
LHTTP.Get("http://www.atozed.com", IndyConvert(LOutput))

The advantages with C are that:
1) User does not have to import any Borland namespaces, only Indy (albeit
an additional Indy one)
2) User does not need to know the destination type, or specify it.
3) Its a bit shorter and easier.

If c is the best - what should we call the function?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Cor" <no*@non.com> wrote in news:ez**************@TK2MSFTNGP09.phx.gbl:

VB6 programs where never as fast as C++ and that is nowhere written.
Its not a matter of fast - its a matter of producing encouraging code with
lots of bugs, and thus being unreliable.
The ones who start with a new program should set option Strict On in the
VS.net options, than you have not even to declare it and behaviour is as
you wish.

By making it the default for 6 versions they told new programmers that it was
not only "good" but led them into many pitfalls and traps.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Cor" <no*@non.com> wrote in news:ub**************@TK2MSFTNGP11.phx.gbl:

Start a debat that is about VB.net without C# with Armin, than you will see
what is forceful

Dont get me wrong - VB.net is finally "good". My gripes lie mostly with VB
versions prior to .net.

I have gripes with C#.

Now if you want to talk langauges - lets talk Delphi. :)

Delphi's not perfect either - but even with using VB and C#, over all I like
it much better. But C# is just a Delphi form of C++ (Anders H no doubt) and
each version of C# gets closer and closer to Delphi. soo...
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Armin Zingler]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb

"Armin Zingler" <az*******@freenet.de> wrote in
news:Oea9wmz5DHA.2252 @TK2MSFTNGP10.phx.gbl:

Thanks for the explanation. I know too little about C#

No problem.

BTW - sorry if sounded forceful in my other replies. No disrespect
intended - Im just a very forceful in debates. :)

No problem either. Didn't sound forceful to me.
--
Armin

[Cor]

Hi Kudzu,

VB has one big benefit it is not a should language, but a could language..

Some people do not like it, the take C# others like it and they take VB.net

I can say I like it more to have some freedom.

Cor

[Klaus Löffelmann]

*LOL*

No offense, Armin... :-)

Klaus
"Cor" <no*@non.com> schrieb im Newsbeitrag
news:ub**************@TK2MSFTNGP11.phx.gbl...

Hi Kudzu,

Start a debat that is about VB.net without C# with Armin, than you will see what is forceful
:-) although for this I can use the one Armin sometimes uses :->

Cor

[Klaus Löffelmann]

Chad,

why not writing a wrapper DLL for VB, that wraps around the related objects.
And about the Using- (Imports-) Business. How do you access a namespace in
c# without "Using" it?

Klaus

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb im Newsbeitrag
news:Xn******************@127.0.0.1...

Ok. New question, same thread as its related. Take a look at the code
below. The line with the .Get is really the only one of importance.

Imports System.IO
Imports System.Text
Imports Indy.Sockets.IndyHTTP

Module Module1

Sub Main()
Dim LResult As String
Dim LHTTP As New HTTP

Dim LStream As New MemoryStream
Dim LOutput As New FileStream( _
New FileInfo
(System.Windows.Forms.Application.ExecutablePath). DirectoryName _
+ "\index.html", FileMode.Create)
LHTTP.Get("http://www.atozed.com", DirectCast(LOutput,
Borland.Vcl.Classes.TStream))
End Sub

End Module

Now I can chaneg it to:

LHTTP.Get("http://www.atozed.com", DirectCast(LOutput, TStream))

If the user adds:
Imports Borland.Vcl.Classes;

In C# neither of these are necessary because of implicit coversion, its all done transparently. They dont even need the Imports (using in C#). We've
esatablished that.

That being said - there are 3 options to present to VB users. Can you tell
me which do you think would be the most desirable to VB users?

a) The solution above. Either with fully qualified TStream or adding it to
the Imports.

b) Same issue as above, but instead of DirectCast calling:

LHTTP.Get("http://www.atozed.com", new TCLRStream(LOutput))

This still needs to be fully qualified - or have the namespace added to
Imports.

c) We add a Convert function that is overloaded to Indy. Im pretty sure we
can do an overload (has different result types, but also different
arguemnts, should be fine for .net).

ie:
LHTTP.Get("http://www.atozed.com", IndyConvert(LOutput))

The advantages with C are that:
1) User does not have to import any Borland namespaces, only Indy (albeit
an additional Indy one)
2) User does not need to know the destination type, or specify it.
3) Its a bit shorter and easier.

If c is the best - what should we call the function?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Cor" <no*@non.com> wrote in news:uR**************@TK2MSFTNGP12.phx.gbl:

VB has one big benefit it is not a should language, but a could language..

For 6 versions it was a "should have been, but isnt" language. :(

Only now is it a "can".
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Klaus Löffelmann" <fo***********@loeffelmann.de> wrote in
news:40**********************@news.freenet.de:

why not writing a wrapper DLL for VB, that wraps around the related
Its not just this one line. The source is 120 source files or so and like
60,000 lines of code. Its also not only for VB. So IFDEFFING say 300 places
with new overload JUST for VB is not a viable nor desirable option. :)
objects. And about the Using- (Imports-) Business. How do you access a
namespace in c# without "Using" it?

With implicit conversion the developer never references the target type of
the argument, and thus never needs the namespace. The developer passes in
System.IO.Stream, and C# does the implicit conversion (cast in VB terms).

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Herfried K. Wagner [MVP]]

* "Klaus Löffelmann" <fo***********@loeffelmann.de> scripsit:

I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set

Option Strict True

'On', not 'True'.

;-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Chad Z. Hower aka Kudzu]

Any input on this one? :)

Subject: Re: VB and implicit conversions
From: "Chad Z. Hower aka Kudzu" <cp**@hower.org>
Newsgroups: microsoft.public.dotnet.languages.vb

Ok. New question, same thread as its related. Take a look at the code
below. The line with the .Get is really the only one of importance.

Imports System.IO
Imports System.Text
Imports Indy.Sockets.IndyHTTP

Module Module1

Sub Main()
Dim LResult As String
Dim LHTTP As New HTTP

Dim LStream As New MemoryStream
Dim LOutput As New FileStream( _
New FileInfo
(System.Windows.Forms.Application.ExecutablePath). DirectoryName _
+ "\index.html", FileMode.Create)
LHTTP.Get("http://www.atozed.com", DirectCast(LOutput,
Borland.Vcl.Classes.TStream))
End Sub

End Module

Now I can chaneg it to:

LHTTP.Get("http://www.atozed.com", DirectCast(LOutput, TStream))

If the user adds:
Imports Borland.Vcl.Classes;

In C# neither of these are necessary because of implicit coversion, its all
done transparently. They dont even need the Imports (using in C#). We've
esatablished that.

That being said - there are 3 options to present to VB users. Can you tell
me which do you think would be the most desirable to VB users?

a) The solution above. Either with fully qualified TStream or adding it to
the Imports.

b) Same issue as above, but instead of DirectCast calling:

LHTTP.Get("http://www.atozed.com", new TCLRStream(LOutput))

This still needs to be fully qualified - or have the namespace added to
Imports.

c) We add a Convert function that is overloaded to Indy. Im pretty sure we
can do an overload (has different result types, but also different
arguemnts, should be fine for .net).

ie:
LHTTP.Get("http://www.atozed.com", IndyConvert(LOutput))

The advantages with C are that:
1) User does not have to import any Borland namespaces, only Indy (albeit
an additional Indy one)
2) User does not need to know the destination type, or specify it.
3) Its a bit shorter and easier.

If c is the best - what should we call the function?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Stephen Martin]

Operator overloading is something of a mixed blessing at best and
overloading the implicit operator is probably the diciest of all. In
general, using an implicit conversion operator on a custom type is not a
good idea and should be restricted at most to a few specialized value types.
Using an implicit conversion operator between reference types is almost
always a very bad idea since it makes reference types act as value types
without warning (i.e. a reference is no longer copied, a new object is
created) along with several other problems to do with readability, etc.
Implicit casts should really be used only for casting to a base class. In
fact, if faced with a library that used implicit conversion to any great
extent, or used it between reference types without a very good reason I
would probably pass on it.

That having been said, in your scenario a) won't work: DirectCast can only
cast to a type that the object already is, for example upcasting or casting
to an interface that the object implements. CType does other conversions as
well as casting but it also can't use your custom operator. Choice b) is
better it makes clear that you are creating a new object based on the input
object but it is a little non-standard. Choice c) is, in my opinion, clearly
the best. As to the name of the conversion function you already have a
static function (your operator) called op_Implicit that can be called from
VB but it would be better to implement functions along the lines of FromXXX
and ToXXX when you want to implement custom conversion routines.

I've used operator overloading a fair amount in C++ and C# and I must say
that I am awaiting its arrival in VB with some trepidation. While it will be
useful occasionally it will almost certainly lead to a proliferation of
garbage code similar to, and possibly worse than, that created by the
introduction of simple multi-threading and a few other things.
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...

Any input on this one? :)

Subject: Re: VB and implicit conversions
From: "Chad Z. Hower aka Kudzu" <cp**@hower.org>
Newsgroups: microsoft.public.dotnet.languages.vb

Ok. New question, same thread as its related. Take a look at the code
below. The line with the .Get is really the only one of importance.

Imports System.IO
Imports System.Text
Imports Indy.Sockets.IndyHTTP

Module Module1

Sub Main()
Dim LResult As String
Dim LHTTP As New HTTP

Dim LStream As New MemoryStream
Dim LOutput As New FileStream( _
New FileInfo
(System.Windows.Forms.Application.ExecutablePath). DirectoryName _
+ "\index.html", FileMode.Create)
LHTTP.Get("http://www.atozed.com", DirectCast(LOutput,
Borland.Vcl.Classes.TStream))
End Sub

End Module

Now I can chaneg it to:

LHTTP.Get("http://www.atozed.com", DirectCast(LOutput, TStream))

If the user adds:
Imports Borland.Vcl.Classes;

In C# neither of these are necessary because of implicit coversion, its all done transparently. They dont even need the Imports (using in C#). We've
esatablished that.

That being said - there are 3 options to present to VB users. Can you tell
me which do you think would be the most desirable to VB users?

a) The solution above. Either with fully qualified TStream or adding it to
the Imports.

b) Same issue as above, but instead of DirectCast calling:

LHTTP.Get("http://www.atozed.com", new TCLRStream(LOutput))

This still needs to be fully qualified - or have the namespace added to
Imports.

c) We add a Convert function that is overloaded to Indy. Im pretty sure we
can do an overload (has different result types, but also different
arguemnts, should be fine for .net).

ie:
LHTTP.Get("http://www.atozed.com", IndyConvert(LOutput))

The advantages with C are that:
1) User does not have to import any Borland namespaces, only Indy (albeit
an additional Indy one)
2) User does not need to know the destination type, or specify it.
3) Its a bit shorter and easier.

If c is the best - what should we call the function?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

"Stephen Martin" <sm*****@removethis.emsoft.andthis.ca> wrote in
news:uo**************@tk2msftngp13.phx.gbl:

Operator overloading is something of a mixed blessing at best and
Operator overloading certainly can be abused. So can the with statement.
overloading the implicit operator is probably the diciest of all. In
Not at all. In fact when you do not have access to alter base classes, its
very important in providing conversions.

Also - a true OOP system cannot function without it. Floats, integers, etc
are ALL implemented this way internally to .net.
general, using an implicit conversion operator on a custom type is not a
good idea and should be restricted at most to a few specialized value
types. Using an implicit conversion operator between reference types is
almost always a very bad idea since it makes reference types act as
value types without warning (i.e. a reference is no longer copied, a new
You misunderstand how they are used. They are not limited to value types,
and you do not convert the reference.

Think of them as adaptors, It allows one interface to morph onto another.
object is created) along with several other problems to do with
readability, etc. Implicit casts should really be used only for casting
to a base class. In fact, if faced with a library that used implicit
There is no need to cast to a base class. And this is not the same. It
appears that you do not understand what happens in implicit conversions of
non valued objects.
That having been said, in your scenario a) won't work: DirectCast can
only cast to a type that the object already is, for example upcasting or
casting to an interface that the object implements. CType does other
Again - you dont seem to understand what is going on. DirectCast most
certainly DOES work. There is no upcasting occurring. You can download the
demo and play with it if you want.
operator. Choice b) is better it makes clear that you are creating a new
object based on the input object but it is a little non-standard. Choice
c) is, in my opinion, clearly the best. As to the name of the conversion
C is the one I prefer as well, since there is no implicit conversion.
op_Implicit that can be called from VB but it would be better to
implement functions along the lines of FromXXX and ToXXX when you want
to implement custom conversion routines.

ToXXX would require the user to understand what it is going to - Where as
we can easily overload them and automatically select for the user based on
the condition.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Klaus Löffelmann]

Yeah, that's on.
I mean true.
Whatever.

;-)

Klaus
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schrieb im Newsbeitrag
news:bv************@ID-208219.news.uni-berlin.de...

* "Klaus Löffelmann" <fo***********@loeffelmann.de> scripsit:

I wouldn't call VB the king language of anti type safety. At least, not
anymore. And, of course, only if you set

Option Strict True

'On', not 'True'.

;-)

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[Stephen Martin]

Hi Chad,

You might want to re-read my post. It might just be me but your responses
don't seem to make much sense in the context they are in. But just to
clarify a couple of things:

...when you do not have access to alter base classes, its very important in providing conversions...
It's actually only one of (and in my opinion the least preferable) method of
doing conversions. Explicit conversion operators, conversion functions and
conversion constructors are all superior.
...a true OOP system cannot function without it. Floats, integers, etc are ALL implemented this way internally to .net...
That a 'true' OOP system requires implicit conversion operators is certainly
highly debatable. Also, your reference to floats, integers, etc. is somewhat
disingenuous, I was explicitly speaking of custom types not primitives and I
added that there are some instances where an implicit conversion operator is
useful for value types.
...They are not limited to value types, and you do not convert the reference.
I didn't say anything about them being limited to value types. But if you
have an assignment statement (or method parameter) that involves an implicit
conversion operator then unlike the standard for reference types of simply
copying a reference to the original object into the new variable you are
actually creating a new object and then assigning its reference to the
variable (unless of course your conversion operator returned a this
reference but that would be rather unusual). This then makes your reference
types act like value types (copy on assignment), at least an explicit
conversion operator gives you warning (though a conversion function or
conversion constructor would be better).
...It allows one interface to morph onto another.

If you want to convert(morph?) between the interfaces implemented by an
object then the default explicit conversion operator already does that and
there is no reason to make it implicit. If you are creating a new object
that implements a similar interface or has the same base class but
additional interfaces, etc. then you are much better off implementing
conversion constructors or static conversion functions (or if you must an
explicit conversion operator).

Also, again I might be misunderstanding, but your code listing states that
LOutput is of type System.IO.FileStream. In order to pass it to your method
you are casting it to type Borland.Vcl.Classes.TStream. If this is correct
then DirectCast should only work if LOuput is already of type
Borland.Vcl.Classes.TStream, but this isn't the case since it is dimmed and
created the line above as a FileStream and I know that FileStream does not
inherit from Borland.Vcl.Classes.TStream nor does it implement an interface
called Borland.Vcl.Classes.TStream. So, either DirectCast isn't working as
it is supposed to or something is going over my head here.

It's possible we're not understanding each other, talking past each other so
to speak. To clarify what you are talking about perhaps you could post the
code here for your implicit operator and a link to the 'demo' to which you
referred.
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1...
<snip>

[Chad Z. Hower aka Kudzu]

"Stephen Martin" <sm*****@removethis.emsoft.andthis.ca> wrote in
news:eu**************@TK2MSFTNGP10.phx.gbl:

method of doing conversions. Explicit conversion operators, conversion
functions and conversion constructors are all superior.
Not always - its always good to have them, but often they are just PITA.
Imagine if you had to cast to go from a byte into an integer? Or a
character into a string? Conversions that are straightforward and well
defined should be automatic.
certainly highly debatable. Also, your reference to floats, integers,
etc. is somewhat disingenuous, I was explicitly speaking of custom types
not primitives and I added that there are some instances where an
In .net there is no difference. Internally an integer is pretty much an
object, and the conversions to other types are handled the same as any
other object. The only "Special" part is that simple types have literals
that the compiler understands.
variable you are actually creating a new object and then assigning its
reference to the variable (unless of course your conversion operator
returned a this reference but that would be rather unusual). This then
makes your reference types act like value types (copy on assignment), at
least an explicit conversion operator gives you warning (though a
conversion function or conversion constructor would be better).
Incorrect - The case in point is not so.

TCLRStream constructor accepts a System.IO.Stream. TCLRStream implements
TStream abstract. All calls from the overridden methods in TCLRStream are
mapped onto (translated) to System.IO.Stream's equivalent on that instance.
There is no value, and nothing is lost.
Also, again I might be misunderstanding, but your code listing states
that LOutput is of type System.IO.FileStream. In order to pass it to
your method you are casting it to type Borland.Vcl.Classes.TStream. If
this is correct then DirectCast should only work if LOuput is already of
type Borland.Vcl.Classes.TStream, but this isn't the case since it is
DirectCast does in fact fail. It compiles but throws an exception. The
documentation I read on it led me to beleive it looks for the implicit
casts, that is its doing what C# does automatically. Evidently it does not
and it uses IConvertable and some differetn mechanisms. What a shame.

I could swear I ran the VB version before. I did a compiler update at the
same time. Id love to back that out to verify, but that would take hours.
And the C# version still works anyways.
It's possible we're not understanding each other, talking past each
other so to speak. To clarify what you are talking about perhaps you
could post the code here for your implicit operator and a link to the
'demo' to which you referred.

It seems that VB has not support for the implicit overloads, even through
explicit calls.

The code is here:
http://downloads.atozed.com/indy/10/VSIntroStream.zip

It requires this assembly:
http://www.atozed.com/indy.html

Looks like Im down to 2 options now - Covert method overload or explicit
creation. The convert overloads are much friendlier.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com

[Chad Z. Hower aka Kudzu]

FYI,

We went with option C.

http://www.atozed.com/indy/Texts/VSIntro.iwp

See the last two examples under "Using Streams". Compare the C# and the VB
and you can see the difference. Also see the note about "Conversion - Visual
Basic".
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com