A
Armin Zingler
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.
No problem either. Didn't sound forceful to me.
No problem either. Didn't sound forceful to me.
C
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
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
C
Chad Z. Hower aka Kudzu
Cor said:
Its not a matter of fast - its a matter of producing encouraging code with
lots of bugs, and thus being unreliable.
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
C
Chad Z. Hower aka Kudzu
Cor said:
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
C
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
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
K
Klaus Löffelmann
*LOL*
No offense, Armin...
Klaus
No offense, Armin...
Klaus
K
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
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
C
Chad Z. Hower aka Kudzu
Cor said:
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
C
Chad Z. Hower aka Kudzu
Klaus Löffelmann said:
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.
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
H
Herfried K. Wagner [MVP]
* "Klaus Löffelmann said:
'On', not 'True'.
;-)
C
Chad Z. Hower aka Kudzu
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
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
S
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.
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.
C
Chad Z. Hower aka Kudzu
Stephen Martin said:
Operator overloading certainly can be abused. So can the with statement.
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.
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.
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.
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.
C is the one I prefer as well, since there is no implicit conversion.
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
K
Klaus Löffelmann
Yeah, that's on.
I mean true.
Whatever.
;-)
Klaus
I mean true.
Whatever.
;-)
Klaus
S
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:
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.
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.
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).
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>
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:
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.
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.
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).
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>
C
Chad Z. Hower aka Kudzu
Stephen Martin said:
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.
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.
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.
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 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
C
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
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