Microsoft silences Karl Peterson's MVP "VB.Not" website
Josh Straub
http://news.cnet.com/news/0-1015-205-4537568.html?tag=btmprm, Microsoft
may definetly have been behind the recent unexplained complete
disappearance of Karl Peterson's notorious "VB.Not" website at
www.mvps.org/vb/ which lists all the problems and incompatibilities with
MS new VB.Net project. Karl's excellent VB website remains, but sans
ALL references to VB.Net (or VB.Not, as his site called it). Karl's
responses have been MIA and I haven't heard anything anywhere else; the
CCRP/MVPS news server is eerily out of date at news://news.mvps.org ,
appearing as though perhaps all recent articles were deleted. Anyone
have any idea what's going on here? One thing's for sure, I absolutely
don't trust any company that stonewalls it's supporters into agreeing
with them.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Josh Straub ôżô took...@nconnect.net
G. Andrew Duthie
appropriateness of his commentary given his position as an MVP. Certainly, I
think it is reasonable for MS to expect someone in that position to not
publicly trash their products (again, I don't know if his page reached that
level). I would also point out that alleging some great conspiracy on the
basis of the reporting on a page called "rumor mill" seems a bit premature.
It could also be that Karl stepped over the line and released NDA info,
which could easily explain the removal of the site and news posts. Until
(if/when) we hear Karl's side of the story, there's no way to know what
happened for sure, so I'm not inclined to condemn anyone just yet.
Regards,
G. /\ndrew Duthie
"Josh Straub" <took...@nconnect.net> wrote in message
news:#6pPYD$hAHA.2020@tkmsftngp05...
> Josh Straub ôŋô took...@nconnect.net
>
Carl Prothman
> Anyone have any idea what's going on here?
>
Josh,
Don't worry, the sky is not falling... ;-)
Karl's "issues" web page for VB.NET is still there.
http://www.mvps.org/vb/index.html?rants/dotnot.htm
And I hear that Microsoft will be addressing each of our concerns in the
near future. I'm sure Karl will say more when he gets a spare moment from
work.
--
Thanks,
Carl Prothman
Microsoft Visual Basic MVP
http://www.able-consulting.com
Jonathan Allen
I saw it, was just a list of rants, many of which were misleading. There are
other VB.Net sites that, while complaining about the changes, at least
mention the work-arounds.
As for MS shutting it down, I seriously doubt it. MS is not in the position
to make enemies right now. And if they did, Karl could have at least posted
the letter from MS's legal department. Considering he still has a logo with
the word "Microsoft" on his site, I have even more doubts.
--
Jonathan Allen
"G. Andrew Duthie" <gra...@att.net> wrote in message
news:eG5$6VAiAHA.2076@tkmsftngp03...
Jonathan Allen
And still as inaccurate as ever.
As Any is not supported for API Declares.
It was a bad practice anyways.
Arrays may not have a lower bound other than zero.
They can, the syntax is just different.
Variants are not supported. Object is now the default data type.
Object can be used just about anywhere variant could.
Currency is not supported.
Decimal provides all the functionality of currency and then some.
Dates are not stored internally as Double values.
True, but who is stupid enough to store dates in doubles?
Dim may not always create procedure-level variables.
Ok, this one intrests me. Can anyone explain what he is talking about?
Redim will not create arrays not already declared.
Big deal, it's one extra line
Local variables are not necessarily visible throughout a procedure.
They are if you put them at the top where they belong
Null is not supported.
It's supported, but it's now known as DBNull.
Empty is not supported.
I use this a lot, myGuid = Guid.Empty.
Object finalization code will not execute in a predictable order.
Sure they will, as long as you use Dispose like your suppose to.
Public object variables are not safe from alteration when passed as
parameters.
They never were. There was a common misconception that objects bassed
ByVal couldn't be altered in VB6. In reality, it is the pointer to the
object that couldn't be altered.
Procedure parameters are not by default passed ByRef anymore.
Cosidering the IDE forces you to use ByVal or ByRef (it inserts it if
you don't), I doubt there will be any confusion.
Static is not supported as a procedure level modifier.
You can still declare the variable at the top of the class, where it
belongs anyways.
Parenthesis are not optional when calling procedures.
The IDE adds them if you forget, so it's no big deal.
Set is not supported for object assignment.
Like "Let", it's no longer needed.
UDTs are not by default contiguous blocks of memory, but are objects.
Complete nonsense. All objects are in contiguous blocks of memory. The
change for structs is that the layout is not garunteed, unless you ask for a
particular order.
Enums will not be recognized unless fully-qualified.
Completely wrong. You can use imports on an Enum if you want.
While/Wend loops are not supported.
Wend was renamed End While. A silly change, but no big deal.
And, Or, XOr, and Not are not bitwise operators.
No, but BitAnd, BitOr, and BitNot are.
Label controls will not have a Caption property.
It's just called Text, no big deal.
The Tag property is not supported.
It's available via Tag, a property extender. Any object can now have a
tag. In fact, you can have several tags if you want. And I haven't even
touched inheritance.
Top-level menus may not be used as context menus.
Instead you build them seperately, which is better than having a bunch
of hidden menus at the top of the screen.
--
Jonathan Allen
"Carl Prothman" <car...@spamcop.net> wrote in message
news:eTwdGvBiAHA.1876@tkmsftngp02...
G. Andrew Duthie
sympathize with people who have a lot of code to migrate, but the truth is
that the changes will make VB a better and more powerful (and more useful)
language. As the saying goes, "you can't make an omelet without breaking a
few eggs." Considering how many times I've heard advanced VB developers
complain about the limitations of VB, you'd think folks like Karl would be
celebrating. Ah well.
G. /\ndrew Duthie
"Jonathan Allen" <greyw...@bigfoot.com> wrote in message
news:OY6ge0BiAHA.2024@tkmsftngp03...
Michael (michka) Kaplan
Some people just have nothing better to do than play games in the media?
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Josh Straub" <took...@nconnect.net> wrote in message
news:#6pPYD$hAHA.2020@tkmsftngp05...
Lars Lundstedt
> Ok, this one intrests me. Can anyone explain what he is talking about?
If you use Dim inside an If-Then statement or an For To Next loop for
instance the Dim is local to that statement, not to the procedure
Bob Butler
Little, if anything, is inaccurate.
> As Any is not supported for API Declares.
> It was a bad practice anyways.
That does not make it inaccurate - it's a change that people need to
understand.
> Arrays may not have a lower bound other than zero.
> They can, the syntax is just different.
And there are limits on passing them to other components if you do that.
> Variants are not supported. Object is now the default data type.
> Object can be used just about anywhere variant could.
That does not make it inaccurate - it's a change that people need to
understand.
> Currency is not supported.
> Decimal provides all the functionality of currency and then some.
That does not make it inaccurate - it's a change that people need to
understand.
> Dates are not stored internally as Double values.
> True, but who is stupid enough to store dates in doubles?
That does not make it inaccurate - it's a change that people need to
understand.
> Dim may not always create procedure-level variables.
> Ok, this one intrests me. Can anyone explain what he is talking about?
If x=5 Then
dim y as integer
<use y for some work>
End If
' at this point y is invalid
> Redim will not create arrays not already declared.
> Big deal, it's one extra line
That does not make it inaccurate - it's a change that people need to
understand.
> Local variables are not necessarily visible throughout a procedure.
> They are if you put them at the top where they belong
That does not make it inaccurate - it's a change that people need to
understand.
(it's actually a reiteration of the Dim/local scope issue)
> Null is not supported.
> It's supported, but it's now known as DBNull.
That does not make it inaccurate - it's a change that people need to
understand.
> Empty is not supported.
> I use this a lot, myGuid = Guid.Empty.
In VB6 you can check if a Variant contains "Empty"; in VB.Net an Object can
not contain the generic "Empty" value. Specific objects may have
workarounds but that's a different issue.
> Object finalization code will not execute in a predictable order.
> Sure they will, as long as you use Dispose like your suppose to.
Terminate events fired automatically when the last reference to an object is
released. This functionality is gone in VB.Net and using Dispose/Finalize
will, in many cases, require significant modifications to both the objects
and the client code in order to properly implement the design patterns
required by it. If you do not re-architect to use the new patterns, and you
do not use careful error trapping and keep very close track of your objects
then finalization order is still unpredictable.
> Public object variables are not safe from alteration when passed as
> parameters.
> They never were. There was a common misconception that objects bassed
> ByVal couldn't be altered in VB6. In reality, it is the pointer to the
> object that couldn't be altered.
Different issue -- in VB6 if you pass a reference to a public property to
another procedure it is not changed. Example:
Class1 has: Public SomeData As String
client code has: Call SetValue(oClass1.SomeData)
If the "SetValue" routine changes the value of the parameter the change is
lost in VB6. It is not lost in VB.Net. I don't expect this to be a big
issue but it may affect some people.
> Procedure parameters are not by default passed ByRef anymore.
> Cosidering the IDE forces you to use ByVal or ByRef (it inserts it if
> you don't), I doubt there will be any confusion.
That does not make it inaccurate - it's a change that people need to
understand.
> Static is not supported as a procedure level modifier.
> You can still declare the variable at the top of the class, where it
> belongs anyways.
That does not make it inaccurate - it's a change that people need to
understand.
(and the "where it belongs" is debatable - in the case of a variable that
needs only local scope but module-level lifetime the Static modifier was
invaluable and prevented many accidental misuses of module-level variables)
> Parenthesis are not optional when calling procedures.
> The IDE adds them if you forget, so it's no big deal.
That does not make it inaccurate - it's a change that people need to
understand.
> Set is not supported for object assignment.
> Like "Let", it's no longer needed.
That does not make it inaccurate - it's a change that people need to
understand.
> UDTs are not by default contiguous blocks of memory, but are objects.
> Complete nonsense. All objects are in contiguous blocks of memory. The
> change for structs is that the layout is not garunteed, unless you ask for
a
> particular order.
All objects are not contiguous blocks of memory in VB.Net but UDTs were not
contiguous blocks in VB6 either. The point I think is being made here is as
you describe and that's going to affect a lot of code.
> Enums will not be recognized unless fully-qualified.
> Completely wrong. You can use imports on an Enum if you want.
No, the name still has to be qualified. You can quibble with "fully" but
you still have to include the enum name as well as the member name.
> While/Wend loops are not supported.
> Wend was renamed End While. A silly change, but no big deal.
To you, maybe. To people suporting code both in VB.Net and VB6 it's still a
change that must be dealt with and one with little justification.
> And, Or, XOr, and Not are not bitwise operators.
> No, but BitAnd, BitOr, and BitNot are.
That does not make it inaccurate - it's a change that people need to
understand.
> Label controls will not have a Caption property.
> It's just called Text, no big deal.
That does not make it inaccurate - it's a change that people need to
understand.
> The Tag property is not supported.
> It's available via Tag, a property extender. Any object can now have a
> tag. In fact, you can have several tags if you want. And I haven't even
> touched inheritance.
Using Extenders is very different than using a direct property. It may
accomplish the same goal but it does not make the statement inaccurate.
> Top-level menus may not be used as context menus.
> Instead you build them seperately, which is better than having a bunch
> of hidden menus at the top of the screen.
That does not make it inaccurate - it's a change that people need to
understand.
You are completely correct that there are new, sometimes much better, ways
to do things that used to be the standard in VB6. That does not change the
fact that VB developers essentially need to learn an entirely new language
and does not make what's on Karl's page "inaccurate". VB.Net, on it's own
merits, may be a good tool but for people expecting to upgrade from VB6 to
VB.Net it's important that the differences be highlighted so that they
understand the maginitude of the task. For independent developers who can
wrap up a completed project, deliver it and move on to the next client the
task of switching to VB.Net may be relatively simple - it just becomes
another option when bidding on a project. For those with an existing
codebase of mission-critical VB apps it's more like hitting a brick wall.
In many cases it's not going to be feasible to rewrite everything in VB.Net
and depending on how tightly new development needs to tie in to existing
apps it may be more appropriate to do that in VB6 as well.
Gregor R. Peisker
I think that's about Static as procedure modifier, which means that all
local variable become static. I'm not so sure that replacing local static
variables by class level variables is always the better way ...
Anyway, Static as a proc modifier in VB6 cause Dim to create a Static
variable. Now you have to use static explicitly for every variable you want
to be static.
So *that* change is a good thing.
Regards,
Gregor
Rob Jolt
>
> And still as inaccurate as ever.
>
> As Any is not supported for API Declares.
> It was a bad practice anyways.
Johathan, have you ever done any real coding in you life?
Just wondering, "anyways"
Jonathan Allen
Not with "As Any" and other slop code..
--
Jonathan Allen
"Rob Jolt" <rj...@iname.com> wrote in message
news:#4UGkQZiAHA.1620@tkmsftngp02...
Michael (michka) Kaplan
been out of work since then and is hoping VB.NET will change his luck! <g>
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Rob Jolt" <rj...@iname.com> wrote in message
news:#4UGkQZiAHA.1620@tkmsftngp02...
Patrice Scribe
VB.NET is a new language rather than an evolution of VB 6...
If you consider VB 6 and VB.NET as two different languages it doesn' make
really sense to compare language constructions this way...
--
Patrice Scribe
http://www.chez.com/scribe/
http://members.nbci.com/vba51/
http://vba51.terrashare.com/
"Jonathan Allen" <greyw...@bigfoot.com> a écrit dans le message news:
umK3wICiAHA.2120@tkmsftngp02...
Karl E. Peterson
No, it's about block scoping.
Later... Karl
--
[This space intentionally left blank.]
"Gregor R. Peisker" <gre...@peisker.de> wrote in message
news:#W3LXZIiAHA.1624@tkmsftngp05...
Gregor R. Peisker
I don't understand this. I was referring to the item
"Static is not supported as a procedure level modifier"
at your site. I thought this was compatible to this note in the VB.Net
documentation:
"In Visual Basic.Net 7.0 the Static modifier is not supported in a Function
or Sub statement. You must individually declare each local variable you want
to be static."
Anyway, I just tried to declare a static local variable, but the IDE
reported" Static variables are not supported. Module and class level may be
used instead". This even mappes to a help topic, but it hasn't been finished
yet (they still need to remove that red text at the top <g>).
Is this a beta issue? Perhaps the documentation applies to version 7 of
VB.Net <g>.
Regards,
Gregor
Karl E. Peterson
> I don't understand this. I was referring to the item
>
> "Static is not supported as a procedure level modifier"
Whoops! I'm sorry. I misunderstood your post as a response to Jonathan's Dim
confusion.
> at your site. I thought this was compatible to this note in the VB.Net
> documentation:
>
> "In Visual Basic.Net 7.0 the Static modifier is not supported in a Function
> or Sub statement. You must individually declare each local variable you want
> to be static."
>
> Anyway, I just tried to declare a static local variable, but the IDE
> reported" Static variables are not supported. Module and class level may be
> used instead". This even mappes to a help topic, but it hasn't been finished
> yet (they still need to remove that red text at the top <g>).
>
> Is this a beta issue? Perhaps the documentation applies to version 7 of
> VB.Net <g>.
I've heard it told both ways. I'd guess that beta2 will be more definitive in regard
to how this will work in the end. In the meanwhile, here's a bit more info:
http://home.earthlink.net/~butlerbob/Port/Static.htm
Sorry... Karl
Sjoerd Verweij
features are gone -- when with a few exceptions, they have just
changed.
Karl E. Peterson
one of those bullets is an obsticle to cross-compilation. No matter how many times
you "say" what you do, the fact remains, functional code is broken.
--
[This space intentionally left blank.]
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a75b1c8....@msnews.microsoft.com...
Sjoerd Verweij
>one of those bullets is an obsticle to cross-compilation. No matter how many times
>you "say" what you do, the fact remains, functional code is broken.
Hey, I wasn't disputing that. But no matter what the intent, people
are using it to point out that VB.NET sucks -- while the list merely
proves it's not VB7 and that again, there are some Microsoft
marketeers that should be shot.
Karl E. Peterson
> >The "intent" is merely to list migration issues. I point to many workarounds.
Each
> >one of those bullets is an obsticle to cross-compilation. No matter how many
times
> >you "say" what you do, the fact remains, functional code is broken.
>
> Hey, I wasn't disputing that.
Cool.
> But no matter what the intent, people
> are using it to point out that VB.NET sucks --
Yeah, I've noticed that.
> while the list merely proves it's not VB7
Noticed that too. Think many have?
> and that again, there are some Microsoft
> marketeers that should be shot.
Gotta give them some credit, though. Selling this as an *upgrade* to VB6 is really
asking a lot. The guy I feel for is the one in charge of writing the migration
wizard. I just don't see any way to win that battle.
Later... Karl
Sjoerd Verweij
>asking a lot. The guy I feel for is the one in charge of writing the migration
>wizard. I just don't see any way to win that battle.
Well, the sad part is that there really is no technical objection to
writing one that goes 99.9%. It'll just never make the deadline. Who
knows though, maybe with all the ruckus they threw twenty additional
propellorheads at it :-)
Karl E. Peterson
Seems they'd benefit *somewhat* if those 6-7 million existing customers could port
their code across, yeah. Heh, who knows? Maybe even more than if the MS-haters
using Java could!? Interesting to ponder, isn't it?
Later... Karl
Sjoerd Verweij
>their code across, yeah. Heh, who knows? Maybe even more than if the MS-haters
>using Java could!? Interesting to ponder, isn't it?
Well, their attitude seems to have changed somewhat since Beta 1 came
out. As in: nobody's talking. Sometimes that means they'll ignore it,
but sometimes it means they're working on it. (Remember the
Scripting/VSA dance?)
Jonathan West
>
> maybe with all the ruckus they threw twenty additional
> propellorheads at it :-)
>
That would probably delay things :-) Trying to subdivide the task among all
those extra people, then bringing the new ones up to speed on the current
status of the project, and then working out how to coordinate the efforts of
the 20 extra. No, it's not on. If MS is only discovering now that the
upgrade wizard is going to be late because it's a bear of a thing to write,
then it will either be late, or be much less capable of coping with a wide
variety of code, or will simply not happen at all. Which of those it will be
is anybody's guess. Throwing lots of people at the task will just make it
even later.
--
Regards
Jonathan West
Karl E. Peterson
Well, it would depend of course on _how_ they used the people, wouldn't it? For
example, they could throw a bunch on the task of rearchitecting the langauge, so that
it more closely resembled Classic VB. Y'know, the little, "gratuitous" stuff.
Casting aside the efforts at Langauge Cleansing would serve multiple goals, not the
least of which being a vast minimization of the effort required to design and produce
a functional migration wiz.
Just a thought... Karl
--
[This space intentionally left blank.]
"Jonathan West" <jw...@mvps.org> wrote in message
news:u08uoUqiAHA.2104@tkmsftngp05...
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:#nJuV#tiAHA.1224@tkmsftngp05...
>
> Well, it would depend of course on _how_ they used the people, wouldn't
it? For
> example, they could throw a bunch on the task of rearchitecting the
langauge, so that
> it more closely resembled Classic VB. Y'know, the little, "gratuitous"
stuff.
> Casting aside the efforts at Langauge Cleansing would serve multiple
goals, not the
> least of which being a vast minimization of the effort required to design
and produce
> a functional migration wiz.
>
Huh ?? That'd be like making the migration wizard part of the compiler. If
they did that, then what would people talk about ? <bgd&r>
Alfred C Thompson II
> appearing as though perhaps all recent articles were deleted. Anyone
> have any idea what's going on here? One thing's for sure, I absolutely
> don't trust any company that stonewalls it's supporters into agreeing
> with them.
Well, based on the last day or so I guess we don't have to worry about Karl
being silenced. :-)
Ely Wilson
"Rule #2: Embrace change."
""
"All employee who fail to see the point of rule #1, see rule #2. If you
have any further questions, contact a recruiter."
--
Ely Wilson
dba/lead-developer, Packard-Hughes Interconnect / Delphi Automotive
--
"G. Andrew Duthie" <gra...@att.net> wrote in message
news:emOrtZCiAHA.2036@tkmsftngp03...
Karl E. Peterson
"I never did give anybody hell.
I just told the truth,
and they thought it was hell."
-- Harry Truman
Later... Karl
Karl E. Peterson
--
[This space intentionally left blank.]
"Bill McCarthy" <Bill...@iprimus.com.au> wrote in message
news:eQzekMuiAHA.2096@tkmsftngp03...
Sjoerd Verweij
>"Rule #2: Embrace change."
>""
>"All employee who fail to see the point of rule #1, see rule #2. If you
>have any further questions, contact a recruiter."
Ooh, I can feel the flames burning...
Jonathan West
>
> Well, it would depend of course on _how_ they used the people, wouldn't
it? For
> example, they could throw a bunch on the task of rearchitecting the
langauge, so that
> it more closely resembled Classic VB.
That's a different task of course. Sounds kinda late in the day for them to
be deciding on wholesale changes to the language specification - I suspect
it would result in lots of work already done getting thrown out. But if
anyone can persuade them to do it, I'm sure it's you :-)
> Y'know, the little, "gratuitous" stuff.
> Casting aside the efforts at Langauge Cleansing would serve multiple
goals,
You mean we aren't allowed to swear in (or at) vb.net?? What is the world
coming to? <g>
--
Regards
Jonathan West
Karl E. Peterson
> > Well, it would depend of course on _how_ they used the people, wouldn't it? For
> > example, they could throw a bunch on the task of rearchitecting the langauge, so
that
> > it more closely resembled Classic VB.
>
> That's a different task of course. Sounds kinda late in the day for them to
> be deciding on wholesale changes to the language specification - I suspect
> it would result in lots of work already done getting thrown out.
Age-old question, isn't it? "Do it right, or do it over." Which more often fits
your own schedule better?
> But if anyone can persuade them to do it, I'm sure it's you :-)
Heh, I was only suggesting ways to maximize the potential return on personnel
investment, while perhaps simultaneously reducing the mid-term support burden. Far
be it from *me* to offer ways to actually make it a better product. If I were to do
that, it might imply I thought they hadn't gotten it perfect in the first place,
mightn't it?
> > Y'know, the little, "gratuitous" stuff.
> > Casting aside the efforts at Langauge Cleansing would serve multiple
> > goals,
>
> You mean we aren't allowed to swear in (or at) vb.net?? What is the world
> coming to? <g>
Hmmmm, seems to depend. (On your credentials.)
Later... Karl
Sjoerd Verweij
Not necessarily. Subdivision would be fairly easy ("you do tags, you
do control arrays...")
Jonathan West
> >That would probably delay things :-)
>
> Not necessarily. Subdivision would be fairly easy ("you do tags, you
> do control arrays...")
>
I suspect that it wouldn't be as simple as that. Programming tends not to be
so easily subdividable. However, we aren't ever going to know how MS
organises the work, so it's idle speculation.
--
Regards
Jonathan West
Thor Olson
They can, the syntax is just different.
Can someone tell me what the syntax is ?? (The help files
explicitly say you can't and list it as one of the differences
between VB6 and VB.NET.)
"Jonathan Allen" <greyw...@bigfoot.com> wrote in message
news:umK3wICiAHA.2120@tkmsftngp02...
> Static is not supported as a procedure level modifier.
> You can still declare the variable at the top of the class, where it
> belongs anyways.
>
> > > Anyone have any idea what's going on here?
> > >
> >
Bob Butler
"Thor Olson" <Ol...@nospam.terabase.com> wrote in message
news:OBGj2$GjAHA.2064@tkmsftngp02...
> Arrays may not have a lower bound other than zero.
> They can, the syntax is just different.
>
> Can someone tell me what the syntax is ?? (The help files
> explicitly say you can't and list it as one of the differences
> between VB6 and VB.NET.)
As an example, this is one way to create an array with a lower bound of 1
and an upper bound of 10:
Dim x As Array = System.Array.CreateInstance(GetType(Integer), 10, 1)
Patrick Steele
says...
> As an example, this is one way to create an array with a lower bound of 1
> and an upper bound of 10:
> Dim x As Array = System.Array.CreateInstance(GetType(Integer), 10, 1)
Huh??
According to the docs, the signature:
CreateInstance(Type, Int32, Int32)
Creates "a two-dimensional Array" that uses "zero-based indexing". Are
we talking about the same thing?
--
Patrick Steele
(pst...@ipdsolution.com)
Lead Software Architect
Bill McCarthy
"Bob Butler" <butl...@earthlink.net> wrote in message
news:ekgOoDHjAHA.2104@tkmsftngp05...
>
> As an example, this is one way to create an array with a lower bound of 1
> and an upper bound of 10:
> Dim x As Array = System.Array.CreateInstance(GetType(Integer), 10, 1)
>
Actually I think that creates a two dimension array. For non zero lbound,
you have to use the Int32() array arguements for the indexes, eg:
Dim a As System.Array
a = System.Array.CreateInstance(GetType(Int32), New Int32() {20}, New
Int32() {-5})
Dim i As Int32
For i = -5 To 14
a.SetValue((i * 10), i)
Next
For i = -5 To 14
Console.WriteLine(a.GetValue(i))
Next
Bob Butler
> Hi Bob, Thor,
> "Bob Butler" <butl...@earthlink.net> wrote in message
> news:ekgOoDHjAHA.2104@tkmsftngp05...
> >
> > As an example, this is one way to create an array with a lower bound of
1
> > and an upper bound of 10:
> > Dim x As Array = System.Array.CreateInstance(GetType(Integer), 10, 1)
> >
>
> Actually I think that creates a two dimension array. For non zero lbound,
> you have to use the Int32() array arguements for the indexes, eg:
>
> Dim a As System.Array
> a = System.Array.CreateInstance(GetType(Int32), New Int32() {20}, New
> Int32() {-5})
Yep, sorry, I copied from the wrong place.
Michael (michka) Kaplan
OLD:
Dim a(-5 to 14) As Long
NEW:
Dim a As System.Array
a = System.Array.CreateInstance(GetType(Int32), New Int32() {20}, New
Int32() {-5})
with the statement that they are not supported. The NEW syntax is a whole
new animal.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Bill McCarthy" <Bill...@iprimus.com.au> wrote in message
news:ur2KcLHjAHA.1728@tkmsftngp04...
Victoria French (Zorien)
The point that he is inaccurate is correct IMO. When you tell someone that
something can't be done and don't explain any furthure... you are giving
wrong information. Perhaps his points are valid but his statements are
incorrect. I was raised to believe that if you only tell half the truth or
leave something out... you're not telling the truth at all.
Victoria
"Bob Butler" <butl...@earthlink.net> wrote in message
news:uVbOvlHiAHA.1684@tkmsftngp05...
>
> "Jonathan Allen" <greyw...@bigfoot.com> wrote in message
> news:umK3wICiAHA.2120@tkmsftngp02...
> > > Karl's "issues" web page for VB.NET is still there.
> >
> > And still as inaccurate as ever.
>
> Little, if anything, is inaccurate.
>
> > As Any is not supported for API Declares.
> > It was a bad practice anyways.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Arrays may not have a lower bound other than zero.
> > They can, the syntax is just different.
>
>
> And there are limits on passing them to other components if you do that.
>
> > Variants are not supported. Object is now the default data type.
> > Object can be used just about anywhere variant could.
>
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Currency is not supported.
> > Decimal provides all the functionality of currency and then some.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Dates are not stored internally as Double values.
> > True, but who is stupid enough to store dates in doubles?
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Dim may not always create procedure-level variables.
> > Ok, this one intrests me. Can anyone explain what he is talking
about?
>
> If x=5 Then
> dim y as integer
> <use y for some work>
> End If
> ' at this point y is invalid
>
> > Redim will not create arrays not already declared.
> > Big deal, it's one extra line
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Local variables are not necessarily visible throughout a procedure.
> > They are if you put them at the top where they belong
>
> That does not make it inaccurate - it's a change that people need to
> understand.
> (it's actually a reiteration of the Dim/local scope issue)
>
> > Null is not supported.
> > It's supported, but it's now known as DBNull.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Empty is not supported.
> > I use this a lot, myGuid = Guid.Empty.
>
> In VB6 you can check if a Variant contains "Empty"; in VB.Net an Object
can
> not contain the generic "Empty" value. Specific objects may have
> workarounds but that's a different issue.
>
> > Object finalization code will not execute in a predictable order.
> > Sure they will, as long as you use Dispose like your suppose to.
>
> Terminate events fired automatically when the last reference to an object
is
> released. This functionality is gone in VB.Net and using Dispose/Finalize
> will, in many cases, require significant modifications to both the objects
> and the client code in order to properly implement the design patterns
> required by it. If you do not re-architect to use the new patterns, and
you
> do not use careful error trapping and keep very close track of your
objects
> then finalization order is still unpredictable.
>
> > Public object variables are not safe from alteration when passed as
> > parameters.
> > They never were. There was a common misconception that objects
bassed
> > ByVal couldn't be altered in VB6. In reality, it is the pointer to the
> > object that couldn't be altered.
>
> Different issue -- in VB6 if you pass a reference to a public property to
> another procedure it is not changed. Example:
> Class1 has: Public SomeData As String
> client code has: Call SetValue(oClass1.SomeData)
> If the "SetValue" routine changes the value of the parameter the change is
> lost in VB6. It is not lost in VB.Net. I don't expect this to be a big
> issue but it may affect some people.
>
> > Procedure parameters are not by default passed ByRef anymore.
> > Cosidering the IDE forces you to use ByVal or ByRef (it inserts it
if
> > you don't), I doubt there will be any confusion.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
>
> > Static is not supported as a procedure level modifier.
> > You can still declare the variable at the top of the class, where it
> > belongs anyways.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
> (and the "where it belongs" is debatable - in the case of a variable that
> needs only local scope but module-level lifetime the Static modifier was
> invaluable and prevented many accidental misuses of module-level
variables)
>
> > Parenthesis are not optional when calling procedures.
> > The IDE adds them if you forget, so it's no big deal.
>
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Set is not supported for object assignment.
> > Like "Let", it's no longer needed.
>
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > UDTs are not by default contiguous blocks of memory, but are objects.
> > Complete nonsense. All objects are in contiguous blocks of memory.
The
> > change for structs is that the layout is not garunteed, unless you ask
for
> a
> > particular order.
>
> All objects are not contiguous blocks of memory in VB.Net but UDTs were
not
> contiguous blocks in VB6 either. The point I think is being made here is
as
> you describe and that's going to affect a lot of code.
>
> > Enums will not be recognized unless fully-qualified.
> > Completely wrong. You can use imports on an Enum if you want.
>
> No, the name still has to be qualified. You can quibble with "fully" but
> you still have to include the enum name as well as the member name.
>
> > While/Wend loops are not supported.
> > Wend was renamed End While. A silly change, but no big deal.
>
> To you, maybe. To people suporting code both in VB.Net and VB6 it's still
a
> change that must be dealt with and one with little justification.
>
> > And, Or, XOr, and Not are not bitwise operators.
> > No, but BitAnd, BitOr, and BitNot are.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > Label controls will not have a Caption property.
> > It's just called Text, no big deal.
>
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
> > The Tag property is not supported.
> > It's available via Tag, a property extender. Any object can now have
a
> > tag. In fact, you can have several tags if you want. And I haven't even
> > touched inheritance.
>
> Using Extenders is very different than using a direct property. It may
> accomplish the same goal but it does not make the statement inaccurate.
>
> > Top-level menus may not be used as context menus.
> > Instead you build them seperately, which is better than having a
bunch
> > of hidden menus at the top of the screen.
>
> That does not make it inaccurate - it's a change that people need to
> understand.
>
>
> You are completely correct that there are new, sometimes much better, ways
> to do things that used to be the standard in VB6. That does not change
the
> fact that VB developers essentially need to learn an entirely new language
> and does not make what's on Karl's page "inaccurate". VB.Net, on it's own
> merits, may be a good tool but for people expecting to upgrade from VB6 to
> VB.Net it's important that the differences be highlighted so that they
> understand the maginitude of the task. For independent developers who can
> wrap up a completed project, deliver it and move on to the next client the
> task of switching to VB.Net may be relatively simple - it just becomes
> another option when bidding on a project. For those with an existing
> codebase of mission-critical VB apps it's more like hitting a brick wall.
> In many cases it's not going to be feasible to rewrite everything in
VB.Net
> and depending on how tightly new development needs to tie in to existing
> apps it may be more appropriate to do that in VB6 as well.
>
>
Michael (michka) Kaplan
canNOT do what you did before. You have a way to get the same functionality,
but that is not the same thing as saying you can still do this.
Its like if they took way the ability to multiply by seven but gave us
shifting. They could then easily claim that with left shifting by 8 and
subtracting left shifting by 1 you get the same functionality. They would
even be right. But it ain't the same thing as being able to just flipping
multiply.
The vast majority of that list is changes of that magnitude.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Victoria French (Zorien)" <victori...@zorien.com> wrote in message
news:#cLM4zXjAHA.1580@tkmsftngp02...
Bill McCarthy
"Michael (michka) Kaplan" <forme...@spamfree.trigeminal.nospam.com> wrote
in message news:OnXTK1ZjAHA.1232@tkmsftngp05...
> When the syntax changes as much as it does in some of these cases, you
truly
> canNOT do what you did before. You have a way to get the same
functionality,
> but that is not the same thing as saying you can still do this.
>
> Its like if they took way the ability to multiply by seven but gave us
> shifting. They could then easily claim that with left shifting by 8 and
> subtracting left shifting by 1 you get the same functionality. They would
> even be right.
you mean i = (i << 3) - i;
(of course not vary useful for FP's though <g>)
Thor Olson
Dim a As System.Array
a = System.Array.CreateInstance(GetType(Int32), New Int32() {20}, New
Int32() {-5})
looks more like "C++" at its worst. I guess the bottom line is you can do
it, not really from within the VB syntax, but rather by making system
calls...
I love the .Net concept, but it does appear that they've pushed VB back from
a third generation
language towards being a second generation language. (The whole point of a
3 GL is shield the
developer from the need to make direct system calls and to make the
transport of programs from
one environment to another as transparent as possible.) I hope that
Microsoft does better as the
beta progresses. This is the second time they've introduced a new version
of VB that had poor/no
backward compatibility. It is very difficult to build large systems on
quicksand.
"Thor Olson" <Ol...@nospam.terabase.com> wrote in message
news:OBGj2$GjAHA.2064@tkmsftngp02...
> Arrays may not have a lower bound other than zero.
> They can, the syntax is just different.
>
> Can someone tell me what the syntax is ?? (The help files
> explicitly say you can't and list it as one of the differences
> between VB6 and VB.NET.)
>
And I have no problem when looking at the following:
OLD:
Dim a(-5 to 14) As Long
NEW:
Dim a As System.Array
a = System.Array.CreateInstance(GetType(Int32), New Int32() {20}, New
Int32() {-5})
with the statement that they are not supported. The NEW syntax is a whole
new animal.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Bill McCarthy" <Bill...@iprimus.com.au> wrote in message
news:ur2KcLHjAHA.1728@tkmsftngp04...
> Hi Bob, Thor,
> "Bob Butler" <butl...@earthlink.net> wrote in message
> news:ekgOoDHjAHA.2104@tkmsftngp05...
> >
> > As an example, this is one way to create an array with a lower bound of
1
> > and an upper bound of 10:
> > Dim x As Array = System.Array.CreateInstance(GetType(Integer), 10, 1)
> >
>
> Actually I think that creates a two dimension array. For non zero lbound,
> you have to use the Int32() array arguments for the indexes, eg:
Jonathan Allen
> it, not really from within the VB syntax, but rather by making system
> calls...
It is not a system call. It is just using the system namespace, which covers
virtually everything.
--
Jonathan Allen
"Thor Olson" <Ol...@nospam.terabase.com> wrote in message
news:#inPKSgjAHA.492@tkmsftngp03...
Karl E. Peterson
> The point that he is inaccurate is correct IMO.
That's inaccurate as well as incorrect.
> When you tell someone that
> something can't be done and don't explain any furthure...
I *defy* you to cite where I state something, anything, can't be done?
> you are giving wrong information.
That would be correct, if it applied. Since it doesn't, it's sophistry, at best.
> Perhaps his points are valid
Damn straight. The *point* of that list, as stated up-top, is to highlight issues
that deserve your attention if you want to migrate code from VB to VFred. Perhaps?
Do you take issue with this point?
> but his statements are incorrect.
Which one(s)? I'm eager to make sure each and every one of those bullets is 100%
accurate.
> I was raised to believe that if you only tell half the truth or
> leave something out... you're not telling the truth at all.
Well, aren't you the little hypocrite, then? Either that, or you're intentionally
being misleading. Which is it?
Btw, Microsoft willingly acknowledges (or chooses to ignore) each point I raise, in a
response document they've asked me to post on that same page. Scroll to the bottom
of the list to see their response.
Thanks... Karl
--
http://www.mvps.org/vb/rants/vfred.htm
Bob Butler
<cut>
> Btw, Microsoft willingly acknowledges (or chooses to ignore) each point I
raise, in a
> response document they've asked me to post on that same page. Scroll to
the bottom
> of the list to see their response.
>
> Thanks... Karl
> --
> http://www.mvps.org/vb/rants/vfred.htm
Wow... the propaganda machine was working overtime there. Most of it is
literally true although it certainly glosses over a lot of the potential
problems. Some excerpts that really struck me as disingenuous:
"Microsoft Visual Basic.NET is the next version of Visual Basic"
Not good to start off with a whopper like that!
"In addition, Visual Basic.NET delivers XCOPY deployment of Windows
applications"
So does VB6 when you have all the runtimes/etc installed and just need to
send out an updated EXE. If clients have the .Net platform installed (along
with updates/service packs/whatever) then installs will be easier but that's
a big if.
"As some of the .NET Framework technologies are based around modern 32-bit
and
64-bit technologies, it makes sense to update the data sizes to the new
technology."
Sorry, but it makes no sense to rename keywords like that. Leave
Integer/Long alone and add new keywords or drop Integer/Long and just go to
the IntXX names consistently. Renaming keywords just adds to the confusion
when moving between versions and makes upgrading hell.
"The Currency data type does not provide sufficient accuracy to avoid
rounding errors,
so Decimal was created as its own data type"
Huh? That's some pretty circuitous logic....
"Fixed-length strings are not supported in the first version of the CLR.
This support will be added in a later version"
That's nice to hear, although by the time code is ready to go to a 'later
version' it may not be so important. Moving from VB6 to VB.Net is where the
loss of fixed-length strings is going to be a problem.
"In most cases this is not an issue." (also regarding fixed-length strings)
I'd really like to know how that conclusion was reached. Most fixed-length
strings I've seen are in UDTs for file I/O or API calls and the change to
the marshalling attributes is not going to be clear for a lot of VB
developers. I think they may differ on whether it's an issue or not.
"For language interoperability, a consistent representation is needed across
all languages" (regarding True)
Bullshit
"Using Nothing instead of a special Empty value reduces complexity in the
language"
For whom?
"Null values and IsNull functions are commented with an upgrade warning."
The warning is needed more when it detects string concatenation with a field
object's value since that's where code is most likely going to have to
change
"Visual Basic.NET declarations for "As New" are far more efficient than the
same
declaration in Visual Basic 6.0."
True, but that's because they are less functional.
"It is rare that this will be an issue. However, if code tries to use a
class after
it has been set to nothing, it will cause an easily detectable run-time
exception.
The code can then be easily modified"
Uh huh. I thought MS was supposed to have reviewed some of the code that's
out there? I've seen plenty that could be a nightmare to modify. It will
be easily detectable though, the users will be calling repeatedly.
"This tracing process runs as a background task" (regarding garbage
collection)
I hope that's being used in a generic sense since as I understand it the GC
pre-empts any managed code while it runs.
"In most cases, this change will not cause a problem. If you have code that
holds a
resource handle open (e.g., SQL Server connections or file handles), you
should
explicitly close the handle. The problem is easily detected and causes a
run-time error."
Right. Anytime I leave a file or connection open too long I get a runtime
error... was somebody smoking something when they wrote that?
"To enable interoperability with other languages, all arrays must have a
lower bound of zero. "
Bullshit
"This change is necessary in order to support short-circuiting evaluation of
the
And and Or operators. The advantage of short-circuiting And and Or operators
is
that they reduce the number of bugs in code and simplify writing code."
Uh huh. And the bugs introduced by changing the meanings of keywords in the
language and the order of precedence for them don't count for anything.
"A more common scenario for ParamArray arguments is for them not to modify
variables
that are passed in to them."
Is that purely guesswork or is there any evidence for it at all?
"The Get and Set functions for a property must both have the same level of
accessibility.
This allows Visual Basic.NET to interoperate with other .NET languages."
Bullshit.
"To be consistent with other block structures, the terminating statement for
While is now End While."
Right up there with End Do and End For.
"GoSub…Return is a nonstructured programming construct."
Uh huh. According to what definition?
"Having inheritance available as a tool makes the built-in controls
significantly more
flexible. In Visual Basic 6.0 you needed the Tag property because you could
not
extend the built-in controls. In Windows Forms you can use inheritance to
extend the
built-in controls and add your own properties. Not only can you add as many
properties
as you like, you can also make those properties strongly typed."
Yep, you can do all sorts of new things but you can't use your code that
uses Tag for some very simple purposes until you make some fairly hefty
revisions. I have yet to understand why adding new capabilities requires
that old ones have to be dropped, especially when retaining the old ones
would not interfere with the new ones at all.
"Windows Forms simplifies form layout by always making layout in pixels."
Simplifies it for whom?
"The MousePointer property on the Screen object returns or sets a value
indicating the
type of mouse pointer displayed when the mouse is outside your application's
forms at run time."
Huh? When I move to other apps I see whatever pointer they have defined. I
use Screen.Mousepointer to easily set or remove the hourglass just for my
app without affecting the normal setting for all forms and controls.
Sjoerd Verweij
Karl,
I'm really curious: why do you keep pretending that there is no such
thing as an upgrade wizard? Not that that would remove everything from
the list, but it'd sure add some perspective.
Maybe adding "this will / will not be handled by the upgrade wizard"?
Sjoerd
Karl E. Peterson
> Wow... the propaganda machine was working overtime there. Most of it is
> literally true although it certainly glosses over a lot of the potential
> problems.
Lots of rationalizations, too. Truth seems illusive here.
> Some excerpts that really struck me as disingenuous:
>
> "Microsoft Visual Basic.NET is the next version of Visual Basic"
> Not good to start off with a whopper like that!
<g>
> "In addition, Visual Basic.NET delivers XCOPY deployment of Windows
> applications"
> So does VB6 when you have all the runtimes/etc installed and just need to
> send out an updated EXE. If clients have the .Net platform installed (along
> with updates/service packs/whatever) then installs will be easier but that's
> a big if.
Good point. (And, I gotta say, I find it real interesting that this is now at the
top of their list of claims. It is, it seems, about the _only_ benefit we can offer
to clients when proposing ports/rewrites.)
> "As some of the .NET Framework technologies are based around modern 32-bit and
> 64-bit technologies, it makes sense to update the data sizes to the new
> technology."
> Sorry, but it makes no sense to rename keywords like that. Leave
> Integer/Long alone and add new keywords or drop Integer/Long and just go to
> the IntXX names consistently. Renaming keywords just adds to the confusion
> when moving between versions and makes upgrading hell.
Giving one existing keyword the properties of another is EVIL.
> "The Currency data type does not provide sufficient accuracy to avoid
> rounding errors, so Decimal was created as its own data type"
> Huh? That's some pretty circuitous logic....
I liked that one, too. <g> Can't you just picture the day when Decimal "isn't
accurate enough"? (And isn't this how we got Currency in the first place?)
> "Fixed-length strings are not supported in the first version of the CLR.
> This support will be added in a later version"
> That's nice to hear, although by the time code is ready to go to a 'later
> version' it may not be so important. Moving from VB6 to VB.Net is where the
> loss of fixed-length strings is going to be a problem.
Yep. Empty promise, there.
> "In most cases this is not an issue." (also regarding fixed-length strings)
> I'd really like to know how that conclusion was reached.
Simple, in most cases, 'softies use C. <g>
> "For language interoperability, a consistent representation is needed across
> all languages" (regarding True)
> Bullshit
Couldn't be any clearer than that.
> "Using Nothing instead of a special Empty value reduces complexity in the
> language"
> For whom?
Heheheh... Choices. Some folks just can't deal with choices.
> "Null values and IsNull functions are commented with an upgrade warning."
> The warning is needed more when it detects string concatenation with a field
> object's value since that's where code is most likely going to have to
> change
Good point!
> "Visual Basic.NET declarations for "As New" are far more efficient than the
> same
> declaration in Visual Basic 6.0."
> True, but that's because they are less functional.
LOL!
> "It is rare that this will be an issue. However, if code tries to use a
> class after
> it has been set to nothing, it will cause an easily detectable run-time
> exception.
> The code can then be easily modified"
> Uh huh. I thought MS was supposed to have reviewed some of the code that's
> out there? I've seen plenty that could be a nightmare to modify. It will
> be easily detectable though, the users will be calling repeatedly.
The PSS guys I've talked to are terrified.
> "This tracing process runs as a background task" (regarding garbage
> collection)
> I hope that's being used in a generic sense since as I understand it the GC
> pre-empts any managed code while it runs.
They wouldn't get confused on something like that, right? (Then again, they did use
Long, not Integer, in those INI declarations. <g>)
> "In most cases, this change will not cause a problem. If you have code that
> holds a
> resource handle open (e.g., SQL Server connections or file handles), you
> should
> explicitly close the handle. The problem is easily detected and causes a
> run-time error."
> Right. Anytime I leave a file or connection open too long I get a runtime
> error... was somebody smoking something when they wrote that?
ROFLMAO! Think shrooms, man. :-)
> "To enable interoperability with other languages, all arrays must have a
> lower bound of zero. "
> Bullshit
Yep. Bullshit. Unmitigated.
> "This change is necessary in order to support short-circuiting evaluation of the
> And and Or operators. The advantage of short-circuiting And and Or operators is
> that they reduce the number of bugs in code and simplify writing code."
> Uh huh. And the bugs introduced by changing the meanings of keywords in the
> language and the order of precedence for them don't count for anything.
I pointed out to them that short-circuiting was *already* supported -- at least for
those who know what it is -- when I asked them to please confirm they *really* wanted
this posted. <g>
> "A more common scenario for ParamArray arguments is for them not to modify
> variables
> that are passed in to them."
> Is that purely guesswork or is there any evidence for it at all?
Oh, who knows? Supposedly OOP is the #1 request, yet fully 80% of all VB users don't
even use classes. (Think shrooms, man. <g>)
> "The Get and Set functions for a property must both have the same level of
> accessibility.
> This allows Visual Basic.NET to interoperate with other .NET languages."
> Bullshit.
The all-purpose answer, yep.
> "To be consistent with other block structures, the terminating statement for
> While is now End While."
> Right up there with End Do and End For.
<bg>
> "GoSub…Return is a nonstructured programming construct."
> Uh huh. According to what definition?
Some language without such a handy feature, no doubt.
> "Having inheritance available as a tool makes the built-in controls
> significantly more
> flexible. In Visual Basic 6.0 you needed the Tag property because you could
> not
> extend the built-in controls. In Windows Forms you can use inheritance to
> extend the
> built-in controls and add your own properties. Not only can you add as many
> properties
> as you like, you can also make those properties strongly typed."
> Yep, you can do all sorts of new things but you can't use your code that
> uses Tag for some very simple purposes until you make some fairly hefty
> revisions. I have yet to understand why adding new capabilities requires
> that old ones have to be dropped, especially when retaining the old ones
> would not interfere with the new ones at all.
Amazing, isn't it? Bob O'Bob's recent tagline says it pretty well.
> "Windows Forms simplifies form layout by always making layout in pixels."
> Simplifies it for whom?
Heheheh... Guys who write frameworks?
> "The MousePointer property on the Screen object returns or sets a value
> indicating the
> type of mouse pointer displayed when the mouse is outside your application's
> forms at run time."
> Huh? When I move to other apps I see whatever pointer they have defined. I
> use Screen.Mousepointer to easily set or remove the hourglass just for my
> app without affecting the normal setting for all forms and controls.
See? They never even read their own docs. No wonder we suffer. :-)
Thanks... Karl
Karl E. Peterson
> I'm really curious: why do you keep pretending that there is no such
> thing as an upgrade wizard? Not that that would remove everything from
> the list, but it'd sure add some perspective.
Whether a wizard exists is not in question.
> Maybe adding "this will / will not be handled by the upgrade wizard"?
Wouldn't be supported by the facts in evidence, would it?
Later... Karl
Sjoerd Verweij
> when moving between versions and makes upgrading hell.
How does it make upgrading hell if the wizard does it for you?
>"For language interoperability, a consistent representation is needed across
>all languages" (regarding True)
>Bullshit
No. Remember the huge flap about this on another news server? There
simply is no way to do this efficiently -- although my challenge for
anyone to prove me wrong there still stands.
>"Using Nothing instead of a special Empty value reduces complexity in the
>language"
>For whom?
They misspelled "Having both a Nothing and an Empty value is silly."
>"Visual Basic.NET declarations for "As New" are far more efficient than the
>same declaration in Visual Basic 6.0."
>True, but that's because they are less functional.
True. They're also far less likely to produce weird behavior.
>"It is rare that this will be an issue. However, if code tries to use a
>class afterit has been set to nothing, it will cause an easily detectable run-time
>exception. The code can then be easily modified"
>Uh huh. I thought MS was supposed to have reviewed some of the code that's
>out there? I've seen plenty that could be a nightmare to modify. It will
>be easily detectable though, the users will be calling repeatedly.
Oh, come on. You'll catch this stuff the first time you press F5,
you'll fix it and move on.
>"This tracing process runs as a background task" (regarding garbage
>collection)
>I hope that's being used in a generic sense since as I understand it the GC
>pre-empts any managed code while it runs.
It's a background thread that pauses all threads using the heap it's
collecting on. However, there are some nifty optimizations thrown in
as well.
>Right. Anytime I leave a file or connection open too long I get a runtime
>error... was somebody smoking something when they wrote that?
Yes, you get a runtime error and you can easily fix it. Do you test
your applications?
>"To enable interoperability with other languages, all arrays must have a
>lower bound of zero. "
>Bullshit
Fresh and steaming.
>"The Get and Set functions for a property must both have the same level of
>accessibility.
>This allows Visual Basic.NET to interoperate with other .NET languages."
>Bullshit.
They misspelled "we didn't do it in other languages, so we'd run into
problems". From the tone of some of the newsgroup-active Microsoft
employees, they just didn't think this one through.
>"To be consistent with other block structures, the terminating statement for
>While is now End While."
>Right up there with End Do and End For.
Those do not count because they have (optional) parameters.
>Yep, you can do all sorts of new things but you can't use your code that
>uses Tag for some very simple purposes until you make some fairly hefty
>revisions. I have yet to understand why adding new capabilities requires
>that old ones have to be dropped, especially when retaining the old ones
>would not interfere with the new ones at all.
I'd be amazed if VB.NET went gold without converting Tag use to use
the control extender.
>"Windows Forms simplifies form layout by always making layout in pixels."
>Simplifies it for whom?
Are you saying you never forgot a " * Screen.TwipsPerPixelX"?
Anyway, don't get me wrong. It's the Spin Machine at 13,000rpm :-)
Michael (michka) Kaplan
wizard does."
So Microsoft can come out in public and make broad claims for a product
starting almost two years before they plan to ship it, and every time
someone points out a problem we are told we should wait to see what the (as
yet unseen) final version of the upgrade wizard produces. I am not sure
which is worst:
1) The idea of a major piece of functionality not being done at code
complete time but instead being ready at the time of the second beta
2) The idea of code complete dates being AFTER the beginning of the public
beta instead of prior to the first Alpha.
3) The idea of the upgrade wizard being such a minor thing that it was not
felt that these guidelines would apply.
I honestly have no idea which is might be, but none of them sit very well
with me.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:OAO6CUulAHA.2252@tkmsftngp05...
Jeff Peil
>
> 1) The idea of a major piece of functionality not being done at code
> complete time but instead being ready at the time of the second beta
>
MichKa,
I'm sure you are quite aware that it was explicitly stated that Beta 1 was
an early beta and was *not* feature complete (and thus not code complete.)
Bill McCarthy
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a8b1dd3....@msnews.microsoft.com...
>
> >"For language interoperability, a consistent representation is needed
across
> >all languages" (regarding True)
> >Bullshit
>
> No. Remember the huge flap about this on another news server? There
> simply is no way to do this efficiently -- although my challenge for
> anyone to prove me wrong there still stands.
>
A challenge ?? Oh shucks, you shouldn't have <bg>, but considering you did:
The facts:
when you cast a Boolean value to an integer, it calls on the
Boolean.ToInt32, Boolean.ToInt16, and Boolean.ToInt64 functions that are
part of the CLR. If we look at them, you'll see they in utrn call on the
system.convert methods. Let's take the Boolean.ToInt32 case:
It calls on the System.Convert.ToInt32(Boolean), the IL for which is:
.method public hidebysig static int32 ToInt32(bool 'value') il managed
{
// Code size 7 (0x7)
.maxstack 8
IL_0000: ldarg.0
IL_0001: brtrue.s IL_0005
IL_0003: ldc.i4.0
IL_0004: ret
IL_0005: ldc.i4.1
IL_0006: ret
} // end of method Convert::ToInt32
Now if you simply change line 5 to ldc.i4.m1 instead of ldc.i4.1 then the
return value is -1. There is no efficiency hit. The decision to make the
converion to integer returning 1 for True instead of -1, was purely
arbitrary, and does not present any efficiency gains. In fact, it makes it
necessary to marshal data containing booleans wehn using COM. This in fact
requires copies of the data to be made, so it is probably slightly more
*inefficient* for it to be returning 1 instead of -1 when using COM interop.
Using the above modified as shown, you could use Int32 both in/out and the
boolean values would be correct. Sadly for some reason it seems those
relatively few C++ programmers have dictated what the CLR should be ,
regardless of the effect on the 6 million or so VB developers and regardless
of the issues when dealing with COM.
Does that answer your challenge ??
Ronald Laeremans [MSFT]
I'll try to stay clear of land mines and just offer some technical comments
to 2 points. I snipped everything else.
> > "In most cases this is not an issue." (also regarding fixed-length
strings)
> > I'd really like to know how that conclusion was reached.
>
> Simple, in most cases, 'softies use C. <g>
I don't understand your C argument. Use of fixed length buffers is endemic
in C/C++ code.
TCHAR FileSpec[MAX_PATH + 1];
> > "This tracing process runs as a background task" (regarding garbage
> > collection)
> > I hope that's being used in a generic sense since as I understand it the
GC
> > pre-empts any managed code while it runs.
>
> They wouldn't get confused on something like that, right? (Then again,
they did use
> Long, not Integer, in those INI declarations. <g>)
There is both a concurrent and a stop-the-world GC in the CLR. Stop the
world offer better aggregate troughput, concurrent offers more deterministic
timing behavior.
Ronald Laeremans
Visual C++ compiler team
Michael (michka) Kaplan
There is a specific benefit to having beta1 and beta2 (and sometimes even a
beta3) *after* feature complete. But no one from MS has claimed there would
be a beta3 or beta 4.
I do not know much about why such a departure from the usual methodology for
producing software that is solid had been done, but sans explanation it does
give one pause for thought....
Or perhaps a beta 3 is planned and they are just not saying anything yet?
This would nullify my concerns here rather effectively.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Jeff Peil" <jp...@bigfoot.com> wrote in message
news:ud0kgdvlAHA.1720@tkmsftngp02...
Michael (michka) Kaplan
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:utyf2BylAHA.2012@tkmsftngp05...
> Common sense would dictate that I should stay out of this thread.
Too late! <g> Just kidding.
> There is both a concurrent and a stop-the-world GC in the CLR. Stop the
> world offer better aggregate troughput, concurrent offers more
deterministic
> timing behavior.
Well, it kind of depends on your POV. With COM you took on the overhead of
refcounting but could as a side effect count on a ertain amount of
deterministic behavior for lifetimes. Yes, you can brute force things by
*making* the GC do its thing, but since the old behavior was "stop the one
person at the street corner" I would hardly consider the "stop the world"
behavior to be comparable. Yes, you do get that same person on the street
corner to stop, but you are also disrupting every single other person. Oops!
Yes, it is a model change -- and there are some cases where it is not a
change for the better. But you cannot claim that you *really* can get the
old behavior in any reasonable way, peformance wise.
Bob Butler
> > when moving between versions and makes upgrading hell.
>
> How does it make upgrading hell if the wizard does it for you?
I'm more concerned about ongoing support in both versions than a one-shot
global search & replace. I also expect to have to do copy&paste and the
wizard isn't going to be involved at all for that.
> >"For language interoperability, a consistent representation is needed
across
> >all languages" (regarding True)
> >Bullshit
>
> No. Remember the huge flap about this on another news server? There
> simply is no way to do this efficiently -- although my challenge for
> anyone to prove me wrong there still stands.
Yes, I've read the threads. At the VB source level TRUE can be whatever the
VB language wants it to be and nothing anybody has posted has refuted that
either. Making it conform to the CLR makes it easy for the VB->IL
translator only.
> >"Using Nothing instead of a special Empty value reduces complexity in the
> >language"
> >For whom?
>
> They misspelled "Having both a Nothing and an Empty value is silly."
>
> >"Visual Basic.NET declarations for "As New" are far more efficient than
the
> >same declaration in Visual Basic 6.0."
> >True, but that's because they are less functional.
>
> True. They're also far less likely to produce weird behavior.
We agree here -- I like this change actually even though it may cause some
issues. I just dislike the way MS attempts to present it.
> >"It is rare that this will be an issue. However, if code tries to use a
> >class afterit has been set to nothing, it will cause an easily detectable
run-time
> >exception. The code can then be easily modified"
> >Uh huh. I thought MS was supposed to have reviewed some of the code
that's
> >out there? I've seen plenty that could be a nightmare to modify. It
will
> >be easily detectable though, the users will be calling repeatedly.
>
> Oh, come on. You'll catch this stuff the first time you press F5,
> you'll fix it and move on.
This is precisely the kind of error that the compiler can not find. You
will not find it until your app tries to reference the object.
> >"This tracing process runs as a background task" (regarding garbage
> >collection)
> >I hope that's being used in a generic sense since as I understand it the
GC
> >pre-empts any managed code while it runs.
>
> It's a background thread that pauses all threads using the heap it's
> collecting on. However, there are some nifty optimizations thrown in
> as well.
>
> >Right. Anytime I leave a file or connection open too long I get a
runtime
> >error... was somebody smoking something when they wrote that?
>
> Yes, you get a runtime error and you can easily fix it. Do you test
> your applications?
In what case do you get a runtime error because you left an SQL connection
open?
> >"To enable interoperability with other languages, all arrays must have a
> >lower bound of zero. "
> >Bullshit
>
> Fresh and steaming.
>
> >"The Get and Set functions for a property must both have the same level
of
> >accessibility.
> >This allows Visual Basic.NET to interoperate with other .NET languages."
> >Bullshit.
>
> They misspelled "we didn't do it in other languages, so we'd run into
> problems". From the tone of some of the newsgroup-active Microsoft
> employees, they just didn't think this one through.
>
> >"To be consistent with other block structures, the terminating statement
for
> >While is now End While."
> >Right up there with End Do and End For.
>
> Those do not count because they have (optional) parameters.
So everything is to be consistent unless it isn't? The Wend/EndWhile change
is just ridiculous - either leave it alone or scrap the whole thing.
> >Yep, you can do all sorts of new things but you can't use your code that
> >uses Tag for some very simple purposes until you make some fairly hefty
> >revisions. I have yet to understand why adding new capabilities requires
> >that old ones have to be dropped, especially when retaining the old ones
> >would not interfere with the new ones at all.
>
> I'd be amazed if VB.NET went gold without converting Tag use to use
> the control extender.
>
> >"Windows Forms simplifies form layout by always making layout in pixels."
> >Simplifies it for whom?
>
> Are you saying you never forgot a " * Screen.TwipsPerPixelX"?
No, I'm saying there are times when using Twips (or any other choice) for
everything is more convenient for the developer and that forgetting to
adjust scales is my error. Forcing me to always use a single scale is
hardly a step forward and I get aggarvated when they imply it is for my
benefit that they made it simpler on themselves.
> Anyway, don't get me wrong. It's the Spin Machine at 13,000rpm :-)
At least <g>
If MS would just drop the act and say, OK, we are ending classic VB but for
VB developers we have a .Net language that will be very familiar and easy to
learn I'd be a lot less negative about it. It's the whole pretense that
this is an upgrade that really bites.
Bill McCarthy
"Bob Butler" <butl...@earthlink.net> wrote in message
news:Ozupdq1lAHA.1404@tkmsftngp02...
>
> Yes, I've read the threads. At the VB source level TRUE can be whatever
the
> VB language wants it to be and nothing anybody has posted has refuted that
> either. Making it conform to the CLR makes it easy for the VB->IL
> translator only.
>
Good point. And considering the implicit or explicit conversions in VB.NET
are NOT mapped directly to the CLR functions, there is nothing preventing
VB.NET from doing this.
A couple of interesting examples worth noting about how VB.NET behaves:
CStr - actually calls on Format functions and is locale sensitive. This
is quite different from C# and the CLR definitions for .ToString . Actually
in Beta 1 , Cdbl(Cstr(10.1)) will crash in VB.NET (on systems wherte the
decimal point is not . ) because of this as it does not map to ToString.
This also means that (string) Obj, returns a different result in C# compare
to VB's CStr(Obj) or Ctype(Obj, String)
Try.. Catch blocks. They actually set the err object in VB.NET. This
means that a C# function doing essentially thesame thing as VB.NET will
behave differently as only the VB.NET component will change the status of
the Err object, whether intentional or not.
It should be noted that the Try Catch one, I mentioned simply because it has
been purposefully made to behave in a non NET friendly manner, and has no
bearing on backward compatibility, but it does mean that interop is not as
it seems in VB.NET. You cannot port the same code to C# and have the same
behaviour. This applies to any method that has structured error handling !!
So by those standards, there is nothing stopping VB.NET having the
CInt32(Bool), CType(bool, Int32) etc all return -1 for Boolean. It would be
consistant with the VB.NET inconsistancies <g>
Larry Serflaten
"Bob Butler" <butl...@earthlink.net> wrote
> Yes, I've read the threads. At the VB source level TRUE can be whatever the
> VB language wants it to be and nothing anybody has posted has refuted that
> either. Making it conform to the CLR makes it easy for the VB->IL
> translator only.
I have a notion that when they say 'language interoperability' more often they mean
'multilingual programmer convenience'
;-)
LFS
Bob Butler
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:exTbnr2lAHA.368@tkmsftngp03...
No, the meaning I always get is that it makes the job of the translators
and/or the CLR easier. Making things easier for multilingual programmers
would be a better justification IMO.
Michael (michka) Kaplan
> > >"To be consistent with other block structures, the terminating
statement
> for
> > >While is now End While."
> > >Right up there with End Do and End For.
> >
> > Those do not count because they have (optional) parameters.
>
> So everything is to be consistent unless it isn't? The Wend/EndWhile
change
> is just ridiculous - either leave it alone or scrap the whole thing.
Actually, it has a clear cause. The WHILE keyword is one that is used in
C/C++; DO WHILE is not. The typical handling of translating control
structures from C to VB is to:
1) leave the initial keyword the same
2) remove the {
3) replace the } with an "END ______"
Therefore, While/End While is much more consistent with C. What any non-VB
programmer would think of in fact. :-)
Larry Serflaten
"Bob Butler" <butl...@earthlink.net> wrote
> > I have a notion that when they say 'language interoperability' more often
> they mean
> > 'multilingual programmer convenience'
>
> No, the meaning I always get is that it makes the job of the translators
> and/or the CLR easier. Making things easier for multilingual programmers
> would be a better justification IMO.
Some examples (from same doc):
Visual Basic.NET True has a value of 1. For language interoperability, a consistent representation is needed across all
languages.
Visual Basic.NET To enable interoperability with other languages, all arrays must have a lower bound of zero
Using Nothing instead of a special Empty value reduces complexity in the language and allows for better language
interoperability.
------
There are plenty of the type you indicate as well, but then in the docs they would use a different phrase.
EX:
Visual Basic.NET 7.0 updates string length declaration for interoperability with the .NET Framework and Runtime.
There are plenty of these, which match what you are saying. My original statement does seem to agree with their
own usage of the term 'language interoperability'.
LFS
Karl E. Peterson
> Common sense would dictate that I should stay out of this thread. However,
as a [former?] newsgroup junkie, I just can't help myself? <vbg>
> > > "In most cases this is not an issue." (also regarding fixed-length strings)
> > > I'd really like to know how that conclusion was reached.
> >
> > Simple, in most cases, 'softies use C. <g>
>
> I don't understand your C argument. Use of fixed length buffers is endemic
> in C/C++ code.
Ah, wrong take, though an understandable one. The point was that since the designers
don't actually _use_ the langauge, they could easily get confused and consider
certain features -- or more to the point, the lack of certain features -- to be "not
an issue." Your pointing out the ubiquity of this usage in C makes the point rather
well, in a really twisted way.
> > > "This tracing process runs as a background task" (regarding garbage
> > > collection)
> > > I hope that's being used in a generic sense since as I understand it the GC
> > > pre-empts any managed code while it runs.
> >
> > They wouldn't get confused on something like that, right? (Then again, they did
use
> > Long, not Integer, in those INI declarations. <g>)
>
> There is both a concurrent and a stop-the-world GC in the CLR. Stop the
> world offer better aggregate troughput, concurrent offers more deterministic
> timing behavior.
Did you mean to put that the other way around?
Thanks... Karl
Karl E. Peterson
> Does that answer your challenge ??
I see no answer to your answer? <g>
Later... Karl
Karl E. Peterson
> hardly a step forward and I get aggarvated when they imply it is for my
> benefit that they made it simpler on themselves.
Careful! Next thing we know, you'll be talking nonsense about naked emporers, and
such. <g>
Later... Karl
Karl E. Peterson
> I do love how people claim everyone should "wait to see what the upgrade
> wizard does."
P.T. Barnham had a special place in his heart for these folks.
Later... Karl
Bob Butler
"To the egress" ?
Which, by the way, is where I think a lot of VB developers may head. The
more I think about the MS reply document the more insulting it gets.
Ronald Laeremans [MSFT]
endemic
> > in C/C++ code.
>
> Ah, wrong take, though an understandable one. The point was that since
the designers
> don't actually _use_ the langauge, they could easily get confused and
consider
> certain features -- or more to the point, the lack of certain features --
to be "not
> an issue." Your pointing out the ubiquity of this usage in C makes the
point rather
> well, in a really twisted way.
since the people designing VB.Net use C, they look at every language feature
with a C perspective. If I now read you correctly you said that since they
never used VB, they don't know what features are core and should be left
allone and which aren't.
> > > > "This tracing process runs as a background task" (regarding garbage
> > > > collection)
> > > > I hope that's being used in a generic sense since as I understand it
the GC
> > > > pre-empts any managed code while it runs.
> > >
> > > They wouldn't get confused on something like that, right? (Then
again, they did
> use
> > > Long, not Integer, in those INI declarations. <g>)
> >
> > There is both a concurrent and a stop-the-world GC in the CLR. Stop the
> > world offer better aggregate troughput, concurrent offers more
deterministic
> > timing behavior.
>
> Did you mean to put that the other way around?
No. Stop the world has less overhead, so although a singe pause takes
longer, the average amount of CPU cycles the GC spends over the run of an
app is lower.
As to Mich's reply, I wasn't trying to debate ref counting vs tracing. Just
pointing out that there are 2 forms of tracing GC in the CLR. Which seemed
to have been put in doubt in the thread.
-Ronald-
Karl E. Peterson
> Sorry I misunderstood what you were saying. I thought you meant to say that
> since the people designing VB.Net use C, they look at every language feature
> with a C perspective.
Well, to be fair, you may have heard me express that notion a time or two in the
past. <g> I don't think it was predominant in this case, though.
> If I now read you correctly you said that since they
> never used VB, they don't know what features are core and should be left
> allone and which aren't.
Never is strong, but I'd be willing to with "rarely, if ever".
> > > There is both a concurrent and a stop-the-world GC in the CLR. Stop the
> > > world offer better aggregate troughput, concurrent offers more deterministic
> > > timing behavior.
> >
> > Did you mean to put that the other way around?
>
> No. Stop the world has less overhead, so although a singe pause takes
> longer, the average amount of CPU cycles the GC spends over the run of an
> app is lower.
I didn't understand how concurrant gave you better DF approximations? Seemed like
the *do it now, damnit!* approach would fit that case better. I suppose it's a
matter of perspective.
> As to Mich's reply, I wasn't trying to debate ref counting vs tracing. Just
> pointing out that there are 2 forms of tracing GC in the CLR. Which seemed
> to have been put in doubt in the thread.
Ah, I see now. Okay, I didn't read it that way, but I see how it could've been
interpreted like that. Yeah, my own response was not only hasty but heavily
tongue-in-cheek.
Thanks... Karl
Karl E. Peterson
I really tried to tell them that something like that shouldn't be rushed. That it
was more important to get it right, than to try recovering from a faulty execution.
Come to think of it, that seems to be an extremely recurring theme, lately. <sigh>
Later... Karl
--
[This space intentionally left blank.]
Michael (michka) Kaplan
Even if it sucks at RTM, even if it is a motherless son of a goat, even if
it ought to be flushed rather than shipped, it will sell. It will do well.
People will buy it. They might complain about it, it might take a little
time, but people will move in that direction.
Although many people misunderstand my motivations (especially people inside
Microsoft, according to the latest rumors I have been hearing), I am hoping
that they can be coerced into making those things that make it difficult and
that make migration/interversion compatibility/support for multiple versions
by developers suck less.
I feel a bit like Kind Canute, except without the fancy title, doing it. And
like you and others, I for damn sure don't feel like many people at
Microsoft appreciate it. :-(
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Bob Butler" <butl...@earthlink.net> wrote in message
news:eyaeDS5lAHA.1232@tkmsftngp05...
>
Bill McCarthy
> Hi Bill --
>
> > Does that answer your challenge ??
>
> I see no answer to your answer? <g>
>
D'oh.. not much of a challenge then was it <g>
Sjoerd Verweij
I don't see how this answers the problem with
If CSharpClass.BooleanProp = VBClass.BooleanProp Then
...
Patrick Steele
says...
Perhaps if C# emitted the same IL, we would be all set.
--
Patrick Steele
(pst...@ipdsolution.com)
Lead Software Architect
Image Process Design
Karl E. Peterson
Problem? What problem?
Later... Karl
Sjoerd Verweij
>> If CSharpClass.BooleanProp = VBClass.BooleanProp Then
>> ...
>
>Problem? What problem?
Can't help acting like a certain Smith & Jones character, can you?
Okay, what do you propose? That the = operator detects we're comparing
booleans, and interprets the above as
If (CSharpClass.BooleanProp <> 0) = (VBClass.BooleanProp <> 0) Then
...
Sheldon Rosenfeld
Ya know, I try to distance myself from these flame wars, but -
I believe that MS may do what it wishes vis-a-vis internal
representation of Boolean.
So say that bool true = 'banana' in VB >>>SOURCE<<< code,
and 'orange' in C# source.
Who cares???
They can compile it to 1/0 for both. (Or -1/0 = 1/0 to keep
old standards).
Sorry, maybe I'm thick, but what's your question?
Sheldon
Sjoerd Verweij <sjo...@sjoerd.org> wrote in message
news:3a8d788b....@msnews.microsoft.com...
Bill McCarthy
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a8d788b....@msnews.microsoft.com...
>
> Okay, what do you propose? That the = operator detects we're comparing
> booleans, and interprets the above as
>
> If (CSharpClass.BooleanProp <> 0) = (VBClass.BooleanProp <> 0) Then
> ...
>
What are you saying ? Are you saying that C# relies on a numeric value for
Booleans instead of True /False state ?? If so then C# is not CLS compliant,
but I don't believe that is the case anyway. In *fact* in C# you can't
implictly cast from boolean to integer. If you go back and read the IL I
showed, you'll see the boolean does a converion based on checking to see if
the value is 0 or not. You can actually test further this by putting some
bools in a strcture or an array, get an unsafe pointer to the structure and
set all the bits. The boolean still works as normal even if the internal
value is 255 unsigned. That is what a boolean is s'pose to do !!
BTW: what *actually* are ou talking about in regards C#'s behaviour ?
obviously the "=" operator in c# is for assignemnt not equality. Did you
mean "==" ???????
In any case, I think you are confusing booleans, with the boolean to integer
conversion.
Sjoerd Verweij
My point was that with an equal internal representation, boolean
comparison can be implemented more efficiently. As the point always
was: it's not impossible, but no matter what you do, something,
somewhere is going to have to do extra work if the underlying value is
not consistent across .NET languages.
Anyway, this is all way too academic, and I really don't feel like
re-doing the entire thread from devx...
Sjoerd
PS: The code was VB.
Sjoerd Verweij
>representation of Boolean.
Yes. The trouble starts when you convert it to another datatype.
Search the archives on devx, where all this flap started.
Karl E. Peterson
> >> I don't see how this answers the problem with
> >> If CSharpClass.BooleanProp = VBClass.BooleanProp Then
> >> ...
> >
> >Problem? What problem?
>
> Can't help acting like a certain Smith & Jones character, can you?
>
> Okay, what do you propose? That the = operator detects we're comparing
> booleans,
Great Turtle help us all, if an equality test can't determine what datatypes it's
comparing! :-)
Later... Karl
--
http://www.mvps.org/vb/rants/vfred.htm
Karl E. Peterson
>
> Anyway, this is all way too academic, and I really don't feel like
> re-doing the entire thread from devx...
Details bite (in the butt), sometimes, don't they? Tsk, tsk.
Bill McCarthy
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a8d88b0....@msnews.microsoft.com...
> Bill,
>
> My point was that with an equal internal representation, boolean
> comparison can be implemented more efficiently. As the point always
> was: it's not impossible, but no matter what you do, something,
> somewhere is going to have to do extra work if the underlying value is
> not consistent across .NET languages.
>
Look. The issue is NOT about the internal representation of boolean. It is
about the value when boolean is cast to Integer !!!!
Now I've showed you the IL the cast produces. There is no effect on
efficiency, their is no effect on interop etc, by making the value returned
via the conversion to -1 instead of 1.
As i said, yo uare confusing Booleans internal value, with the Boolean to
Integer conversion. Please have a look at the IL for the Boolean to integer.
You will see it calls on Convert.ToInt32(bool), and as I have shown there is
no impact on efficiency at all by having that return -1 instead of 1. I
have shown you this. These are the facts. If you want to claim otherwise
provide some proof, some code, something, OR admit that I have indeed
answered your challenge and that it is indeed not more efficient to return 1
instead of -1 !! Let's deal with facts shall we ? Can you handle the truth
??
Bill McCarthy
"Karl E. Peterson" <ka...@mvps.org> wrote in message
news:uf0U2WFmAHA.1220@tkmsftngp05...
>
> Great Turtle help us all, if an equality test can't determine what
datatypes it's
> comparing! :-)
>
hmm.. time to call on the great turtle them <bg> .. see below:
Public Sub Main()
Dim b(4) As Boolean
Dim ptr As Int32
Dim bln As Boolean
ptr = marshal.UnsafeAddrOfPinnedArrayElement(b, 0)
marshal.WriteInt32(ptr, -1)
bln = True
If bln = b(0) Then
Console.WriteLine(" bln does equal b(0)")
Else
Console.WriteLine(" bln does *NOT* equal b(0)")
End If
Console.WriteLine(" bln = {0} , b(0) = {1}", bln, b(0))
End Sub
output from that is
bln does *NOT* equal b(0)
bln = True , b(0) = True
Karl E. Peterson
--
[This space intentionally left blank.]
"Bill McCarthy" <Bill...@iprimus.com.au> wrote in message
news:#zzlneFmAHA.1856@tkmsftngp02...
Sjoerd Verweij
>Now I've showed you the IL the cast produces. There is no effect on
>efficiency, their is no effect on interop etc, by making the value returned
>via the conversion to -1 instead of 1.
Correct me if I'm wrong, but wasn't the IL you posted an internal
framework function? If it were changed there, wouldn't you have
changed it for all .NET languages?
Sjoerd
Bill McCarthy
Yep. That was the point.
Sjoerd Verweij
Bill,
>> Correct me if I'm wrong, but wasn't the IL you posted an internal
>> framework function? If it were changed there, wouldn't you have
>> changed it for all .NET languages?
>
>Yep. That was the point.
And how is this supposed to support the assertion that it is possible
to have True -1 in VB and 1 everywhere else efficiently?
Puzzled,
Sjoerd
Bill McCarthy
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a8d9c33....@msnews.microsoft.com...
>
> And how is this supposed to support the assertion that it is possible
> to have True -1 in VB and 1 everywhere else efficiently?
>
It doesn't directly. The main thing it supports is the assertion that the
CLR can return -1 just as efficiently. But the other thing it clearly shows
is how the value for the integer is obtained. The return value is determined
by comparing the boolean to 0 then returnign the appropiate value. So, just
like CStr does not map directly to ToString in VB, CInt(bool) can simply do
the equivalent of the Convert.ToInt32(bool) at absolutely no extra overhead.
So whether you make the change across all the CLR, or just change the
CInt(bool) behaviour of VB, there is NO extra overhead, there is no loss in
efficiency. Them's the facts !!
Sjoerd Verweij
>It doesn't directly. The main thing it supports is the assertion that the
>CLR can return -1 just as efficiently.
That's wonderful, but I really don't think MS is going to change the
CLR (and thus the representation of Boolean in all languages) because
of this.
>So whether you make the change across all the CLR, or just change the
>CInt(bool) behaviour of VB, there is NO extra overhead, there is no loss in
>efficiency.
Yes, but neither is a viable option. Changing the CLR -- see above.
And changing CInt? Are you seriously saying that you'd be okay with
CInt(bFoo) <> bFoo.ToInt32 ?!
Sjoerd
Bill McCarthy
> Bill,
>
> >It doesn't directly. The main thing it supports is the assertion that the
> >CLR can return -1 just as efficiently.
>
> That's wonderful, but I really don't think MS is going to change the
> CLR (and thus the representation of Boolean in all languages) because
> of this.
>
You are still confusing Boolean's with the Boolean to integer value. They
would not be changing the Boolean. In fact they would NOT even touch the
Boolean class at all. They simply change the System.Convert.ToInt32(bool)
method etc.
> >So whether you make the change across all the CLR, or just change the
> >CInt(bool) behaviour of VB, there is NO extra overhead, there is no loss
in
> >efficiency.
>
> Yes, but neither is a viable option. Changing the CLR -- see above.
> And changing CInt? Are you seriously saying that you'd be okay with
> CInt(bFoo) <> bFoo.ToInt32 ?!
>
First, you claim it's not a viable option, but yet you give no reason as to
why you claim that. Secondly, you are ignoring that your *challenge* was to
show that it could be done efficiently. I have shown that, have I not ?
And on the last point you raise, I don't see you jumping up and down about
how CInt(string) is different from string.ToInt32, or how CDbl(string) <>
string.ToDbl() etc..
Sjoerd Verweij
>You are still confusing Boolean's with the Boolean to integer value. They
>would not be changing the Boolean. In fact they would NOT even touch the
>Boolean class at all. They simply change the System.Convert.ToInt32(bool)
>method etc.
Ah, okay. Do you think C# programmers would welcome that change?
>First, you claim it's not a viable option, but yet you give no reason as to
>why you claim that. Secondly, you are ignoring that your *challenge* was to
>show that it could be done efficiently. I have shown that, have I not ?
Yes, you have. The challenge would have to be "how to efficiently
implement True = -1 in VB without affecting other .NET languages".
Damn me for not being explicit enough :-)
>And on the last point you raise, I don't see you jumping up and down about
>how CInt(string) is different from string.ToInt32, or how CDbl(string) <>
>string.ToDbl() etc..
Haven't even looked into that -- the C* functions are dead to me. They
should be the same, methinks, but that's another thread. We've
hijacked this one enough, I think.
Sjoerd
Bill McCarthy
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a8daca4....@msnews.microsoft.com...
>
> Ah, okay. Do you think C# programmers would welcome that change?
>
What C# programmers ? At present there are no C# programmers (outside of at
MS), only C# beta testers. There is no better time to fix this than now
while the program is still in beta. The real issue is how many people does
this impact on. 0 vs 6.5 million, and all the COM compnents out there too.
The numbers all stack up in favour of -1 being the way to go.
>
> Yes, you have. The challenge would have to be "how to efficiently
> implement True = -1 in VB without affecting other .NET languages".
> Damn me for not being explicit enough :-)
>
Ha, ha. Too late <g> In any case it does not impact on any language that
uses booleans properly. If the language operates on the value after it is
converted to Int32 then that language is not only inefficient, but also is
breaking the rules of what boolean is.
>
> Haven't even looked into that -- the C* functions are dead to me. They
> should be the same, methinks, but that's another thread. We've
> hijacked this one enough, I think.
>
Sure. In fact they probably do deserve a thread of there own. I think a lot
of people would like to know why you can't round trip a double to a string
and back again using CStr and Cdbl.
Jeff Peil
> What C# programmers ? At present there are no C# programmers (outside of
at
> MS), only C# beta testers. There is no better time to fix this than now
> while the program is still in beta. The real issue is how many people does
> this impact on. 0 vs 6.5 million, and all the COM compnents out there too.
> The numbers all stack up in favour of -1 being the way to go.
As I pointed out elsewhere Bill, the real problem is the impact this has on
C, some C derivitives, and potentially other languages with similar typing
rules for unsigned types.
As the CLR level goal is language neutrality, I would view there being only
two acceptable choices in the libraries:
1) Refuse to convert between integral and boolean types (IOW force each
language to supply it's own independent mechanism to do so)
2) Choose a value that is likely to give the greatest level of language
neutrality (not the greatest number of end-users, the greatest number of
languages that are likely to want to run on the CLR and take advantage of
the library.)
Option (1) seems to be in much worse taste to me, and there isn't any good
reason for the URT team to tear out such support, as all it impacts is areas
where a language touches the libraries.
It would certainly be possible to create a language under the CLR as it
exists today that used -1 as the value, such a language would just be making
a choice that reduced it's interoperability with the URT and other languages
that went along with the URT in this regard.
The numbers *where it matters* are clearly not in favor of a -1
representation, as with most statistics if you used the wrong numbers you
can get the wrong conclusions.
David Bayley
> The numbers all stack up in favour of -1 being the way to go.
There appears to be some obfuscation of the argument going on here, and I
don't like politics. But as I understand it, the above statement just about
sums it up.
IOW, the framework function Convert.ToInt32(<True>) should return -1,
according to majority rule and back-compat reasons (and possibly some
technical reasons about -1 being Not 0).
Is that a fair assessment?
--
David.
Jeff Peil
"David Bayley" <dba...@aebacus.com> wrote in message
news:uLHFnQJmAHA.1472@tkmsftngp03...
>
> IOW, the framework function Convert.ToInt32(<True>) should return -1,
> according to majority rule and back-compat reasons (and possibly some
> technical reasons about -1 being Not 0).
>
> Is that a fair assessment?
It would be a fair assessment of Bill's claim.
As to "majority rule" it depends on the majority you look at. Of course, the
impact it would have, in general, to other languages in each case is worth
considering too (for example, consider a language where 1 is already the
defined result for a boolean expression, that does not define a distinct
boolean type separate from it's normal integral types, such a language
would be impacted far worse than those languages where boolean is already a
distinct recognized type.)
Bill McCarthy
"Jeff Peil" <jp...@bigfoot.com> wrote in message
news:uGZJaRJmAHA.2232@tkmsftngp05...
>
> As I pointed out elsewhere Bill, the real problem is the impact this has on
> C, some C derivitives, and potentially other languages with similar typing
> rules for unsigned types.
>
<snip>
Well I disagree with that statement, but you knew that. There is nothing
stopping those languages using boolean . It does not cause them any problems
what so ever. In fact what I proposed solves that issue and the VB6
compatibility issue. For languages that don't have a strict boolean type, they
would see booleans simply as a byte with value of 1. We are talking about
changing the Convert.ToInt32(bool) result, not the internal value of booleans.
And let's look at your claim even further. Which language are you talking
about that is in .NET that has a problem with the booleans. You are talking
about managed code, yes ??