Re: Access .NET classes from VB 5/6?

***,

While OO is great for lots of
things, it is most decidedly UNusable for some applications and is most
decidedly UNusable in some places in MOST complex applications,
ESPECIALLY in simulators and state machine logic.

I do state machines in .NET often. I find them no harder than VB6.

I suspect that one of us knows something that the other doesn't, but I'm not sure who is ahead. Hence, I'll start out by saying some things for you to pick holes in.

State machine programming is usually characterized by a state number of some sort that maps to a place in the code. You affect the outside world in some way, change your state to redirect control in your code, and wait for control to pop back when the outside world responds in some way.

Before .NET, you could just funnel all events that might affect your state to a gigantic On state GoTo places in your program. Now, the only way to have a many-way branch is with a gigantic Select Case statement which I presume you are using.

The BIG unanswered question in my mind is whether they have "done their homework" to build branch tables where the cases are consecutive, or whether this compiles into a long pile of IF statements so that a branch near the end can take a LONG time when there are dozens/hundreds of states. If they have done this homework, than while it would remain ugly at least it wouldn't be much slower than the On GoTo approach.

I'm not sure about "emulators" though. I'd have to have a notion about what you might be emulating (VT100?).

A horror that might have escaped your notice are the RFCs the describe the Internet's operation. Anytime you build something to interface to the Internet, it must typically conform to DOZENS of these RFCs. Unfortunately, these were generally NOT written by competent programmers, so there is some of the worst ILlogical operation you could imagine. For example, users with slow connections take almost forever to download large numbers of newsgroup postings, because there is no overlap between Input and Output. No, there is no logical reason for this situation, just stupidity in the RFCs.

However, you are right. GoTo and GoSub must be done by some other approach. Since I haven't used either of these since I started programming in VB (1992), I have a hard time missing them.

I sure don't use them very often, maybe on average just one place per major project. However, when you need them, you REALLY NEED them as the cost of their absence can be rather high, like the entire project runs a a fraction of the speed that it should run.

The simple GoSub isn't so valuable, because in most cases you could just move your local variables to become module variables and call the procedure rather than GoSub'ing to it. Of course, this approach does NOT work in recursive code, but I don't do much of that.

However, the ON ... statement is another matter. I often implement compile now and interpret later logic to resolve complex user demands into simpler procedures to be performed later. This is hard/impossible to do efficiently without ON statements.

Thanks for the discussion.

Steve Richfie1d


.

Loading