VB and implicit conversions

  • Thread starter Thread starter Chad Z. Hower aka Kudzu
  • Start date Start date
Chad Z. Hower aka Kudzu said:
No problem.

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

No problem either. Didn't sound forceful to me.
 
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
 
Cor said:
VB6 programs where never as fast as C++ and that is nowhere written.
Click to expand...

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.
Click to expand...

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
 
Cor said:
Start a debat that is about VB.net without C# with Armin, than you will see
what is forceful
Click to expand...

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
 
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
 
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
 
Klaus Löffelmann said:
why not writing a wrapper DLL for VB, that wraps around the related
Click to expand...

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?
Click to expand...

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
 
* "Klaus Löffelmann said:
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
Click to expand...

'On', not 'True'.

;-)
 
Any input on this one? :)

Subject: Re: VB and implicit conversions
From: "Chad Z. Hower aka Kudzu" <[email protected]>
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
 
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.
 
Stephen Martin said:
Operator overloading is something of a mixed blessing at best and
Click to expand...

Operator overloading certainly can be abused. So can the with statement.
overloading the implicit operator is probably the diciest of all. In
Click to expand...

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
Click to expand...

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
Click to expand...

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
Click to expand...

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
Click to expand...

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.
Click to expand...

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
 
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
Click to expand...
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
Click to expand...
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
Click to expand...
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.
Click to expand...
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.


<snip>
 
Stephen Martin said:
method of doing conversions. Explicit conversion operators, conversion
functions and conversion constructors are all superior.
Click to expand...

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
Click to expand...

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).
Click to expand...

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
Click to expand...

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.
Click to expand...

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
 
Back
Top