My Wish
jimo
studio 6, specifically visual basic. I, like a lot of my peers are
attempting to upgrade our existing applications using the .NET upgrade tool
and we are not having a lot of success. We have been writing code with VB
for some years now. Now that we have a huge reusable code base developed,
your latest beta of your new language does not support our existing work.
Flex Grids don't upgrade, simple calls to functions are failing. the list
goes on and on. Do you guys want to fail? I sure don't.
How long are you going to support 32 bit Visual Basic in years? Will you
port Visual Basic 6 to 64 bit or are we screwed? You know, we went from 16
bit to 32 with not major issues and I thought based on that experience that
you guys knew how to make this work. RDO 2.0 isn't working? I called and
spoke to your engineers and asked them the best way to access data for
performance and scalability. They told me to use RDO, not the data control
the Remote Data Object. They also said to get the scalability I wanted to
not work with open cursors but to open the table, load the data into an
array and close connection. What a great idea. It works perfectly. Here's
how I get data from the database and load it into a flex grid. I can't get
simple code like this to run because you don't support it any more. You can
say what ever you want to about this code, it's self documenting, it's
simple, it's fast and it works.
Public Sub Show_Purchase_Order_Detail(ComponentPartNumber As String)
On Local Error GoTo ShowPODetailErr
Dim P As rdoConnection, PODetail As rdoResultset
rdoDefaultCursorDriver = rdUseOdbc
ODBCStr1$ = "DSN=PurchaseOrderDetail;UID=" + ODBCLoginName$ +
";PWD=;DATABASE=ShopFloor;"
Set P = rdoEnvironments(0).OpenConnection("PurchaseOrderDetail",
rdDriverNoPrompt, False, ODBCStr1$)
Qry$ = ""
Qry$ = "SELECT PartNumber, OrderNumber, LineNumber, OrderType, Quantity,
DueDate, BlanketOrderFlag, QtyOk, QtyReceived, QtyInInsp, QtyInMRB,
QtyComplete, QtyScrapped, QtyOpen, PromiseDate, ReleaseDate "
Qry$ = Qry$ + "FROM PurchaseOrderDetail "
Qry$ = Qry$ + "WHERE PartNumber = '" + Trim$(ComponentPartNumber) + "' "
Qry$ = Qry$ + "ORDER BY OrderNumber, LineNumber"
Set PODetail = P.OpenResultset(Qry$, rdOpenKeyset, rdConcurRowVer)
Qry$ = ""
With msfPurchaseOrder
.Clear
.Rows = PODetail.RowCount + 1
Init_Purchase_Order_Grid
For PORow% = 1 To PODetail.RowCount
For POColumn% = 0 To 15
.TextMatrix(PORow%, POColumn%) = PODetail(POColumn%)
Next POColumn%
PODetail.MoveNext
Next PORow%
End With
Set PODetail = Nothing
P.Close
Exit Sub
ShowPODetailErr:
Resume Next
End Sub
Public Sub Init_Purchase_Order_Grid()
With msfPurchaseOrder
.ForeColorFixed = &H8000000F
.Cols = 16
'set the grid column widths
For I% = 0 To 15
.ColWidth(I%) = 1200
.ColAlignment(I%) = 0
Next I%
'label the columns
.Row = 0
.Col = 0
.Text = "Part"
.Col = 1
.Text = "Order"
.Col = 2
.Text = "Line"
.Col = 3
.Text = "Status"
.Col = 4
.Text = "Quantity"
.Col = 5
.Text = "DueDate"
.Col = 6
.Text = "Blanket"
.Col = 7
.Text = "QtyOk"
.Col = 8
.Text = "QtyReceived"
.Col = 9
.Text = "QtyInInsp"
.Col = 10
.Text = "QtyInMRB"
.Col = 11
.Text = "QtyComplete"
.Col = 12
.Text = "QtyScrapped"
.Col = 13
.Text = "QtyOpen"
.Col = 14
.Text = "PromiseDate"
.Col = 15
.Text = "ReleaseDate"
.ForeColorFixed = &H80000012
.Refresh
End With
End Sub
Joe "Nuke Me Xemu" Foster
> I wish someone at Microsoft could tell me what the plans are for visual
> studio 6, specifically visual basic. I, like a lot of my peers are
> attempting to upgrade our existing applications using the .NET upgrade tool
> and we are not having a lot of success. We have been writing code with VB
> for some years now. Now that we have a huge reusable code base developed,
> your latest beta of your new language does not support our existing work.
> Flex Grids don't upgrade, simple calls to functions are failing. the list
> goes on and on. Do you guys want to fail? I sure don't.
"What do you want to rewrite today?"
> How long are you going to support 32 bit Visual Basic in years? Will you
> port Visual Basic 6 to 64 bit or are we screwed? You know, we went from 16
> bit to 32 with not major issues and I thought based on that experience that
> you guys knew how to make this work. RDO 2.0 isn't working? I called and
> spoke to your engineers and asked them the best way to access data for
> performance and scalability. They told me to use RDO, not the data control
> the Remote Data Object. They also said to get the scalability I wanted to
> not work with open cursors but to open the table, load the data into an
> array and close connection. What a great idea. It works perfectly. Here's
> how I get data from the database and load it into a flex grid. I can't get
> simple code like this to run because you don't support it any more. You can
> say what ever you want to about this code, it's self documenting, it's
> simple, it's fast and it works.
Why do you think Microsoft had to break it? It's very embarrassing for
them when other people's programs work but Microsoft Office doesn't!
--
Joe Foster <mailto:jlfoster%40znet.com> Greed = God? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Ed Hickey
I wish I could tell you exactly what will become of VB6, but as I cannot
see the future, I'm not really sure myself. Suffice it to say that VB6
will be around for quite some time. If you are currently developing in
VB4-16 bit, and you call for support, we will support you, and that product
is 5 years old now. VB6 will be supported in the future, it is not going
to go away. I cannot tell you for how long it will be supported, I don't
think anyone can, but for the near future, you should have no problems
getting support for VB6 directly from Microsoft or in the Newsgroups.
Now, to address why we made such radical changes with VB.Net - you, our
customers, asked us for these changes repeatedly. For many revs, people
asked us for true OOP functionality, along with too many other features and
functionality to list here. Now it's here, and it leaves programmers a
choice of tools, which should be nothing new. My best advice is to use the
tool which fits the job, be it VB6 or VB.Net.
Regards,
Ed Hickey
VB Forum Manager
This posting is provided “AS IS” with no warranties, and confers no rights.
You assume all risk for your use. © 2001 Microsoft Corporation. All rights
reserved.
Bob Butler
"Ed Hickey" <edhicke...@microsoft.com> wrote in message
news:PpBz52i...@cppssbbsa01.microsoft.com...
> Hello,
>
> I wish I could tell you exactly what will become of VB6, but as I cannot
> see the future, I'm not really sure myself. Suffice it to say that VB6
> will be around for quite some time. If you are currently developing in
> VB4-16 bit, and you call for support, we will support you, and that
product
> is 5 years old now. VB6 will be supported in the future, it is not going
> to go away. I cannot tell you for how long it will be supported, I don't
> think anyone can, but for the near future, you should have no problems
> getting support for VB6 directly from Microsoft or in the Newsgroups.
Define "supported". VB4-16 is not getting any more service packs or
releases so there are no more bug fixes or enhancements. If VB6 falls to
that same level, where "support" just means that MS will admit it knows
about the product then that's not "support" by my definition.
> Now, to address why we made such radical changes with VB.Net - you, our
> customers, asked us for these changes repeatedly. For many revs, people
> asked us for true OOP functionality, along with too many other features
and
> functionality to list here. Now it's here, and it leaves programmers a
> choice of tools, which should be nothing new. My best advice is to use
the
> tool which fits the job, be it VB6 or VB.Net.
That's just totally bogus. Where's the ability to static-link into a single
EXE? That has to be one of the most asked-for things in VB for years now
but it's certainly not in VB.Net. MS designed a new OO platform, then
slapped a VB-like syntax on top of it and claims it's what people asked for.
Picking out some things that some VB developers wanted and pointing out that
they are provided in VB.Net is just marketing bullshit. The radical changes
were not all required by the platform, nor were they all what people asked
for. I never saw any request to eliminate "Gosub/Return" or to change
Integer to 32 bits or to change "End While" to "Wend"... and none of those
were required to make a fully dotnet compliant version of VB. The list goes
on and on.
Joe "Nuke Me Xemu" Foster
> I wish I could tell you exactly what will become of VB6, but as I cannot
> see the future, I'm not really sure myself. Suffice it to say that VB6
> will be around for quite some time. If you are currently developing in
> VB4-16 bit, and you call for support, we will support you, and that product
> is 5 years old now. VB6 will be supported in the future, it is not going
> to go away. I cannot tell you for how long it will be supported, I don't
> think anyone can, but for the near future, you should have no problems
> getting support for VB6 directly from Microsoft or in the Newsgroups.
Yeah, like VB 4.0 SP 1, right? Yes, I remember that fiasco, since I've
been cutting back on how much Redmond Gold I've been smoking...
> Now, to address why we made such radical changes with VB.Net - you, our
> customers, asked us for these changes repeatedly. For many revs, people
> asked us for true OOP functionality, along with too many other features and
> functionality to list here. Now it's here, and it leaves programmers a
> choice of tools, which should be nothing new. My best advice is to use the
> tool which fits the job, be it VB6 or VB.Net.
YM, "Bill 'Go ahead, break my code' Storage has asked us for these changes
repeatedly." The rest of us ask for "Inherits" to complement "Implements"
and you give us this bucket of raw sewage!? Tell us again how we, your
customers, asked you for C-ish arrays, *only* C-ish arrays, repeatedly.
Tell us all exactly how we demanded that resource management be sacrificed
on the altar of free-threading. Remind us of how we begged and begged for
Borland Basic Builder, but without that awful Deterministic Finalization!
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
Ed Hickey
certainly not a marketing guy, and please don't ever call me that again!
;-)
Honestly, I have seen the requests for features, etc., and #1 has always
been Inheritance and "true" OOP support. #2 was to get rid of DLL Hell,
and although there will be some disagreement, I believe we have taken great
steps to get rid of that.
As to "support" - having engineers manning the phones and responding to
posts is what I term "support". We will be releasing further Service Packs
on VB6, I can tell you that. Bug fixes are always considered, some of them
would just require too much regression testing, etc., and will often pass
the point of diminishing return - if there's a passable workaround, that
will be used instead. That's simple economics. You can, and will, believe
what you will, but to me VB.Net is such a great improvement over VB6 that I
hate to go back to VB6. Having said that, I personally hated VB.Net at
first as well - I went from a good VB6 programmer to a really bad .Net
programmer - but once I got my feet under me, I much prefer .Net.
I welcome your replies...
Bob Butler
> Well Bob, I just spent the last 4 years in VB Developer Support. I am
> certainly not a marketing guy, and please don't ever call me that again!
> ;-)
Sorry, I know what an insult that can be <g>.
> Honestly, I have seen the requests for features, etc., and #1 has always
> been Inheritance and "true" OOP support. #2 was to get rid of DLL Hell,
> and although there will be some disagreement, I believe we have taken
great
> steps to get rid of that.
No argument there on either count. While I'm still waiting to see how some
of the new deployment works in practice there are certainly more options for
dealing with "DLL hell" problems.
> As to "support" - having engineers manning the phones and responding to
> posts is what I term "support". We will be releasing further Service
Packs
> on VB6, I can tell you that. Bug fixes are always considered, some of
them
> would just require too much regression testing, etc., and will often pass
> the point of diminishing return - if there's a passable workaround, that
> will be used instead. That's simple economics. You can, and will,
believe
> what you will, but to me VB.Net is such a great improvement over VB6 that
I
> hate to go back to VB6. Having said that, I personally hated VB.Net at
> first as well - I went from a good VB6 programmer to a really bad .Net
> programmer - but once I got my feet under me, I much prefer .Net.
I fully understand that older version can't be supported forever -- I deal
with the same issues with my own stuff. I just don't tell my users that the
old version is supported but then say that the problem they are having is
fixed in the current rev so they have to update. At that point the old rev
is no longer supported in any practical sense. I don't expect MS to support
VB6 at that level forever but given the upgrade difficulties there really is
no reasonable upgrade path from VB6 to VB.Net except for the most trivial
applications. That makes it more important to support VB6, including bug
fixes and even enhancements for a longer time. <cynic>Not that I expect
that to happen, of course.</cynic>
> I welcome your replies...
You'll get them anyway <g>
I notice you did not reply to a number of other points in the earlier post.
Blanket claims that the radical changes from VB6 syntax were required to
provide what VB users have been asking for are simply unfounded (unless you
add "within the time frame allotted" or other such caveats). Too many of
the changes were neither required nor requested and too many requests were
not included to make that palatable. The best course of action I can see at
this point would be for MS to drop the name VB.Net and call it "Basic.Net"
or "B#" or anything else and to stop pretending that this is an upgrade to
VB. It isn't. It is a new language with a lot of things borrowed from VB
that is likely to feel familiar to current VB users.
There are certainly a lot of things that I like in the new language and a
great many things that it makes much easier to handle and I'm not arguing
that VB.Net doesn't have merits on its own. I just feel like MS is trying
to pull a fast one and I resent the entire way it has been marketed.
<sidenote>
The one thing I've been trying to quantify, without success so far, is why I
dislike working with VB.Net without regard to VB6 comparisons... for many
years now I've found VB6 to be a lot of fun and really enjoyed developing
applications in it. Now I do things in VB.Net and I find myself making
excuses to use other tools or work on other projects because coding in
VB.Net is simply a job and lacks any "fun" level. Getting things to run in
VB.Net is simply an onerous chore. Maybe I'm just still too aggravated that
I have to rewrite so many reams of code if I want to move to the language to
look at it totally objectively.
</sidenote>
Ed Hickey
we all say things we don't mean to sometimes! ;-)
I welcome the replies! Don't expect me to "hide" and just respond to
positive replies and things like that. I'm obviously very pro-.Net, but
that does not mean that I will not listen to dissenting viewpoints - I'm
not a politician, after all <g>...the whole idea about an "online
community" is that EVERYONE has a right to post and be heard, and anyone
here that tries to censor viewpoints will hear from me immediately. It's
not really a community if there's any sort of policing of views.
Now, as to the "radical rewrite" that is VB.Net. The old Ruby engine that
VB 6 and previous was built on is now over 10 years old. It was written
before 32 bit, before COM, before just about everything that we now take
for granted. There was originally no data access methods in VB as well, if
you will recall. The basic engine has been patched enough that it would be
almost impossible to support inheritance, etc., as it was. Like you, I'm
not really wild about having my library of code samples go down the pipes,
but I fully expect that in a few years, I will have a completely new and
better library of .Net stuff written up. And I certainly think this is a
much better idea (rewriting from the ground up) than making yet another
overhaul of an engine that was not originally designed to do what we are
now asking of it.
I know there has been a lot of discussion and alternative names propsed for
the new VB product, but it really still is VB. Believe me, I am fully
aware of the problems with upgrading, and I know that a lot of VB6 code
will not upgrade well. I have found that I am better off re-writing, as
the style of how I approach a task is so much different, and so much more
OOP than how I did things in VB6. I also realize that this is a
less-than-popular concept, and I will do my best to transmit the anger over
this to the product group, although I know they've already heard a lot of
it so far!
Keep up the discussion, don't pull any punches, but please be fair and
well-informed.
Bob Butler
<cut>
> Now, as to the "radical rewrite" that is VB.Net. The old Ruby engine that
> VB 6 and previous was built on is now over 10 years old. It was written
> before 32 bit, before COM, before just about everything that we now take
> for granted. There was originally no data access methods in VB as well,
if
> you will recall. The basic engine has been patched enough that it would
be
> almost impossible to support inheritance, etc., as it was.
Wasn't the VB4-32bit and/or VB5 release effectively a re-write? Except for
the unicode string issues that did an admirable job of maintaining
compatibility. Even if it wasn't, and this time a total rewrite was deemed
necessary, that still does not excuse the changes made to the VB language
syntax. VB as a language did not have to be changed because a new compiler
was written.
> Like you, I'm
> not really wild about having my library of code samples go down the pipes,
> but I fully expect that in a few years, I will have a completely new and
> better library of .Net stuff written up.
And what happens a year after that when VB.WhateverComesNext trashes your
code again and you have to start all over again? Sometimes a rewrite is
necessary -- when I decide my code is too outdated, not because MS has
decided that the language needs to be cleaned up. If I am going to rewrite,
what should I guess to be the expected life expectancy of the new language?
> And I certainly think this is a
> much better idea (rewriting from the ground up) than making yet another
> overhaul of an engine that was not originally designed to do what we are
> now asking of it.
Fine. But there's still no justification for many of the language changes.
> I know there has been a lot of discussion and alternative names propsed
for
> the new VB product, but it really still is VB.
In your opinion perhaps. IMO it is a new language with, at best, a strong
family relationship to VB. That may be seen as arguing semantics but I see
a deeper issue there -- since MS has aptly demonstrated little or no concern
for their client's investment in VB applications I'd like to see them be
honest about it and state up front that VB as it was is being declared
legacy and that a new, similar, language is being offered in its place.
> Believe me, I am fully
> aware of the problems with upgrading, and I know that a lot of VB6 code
> will not upgrade well.
or at all. Much has to be redone to allow for the DF/GC design pattern
changes and that I accept because the new platform requires that change.
That type of change can be back-ported to VB6 though since I don't *have* to
rely on DF there if I want to manually call Dispose methods. "Type" to
"Structure", "End While" to "Wend", loss of Gosub/Return, redefinition of
Integer/Long, and all of the other syntactical changes done to the language
are simply unjustified IMO since they serve only to make it more difficult
to keep a codebase in both VB6 and VB.Net or to upgrade cleanly.
> I have found that I am better off re-writing, as
> the style of how I approach a task is so much different, and so much more
> OOP than how I did things in VB6.
I totally agree that there are ways to design applications under VB.Net that
are superior to the best options available under VB6. The problem is that I
have working applications under VB6 that I have no need to rewrite except
that I can't integrate new features without adding the overhead of COM
interop unless I rewrite from scratch. That's a hell of an investment to
make just to get back to where I am now in order to move forward. I either
bite the bullet and suspend all new development while existing apps are
redesigned, rewritten and tested under VB.Net or I just use VB.Net for new
development and maintain existing apps in VB6 and maybe use interop for a
few new add-ons. Either option sucks IMO.
> I also realize that this is a
> less-than-popular concept, and I will do my best to transmit the anger
over
> this to the product group, although I know they've already heard a lot of
> it so far!
I'm sure they have. In my more cynical moments I'd say they deserve it. As
others have wondered, ask what they'd say if somebody decided to clean up
the C++ syntax, redefining keywords and dropping features.
> Keep up the discussion, don't pull any punches, but please be fair and
> well-informed.
I try. If I am incorrect about anything factual please correct me.
Joe "Nuke Me Xemu" Foster
> "Ed Hickey" <edhicke...@microsoft.com> wrote in message
> news:bf6YiXv...@cppssbbsa01.microsoft.com...
> > I also realize that this is a
> > less-than-popular concept, and I will do my best to transmit the anger
> over
> > this to the product group, although I know they've already heard a lot of
> > it so far!
>
> I'm sure they have. In my more cynical moments I'd say they deserve it. As
> others have wondered, ask what they'd say if somebody decided to clean up
> the C++ syntax, redefining keywords and dropping features.
>
> > Keep up the discussion, don't pull any punches, but please be fair and
> > well-informed.
>
> I try. If I am incorrect about anything factual please correct me.
The Microserfs been quite good about correcting factual inaccuracies,
whether drenched in bile and vitriol or not. Therefore, if a rant
goes unanswered, could the ranter possibly be correct?
--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
Quantum Red
>aware of the problems with upgrading, and I know that a lot of VB6 code
>will not upgrade well. I have found that I am better off re-writing, as
Any reasonably complex VB5 or 6 project needs to be rewritten, as you
mentioned above. The larger and more complex the project, the more
time and effort involved. Where do you make a distinction between
"upgrade" and "port to another language"?
I could also "upgrade" to C++ with "some" rewritting of my VB code.
Being forced to "rewrite" my code is not what I consider an "upgrade"
at all, but rather a port to another language.
I have a couple of massive projects in VB5 and 6 and have absolutely
no intention of "upgrading" to .net simply due to the complexity
(usercontrols, api calls, variants, the list goes on and on). These
projects are years in the making and would likely take a similar
amount of time to "port" to .net.
You can cast my vote on the side of those very disappointed with the
abandonment of VB. I also dislike the blanket justification that "I
asked for this". Those with the loudest voices are those with the most
discontent. However I'll bet that I am in the majority who are for the
most part quietly satisfied with VB as it is, and would only like to
see incremental improvements now and then.
Win'3000
users would think of VB.net or should it be called VB.sht!
Even the writer of a book on VB6 development has said that nothing in his
book is useful or applies to VB.net!
If programmers had wanted to use a C like language there would have been no
demand for VB past ver 1 or 2!
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:#bzKWjkOBHA.1788@tkmsftngp03...
Richard Childress
>
> > I wish I could tell you exactly what will become of VB6, but as I cannot
> > see the future, I'm not really sure myself. Suffice it to say that VB6
> > will be around for quite some time. If you are currently developing in
> > VB4-16 bit, and you call for support, we will support you, and that product
> > is 5 years old now. VB6 will be supported in the future, it is not going
> > to go away. I cannot tell you for how long it will be supported, I don't
> > think anyone can, but for the near future, you should have no problems
> > getting support for VB6 directly from Microsoft or in the Newsgroups.
>
> Yeah, like VB 4.0 SP 1, right? Yes, I remember that fiasco, since I've
> been cutting back on how much Redmond Gold I've been smoking...
>
> > Now, to address why we made such radical changes with VB.Net - you, our
> > customers, asked us for these changes repeatedly. For many revs, people
> > asked us for true OOP functionality, along with too many other features and
> > functionality to list here. Now it's here, and it leaves programmers a
> > choice of tools, which should be nothing new. My best advice is to use the
> > tool which fits the job, be it VB6 or VB.Net.
>
> YM, "Bill 'Go ahead, break my code' Storage has asked us for these changes
> repeatedly." The rest of us ask for "Inherits" to complement "Implements"
> and you give us this bucket of raw sewage!? Tell us again how we, your
> customers, asked you for C-ish arrays, *only* C-ish arrays, repeatedly.
> Tell us all exactly how we demanded that resource management be sacrificed
> on the altar of free-threading. Remind us of how we begged and begged for
> Borland Basic Builder, but without that awful Deterministic Finalization!
Q: How can you implement true implementation inheritance in a language
whose classes are based on COM?
A: You can't.
VB's classes are based on COM. That's what makes it so easy to create
COM components with VB.
Joe "Nuke Me Xemu" Foster
> "Joe \"Nuke Me Xemu\" Foster" <j...@bftsi0.UUCP> wrote in message news:<#bzKWjkOBHA.1788@tkmsftngp03>...
> > YM, "Bill 'Go ahead, break my code' Storage has asked us for these changes
> > repeatedly." The rest of us ask for "Inherits" to complement "Implements"
> > and you give us this bucket of raw sewage!? Tell us again how we, your
> > customers, asked you for C-ish arrays, *only* C-ish arrays, repeatedly.
> > Tell us all exactly how we demanded that resource management be sacrificed
> > on the altar of free-threading. Remind us of how we begged and begged for
> > Borland Basic Builder, but without that awful Deterministic Finalization!
>
> Q: How can you implement true implementation inheritance in a language
> whose classes are based on COM?
>
> A: You can't.
>
> VB's classes are based on COM. That's what makes it so easy to create
> COM components with VB.
BZZT! That's crap, and you know it. Implementation inheritance no more
requires native support from COM than it does from the CPU. Sheridan's
now-abandoned ClassAssist add-in gave us implementation inheritance in
VB 4.0! No, all implementation inheritance in VB would require is the
ability to inspect arbitrary base class' interfaces, Implement them all,
and copy their vtables to avoid having to provide wrappers for methods
and properties not being overridden. An add-in can almost do all this
without requiring native support from VB, but some performance tricks
would be all but unavailable without some very scary hacking. McKinney's
_Hardcore VB_ touches on how to do this in its sections about writing
Collection classes:
http://www.mvps.org/vb/hardcore/html/stupidcodetricks.htm
(deep-link within http://www.mvps.org/vb/hardcore/ , itself a deep-link
within http://www.mvps.org/vb/ )
--
Joe Foster <mailto:jfo...@ricochet.net> Sacrament R2-45 <http://www.xenu.net/>
Richard Childress
> requires native support from COM than it does from the CPU. Sheridan's
> now-abandoned ClassAssist add-in gave us implementation inheritance in
> VB 4.0! No, all implementation inheritance in VB would require is the
> ability to inspect arbitrary base class' interfaces, Implement them all,
> and copy their vtables to avoid having to provide wrappers for methods
> and properties not being overridden. An add-in can almost do all this
> without requiring native support from VB, but some performance tricks
> would be all but unavailable without some very scary hacking. McKinney's
> _Hardcore VB_ touches on how to do this in its sections about writing
> Collection classes:
What you are descibing is not true implementation inheritance. What
you are describing would be a way to achieve implementation
inheritance at design-time, but anything after that would require a
recompile.
Example:
Let's say I have Class1 which implements some functionality
(MethodA){Class1.MethodA (Not Overridable)). Now we create Class2
which would inherit from Class1. {Class2.MethodA, Class2MethodB}.
Yes, you can create an add-in to copy the code from Class1 to Class2
at design-time. Now let's assume these classes exist in different
DLLs. You're still OK as long as you have control over the DLLs. But
what if the DLL that contains Class1 comes from a third-party and you
don't have access to the source. BZZT! ( sorry ;) ) You're out of
luck. What if, after you deploy Class1 and Class2, you change the
implementation of Class1.MethodA? Class1.MethodA and Class2.MethodA
are now different. You have to copy the source-code from Class1 to
Class2, recompile Class2 and redistribute. If you have a large (~
6700 classes last I heard) object class framework (.NET framwework)
built from the ground up using inheritance (everything inherits from
Object), that's a lot of copy-and-pasting, mon ami.
COM does not support true implementation inheritance. VB's classes
are COM-based. VB does not support true implementation inheritance.
Sure, you can copy-and-paste code around to get the effect, but there
are holes.
Joe "Nuke Me Xemu" Foster
> > BZZT! That's crap, and you know it. Implementation inheritance no more
> > requires native support from COM than it does from the CPU. Sheridan's
> > now-abandoned ClassAssist add-in gave us implementation inheritance in
> > VB 4.0! No, all implementation inheritance in VB would require is the
> > ability to inspect arbitrary base class' interfaces, Implement them all,
> > and copy their vtables to avoid having to provide wrappers for methods
> > and properties not being overridden. An add-in can almost do all this
> > without requiring native support from VB, but some performance tricks
> > would be all but unavailable without some very scary hacking. McKinney's
> > _Hardcore VB_ touches on how to do this in its sections about writing
> > Collection classes:
>
> What you are descibing is not true implementation inheritance. What
> you are describing would be a way to achieve implementation
> inheritance at design-time, but anything after that would require a
> recompile.
What do you think happens in C++ whenever you modify a base class'
header, even if the size and public/protected interface change not
at all?
> Example:
>
> Let's say I have Class1 which implements some functionality
> (MethodA){Class1.MethodA (Not Overridable)). Now we create Class2
> which would inherit from Class1. {Class2.MethodA, Class2MethodB}.
> Yes, you can create an add-in to copy the code from Class1 to Class2
> at design-time. Now let's assume these classes exist in different
> DLLs. You're still OK as long as you have control over the DLLs. But
> what if the DLL that contains Class1 comes from a third-party and you
> don't have access to the source. BZZT! ( sorry ;) ) You're out of
> luck. What if, after you deploy Class1 and Class2, you change the
> implementation of Class1.MethodA? Class1.MethodA and Class2.MethodA
> are now different. You have to copy the source-code from Class1 to
> Class2, recompile Class2 and redistribute. If you have a large (~
> 6700 classes last I heard) object class framework (.NET framwework)
> built from the ground up using inheritance (everything inherits from
> Object), that's a lot of copy-and-pasting, mon ami.
BZZT! Copying the vtables is copying tables of pointers to methods,
not source or object code. Access to the base classes' source code
would be completely irrelevant. The base classes could even be remoted!
The copy-and-paste job done by ClassAssist was done for performance
reasons, but it could have just as easily used delegation instead and
still hid the nasty details from the developer.
> COM does not support true implementation inheritance. VB's classes
> are COM-based. VB does not support true implementation inheritance.
> Sure, you can copy-and-paste code around to get the effect, but there
> are holes.
What I described would be indistinguishable from "true" inheritance to
a developer. Just what do you think happens "under the covers" in a
language supporting "true inheritance"? Take a look at "cfront", the
old C++-to-C preprocessor.
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
Richard Childress
> What do you think happens in C++ whenever you modify a base class'
> header, even if the size and public/protected interface change not
> at all?
.
.
> BZZT! Copying the vtables is copying tables of pointers to methods,
> not source or object code. Access to the base classes' source code
> would be completely irrelevant. The base classes could even be remoted!
> The copy-and-paste job done by ClassAssist was done for performance
> reasons, but it could have just as easily used delegation instead and
> still hid the nasty details from the developer.
.
.
> What I described would be indistinguishable from "true" inheritance to
> a developer. Just what do you think happens "under the covers" in a
> language supporting "true inheritance"? Take a look at "cfront", the
> old C++-to-C preprocessor.
OK, I see what you're saying. They could have implemented inheritance
(a kind of bastardized way of doing it though), and they could have
made it invisible to you. Point, Red.
I'm not trying to bait and switch, but don't you think leaving COM
behind is a GOOD thing?
Joe "Nuke Me Xemu" Foster
"Richard Childress" <richardj...@eaton.com> wrote in message <news:d485806.01092...@posting.google.com>...
> "Joe \"Nuke Me Xemu\" Foster" <j...@bftsi0.UUCP> wrote in message news:<uNFToKXRBHA.1644@tkmsftngp05>...
> > What I described would be indistinguishable from "true" inheritance to
> > a developer. Just what do you think happens "under the covers" in a
> > language supporting "true inheritance"? Take a look at "cfront", the
> > old C++-to-C preprocessor.
>
> OK, I see what you're saying. They could have implemented inheritance
> (a kind of bastardized way of doing it though), and they could have
> made it invisible to you. Point, Red.
Again, just WTF do you think is happening under the covers in .NET?
> I'm not trying to bait and switch, but don't you think leaving COM
> behind is a GOOD thing?
No, I most certainly do not. Deterministic finalization is still
where I want to go today! Even the C++ crowd has been taking a shine
to reference counting in the past year or so, thanks to templates
which make using it much easier. What, is only one major language at
a time allowed to use refcounting, lest the Earth explode or something?
--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
Richard Childress
> > behind is a GOOD thing?
>
> No, I most certainly do not. Deterministic finalization is still
> where I want to go today! Even the C++ crowd has been taking a shine
> to reference counting in the past year or so, thanks to templates
> which make using it much easier. What, is only one major language at
> a time allowed to use refcounting, lest the Earth explode or something?
Why are you so hung up on DF? I think the benefits of GC and memory
management along with the Dispose design pattern are much more valuable to
developers. With DF, you can have those painful circular reference
problems.
Joe "Nuke Me Xemu" Foster
DF makes a number of my classes much easier for others to use within
my organization, especially for non-"programmers" who can do a little
VBA macro coding. If they want to memorize when to Dispose or delete
an object, let them use Java or C++. No, I've never been bitten by
the circular references problem. "Mediator classes", anyone?
VB Classic pseudocode:
class sharedstuff
' little more than a glorified Type, really
public x as integer, y as integer, z as integer
end class
class containee
private me_ss as sharedstuff
public sub init (stuff as sharedstuff)
set me_ss = stuff
end sub
public sub blah ()
msgbox me_ss.x + me_ss.y + me_ss.z
end sub
end class
class container
private me_ss as sharedstuff
private me_list(1 to 10) as containee
private sub class_initialize()
set me_ss = new sharedstuff
dim i as integer: for i = lbound(me_list) to ubound(me_list)
set me_list(i) = new containee
me_list(i).init me_ss
next
end sub
end class
Now, each containee can get at the shared x, y, and z variables, with
no worries about circular references. If they need more, we can hang
an event or two off the sharedstuff class. Gee, I wonder how we ever
survived *three* versions of VB with this impossible, unsurmountable
circular references problem!
And what, may I ask, prevents you from using the "dispose pattern" in
VB Classic, if that's really what you want?
Richard Childress
Absolutely nothing prevents one from using the Dispose
pattern in VB4-6.
Do you encourage your developers to set their objects to
nothing when they're done with them? It's the same thing
as calling Dispose.
The point I was trying to make was, that to me,
implementing the Dispose pattern is a small price to pay
for the benefits of CLR managed memory. Most memory leaks
will go away (You'll have to get creative). OK, so now
instead of saying 'set objMyObject = Nothing' I
say 'objMyObject.Dispose'. Big Deal.
They actually tried to implement refernce counting but
couldn't make it work very well with the other things they
were trying to do such as garbage collection.
Bob Butler
"Richard Childress" <RichardJ...@eaton.com> wrote in message
news:466701c14819$0bd86d80$19ef2ecf@tkmsftngxa01...
<cut>
> Absolutely nothing prevents one from using the Dispose
> pattern in VB4-6.
True
> Do you encourage your developers to set their objects to
> nothing when they're done with them? It's the same thing
> as calling Dispose.
Not if you have multiple references to an object. In that case you might be
explicitly setting references to Nothing in many places that you do not want
to call Dispose.
> The point I was trying to make was, that to me,
> implementing the Dispose pattern is a small price to pay
> for the benefits of CLR managed memory. Most memory leaks
> will go away (You'll have to get creative). OK, so now
> instead of saying 'set objMyObject = Nothing' I
> say 'objMyObject.Dispose'. Big Deal.
In VB6 and earlier if you were careful not to leave references hanging
around then when the last one was released the finalizer ran automatically.
With VB.Net you now have to be certain to explicitly call Dispose at the
point of last release whenever some resource needs to be freed quickly. For
objects that can be left for the GC the VB.Net pattern is less work than
before but for objects that need to be disposed quickly it's more critical
that you pay close attention to the code. It also means that if you have an
object to which you need to add something that moves it from the "it can
wait for GC" to "it needs to be disposed" category you either need to revise
any/all client code or you need to make it a new object or interface.
The more I look at it, the DF->GC change resulted in less complexity in some
areas and more in others and is largely a wash in my opinion. I'm still
waiting to see how bad memory usage is on large projects.
Richard Childress
True, but you only have a few cases of object use.
If the object is local to a routine, there is no
difference between setting the object to 'nothing' and
calling Dispose().
OK, now let's say our object (CConnectionSource) (which
maybe represents a connection) is a member of a class
(CParent) and several children objects
(CConnectionConsumer) obtain references to the
CConectionSource object. Our CParent object just hands
the CConnectionSource object off to the
CConnectionConsumer objects to do some work. The CParent
object maintains a reference to the CConnectionSource
object therefore even if all the CConnectionConsumer
objects AddRef and Release, one reference still exists.
The CConnectionSource object would not get Released until
the CParent object releases it (via set object = nothing
or object.Dispose())
What other example of object use can you have that this
doesn't hold true?
Bob Butler
<cut>
> If the object is local to a routine, there is no
> difference between setting the object to 'nothing' and
> calling Dispose().
Agreed.
> OK, now let's say our object (CConnectionSource) (which
> maybe represents a connection) is a member of a class
> (CParent) and several children objects
> (CConnectionConsumer) obtain references to the
> CConectionSource object. Our CParent object just hands
> the CConnectionSource object off to the
> CConnectionConsumer objects to do some work. The CParent
> object maintains a reference to the CConnectionSource
> object therefore even if all the CConnectionConsumer
> objects AddRef and Release, one reference still exists.
> The CConnectionSource object would not get Released until
> the CParent object releases it (via set object = nothing
> or object.Dispose())
CConnectionSource would not get released until CParent releases it AND all
CConnectionConsumer objects release it. In the VB6 case it is easy since I
just have to ensure that the parent and consumer classes release the
reference when they are done. I do not normally care who is last to release
it since COM will track it for me and "dispose" of it when appropriate and
if some consumer class hangs around for a while then the connection will
remain valid.
Under VB.Net I can't call Dispose until I am sure that all
CConnectionConsumer classes are done with it which means I might need to add
my own ref counting or implement some other scheme to ensure that the
connection is not destroyed while it is still needed.
Richard Childress
releases it AND all
>CConnectionConsumer objects release it. In the VB6 case
it is easy since I
>just have to ensure that the parent and consumer classes
release the
>reference when they are done. I do not normally care who
is last to release
>it since COM will track it for me and "dispose" of it
when appropriate and
>if some consumer class hangs around for a while then the
connection will
>remain valid.
True
>Under VB.Net I can't call Dispose until I am sure that all
>CConnectionConsumer classes are done with it which means
I might need to add
>my own ref counting or implement some other scheme to
ensure that the
>connection is not destroyed while it is still needed.
Unless CParent hands off the references to the
CConsumerObjects and then immediately releases it's own
reference, it's the same thing. You would have to do
something like this:
' CParent
Private Sub Class_Initialize()
' initialize member CConnectionSource object
' initialize CConnectionConsumer1 object
' handoff connection to CConnectionConsumer1 object
...
' initialize CConnectionConsumern object
' handoff connection to CConnectionConsumern object
' Release CConnectionSource reference
End Sub
Then, yes, DF is what you want.
But unless CParent releases it's own reference
immediately, then CConnectionSource needs to be around for
future requests, possibly future instantiations of other
objects. You can't let it go until you know you don't
need it anymore. Then the last release becomes important.
Bob Butler
<cut>
> Unless CParent hands off the references to the
> CConsumerObjects and then immediately releases it's own
> reference, it's the same thing.
yes, in the case where references are isolated then there is no issue.
<cut>
>
> Then, yes, DF is what you want.
It's what I had <g>
> But unless CParent releases it's own reference
> immediately, then CConnectionSource needs to be around for
> future requests, possibly future instantiations of other
> objects. You can't let it go until you know you don't
> need it anymore. Then the last release becomes important.
Exactly. It sounds like we essentially agree and just may have different
priorities and favorite design patterns. My only point is that you can't
just always replace VB6-style "Set o=Nothing" statetements (or the
equivalent let-it-fall-out-of-scope) with calls to Dispose under VB.Net
because they aren't equivalent in all cases.
Richard Childress
Oh, no question.
Joe "Nuke Me Xemu" Foster
> CConnectionSource would not get released until CParent releases it AND all
> CConnectionConsumer objects release it. In the VB6 case it is easy since I
> just have to ensure that the parent and consumer classes release the
> reference when they are done. I do not normally care who is last to release
> it since COM will track it for me and "dispose" of it when appropriate and
> if some consumer class hangs around for a while then the connection will
> remain valid.
>
> Under VB.Net I can't call Dispose until I am sure that all
> CConnectionConsumer classes are done with it which means I might need to add
> my own ref counting or implement some other scheme to ensure that the
> connection is not destroyed while it is still needed.
Looks like you'll get a taste of the AddRef stuff the MSVC+/ATL folks
have to swallow each and every day, and just when the C++ journals have
been touting reference counting using "smart" pointer templates, too!
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
Joe "Nuke Me Xemu" Foster
> Do you encourage your developers to set their objects to
> nothing when they're done with them? It's the same thing
> as calling Dispose.
Not if there's more than one reference pointing to it.
> The point I was trying to make was, that to me,
> implementing the Dispose pattern is a small price to pay
> for the benefits of CLR managed memory. Most memory leaks
> will go away (You'll have to get creative). OK, so now
> instead of saying 'set objMyObject = Nothing' I
> say 'objMyObject.Dispose'. Big Deal.
Definitely a big deal, if there's more than one reference
variable pointing to it!
> They actually tried to implement refernce counting but
> couldn't make it work very well with the other things they
> were trying to do such as garbage collection.
What, did Brian Harry "forget" that INC and DEC are atomic?
Couldn't they figure out when a reference variable might be
accessible to more than one thread and thus require a nice
sync or reader/writer lock?
Richard Childress
> > nothing when they're done with them? It's the same thing
> > as calling Dispose.
>
> Not if there's more than one reference pointing to it.
>
> > The point I was trying to make was, that to me,
> > implementing the Dispose pattern is a small price to pay
> > for the benefits of CLR managed memory. Most memory leaks
> > will go away (You'll have to get creative). OK, so now
> > instead of saying 'set objMyObject = Nothing' I
> > say 'objMyObject.Dispose'. Big Deal.
>
> Definitely a big deal, if there's more than one reference
> variable pointing to it!
>
> > They actually tried to implement refernce counting but
> > couldn't make it work very well with the other things they
> > were trying to do such as garbage collection.
>
> What, did Brian Harry "forget" that INC and DEC are atomic?
> Couldn't they figure out when a reference variable might be
> accessible to more than one thread and thus require a nice
> sync or reader/writer lock?
I see your point.
In those cases (where you don't have a definite handle on the lifetime of an
object), regretably, you'd have to live with a finalizer, which may or may
not be called. Point, Red.
Do you know how Java handles this? I would imagine the same problem exists,
right?
Joe "Nuke Me Xemu" Foster
> > What, did Brian Harry "forget" that INC and DEC are atomic?
> > Couldn't they figure out when a reference variable might be
> > accessible to more than one thread and thus require a nice
> > sync or reader/writer lock?
>
> I see your point.
>
> In those cases (where you don't have a definite handle on the lifetime of an
> object), regretably, you'd have to live with a finalizer, which may or may
> not be called. Point, Red.
>
> Do you know how Java handles this? I would imagine the same problem exists,
> right?
I have no idea! I imagine if they had a solution, Microsoft would have
ripped that off too, along with just about everything else, for Java.NET,
oops, I meant "C#". However, that can't have been the case, since most
Cheerleaders.NET claim all resource-management classes should always have
been Pure Stateless, just like the file I/O classes, right...?
--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
Richard Childress
same problem exists,
>> right?
>I have no idea! I imagine if they had a solution,
Microsoft would have
>ripped that off too, along with just about everything
else, for Java.NET, oops, I meant "C#".
Everybody rips everybody off in this industry (some,
admittedly, more than others)
>However, that can't have been the case, since most
>Cheerleaders.NET claim all resource-management classes
should always have
>been Pure Stateless, just like the file I/O classes,
right...?
The only time stateless makes sense is on the application
server, and even then stateless between calls. That's my
opinion.
Joe "Nuke Me Xemu" Foster
> >However, that can't have been the case, since most
> >Cheerleaders.NET claim all resource-management classes
> should always have
> >been Pure Stateless, just like the file I/O classes,
> right...?
>
> The only time stateless makes sense is on the application
> server, and even then stateless between calls. That's my
> opinion.
HERESY! APOSTASY! HETERODOXY! Repent now, before it's too late!
http://www.devx.com/free/press/2000/102500.asp
http://www.devx.com/upload/free/features/vbpj/2001/01feb02/jf0102/sidebar4.asp
Why is Brian Harry [MSFT] lying about the cost of reference counting?
InterlockedIncrement is just i80x86 INC, and the InterlockedDecrement
and test boil down to just DEC and testing the "zero flag"!
http://mvps.org/vbnet/dev/vb7/vbdotnet_ms_resmanagement.htm
http://sources.redhat.com/ml/libc-hacker/2000-01/msg00000.html
--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
Richard Childress
reference counting?
>InterlockedIncrement is just i80x86 INC, and the
InterlockedDecrement
>and test boil down to just DEC and testing the "zero
flag"!
http://mvps.org/vbnet/dev/vb7/vbdotnet_ms_resmanagement.htm
>
> http://sources.redhat.com/ml/libc-hacker/2000-
01/msg00000.html
Inserted from the above link...
>/* According to the Intel documentation the following
>operations are
> atomic on the Intel Architecture processors:
>
> - Reading or writing a byte.
> - Reading or writing a word aligned on a 16-bit
>boundary.
> - Reading or writing a doubleword aligned on a 32-bit
>boundary.
>
> The compiler takes care of proper alignment so we
>don't have to
> worry about unaligned access.
>
> Bus-locking may be necessary for certain operations to
>be atomic on
> multiprocessor machines. According to the Intel
>documentation this
> is necessary for the following operations:
>
> - The bit test and modify instructions (BTS, BTR and
>BTC).
> - The exchange instructions (XADD, CMPXCHG, CMPXCHG8B).
> - The following single-operand arithmetic and logical
>instructions:
> INC, DEC, NOT, and NEG.
> - The following two-operand arithmetic and logical
>instructions:
> ADD, ADC, SUB, SBB, AND, OR, and XOR.
>
> The XCHG instruction is automatically locked. */
Forgive me if I'm wrong, but doesn't this say that it's
NOT a simple INC/DEC?
Joe "Nuke Me Xemu" Foster
> > http://mvps.org/vbnet/dev/vb7/vbdotnet_ms_resmanagement.htm
> > http://sources.redhat.com/ml/libc-hacker/2000-01/msg00000.html
I interpret it as meaning that each opcode in the above list is atomic,
even in the case of dual- or multi-processor machines. However, using
the above opcodes involves a small performance penalty in the case of
multi-processor machines. Doubtlessly, the Crusaders.NET will hype the
need for bus locking when attempting to implement reference counting,
"forgetting" to mention that the same performance penalty is paid for
nearly all operations on integer types!
Now, my assembly language might be rather rusty, but most of the above
instructions, including DEC, should set the "zero flag" in a special
register if the value being decremented hits zero. This is perfect for
implementing reference counting! Next, we need an equally fast and
easy way to sync-lock the reference variable, which Brian Harry [MSFT]
also conveniently "forgot".
' assign public reference b to public reference a, pseudocode
ref counting:
const locked = &hDEADBEEF& ' arbitrary magic value meaning "sync-locked"
' get exclusive use of reference variable a
tempa = locked ' tempa is a scratch variable exclusive to this thread
do
ATOMIC_SWAP a, tempa
if not tempa is locked then exit do
if CPUs.Count < 2 then yield
loop
' get exclusive use of reference variable b
tempb = locked ' also exclusive to this thread
do
ATOMIC_SWAP b, tempb
if not tempb is locked then exit do
if CPUs.Count < 2 then yield
loop
' acquire reference to object b
if not tempb is nothing then
INC tempb.m_ref
end if
' release reference to object a
if not tempa is nothing then
DEC tempa.m_ref
if ZERO_FLAG then tempa.FinalRelease
end if
a = tempb
ATOMIC_SWAP b, tempb
I expect the ZERO_FLAG test and ATOMIC_SWAP calls to be single assembly
language instructions. Of course, a and b might not even be accessible
to other threads:
' assign local reference b to local reference a, pseudocode
ref counting:
if not b is nothing then
INC b.m_ref
end if
if not a is nothing then
DEC a.m_ref
if ZERO_FLAG then a.FinalRelease
end if
a = b
Using those "interlocked increment" and "interlocked decrement" *opcodes*
instead of Brian Harry's specious canards, "the execution performance is
obscenely higher", all right!
Michael D. Long
get those nasty 0xC0000005 faults that come as a side
effect of non-DF. I just saw a repro of one in another
newsgroup, and the Microsoft guy reported the fault to
lie with the URT (after reproducing on his machine).
With DF you can avoid many of the problems that can
due to race conditions associated with clean-up processing
in a run-time (such as the CLR).
Michael D. Long
"Richard Childress" <r.childre...@verizon.net> wrote in message
news:em655IjRBHA.1604@tkmsftngp03...