Re: Move from VB 6 to VB.Net in 5 easy steps

[Jon Ogden]

"Jay Glynn" <jay_glynn@agla.com> wrote in message
news:3a6ba6a0@news.devx.com...
> Jon,
>
>
> > Many of the changes seem to be designed simply to break compatibility.
> They
> > do not make VB.NET any more OO, they simply make it look 'cool.'
> >
>
> They make it more compatible with the other languages that will be
supported
> on .NET.

I wonder how compatible it will be with VB.Python...but even granting your
premise, you are not disagreeing with me; just rephrasing in different
terms.

> > I have never have quarreled with the elegance of Fred.NET. And it
> certainly
> > can be considered a variant of the BASIC family. But by your own
> testimony,
> > it's not VB.
>
> It's not VB7. It's not a load and recompile migration from VB6, but I
think
> that you can still call it VB.

Then it should be called PDS 14. It has little if anything more in common
with VB6 than VB1 had with QBX. Why keep the name the same this time?

> > Why is it, I wonder, that anyone who likes VB.NET starts off by assuming
> > that anyone who doesn't is an ignoramus? I'm reading your opinions
pretty
> > carefully and with an open mind. You seem to want to discount mine in
> > advance by assigning me a history that makes you feel superior.
>
> Never meant to imply anything like that. Simply if all you know is VB,
then
> the changes make less sense then if you have done a fair amnount of C /C++
> programming or perhaps Java programming.

"Make sense?" If you mean recognisable, then I agree with you. If you mean
more likely to be deemed "A Good Thing," I have doubts. If you mean that
someone who has programmed primarily in other languages will feel more
comfortable with Fred, then, again, I agree.

>Then the changes would ring a
> familiar bell. I am not trying to infer that this has a direct
relationship
> to your intellect, or to your development skills. Apologies if it came
> across that way.

Accepted with thanks.
> > >The boolean -1
> > > to not 0, the 0 based arrays etc are being handled the way that most
> > > languages currently handle them.
> >
> > Most languages are different from each other. MSFT recognized this re:
C++
> > and VFP. Only VB was changed to be a semi-clone of C#.
>
> VB was the only on that did them differently.
>

The three languages (VB; C++; VFP) all do many things differently than each
other and C++ and VFP have not been coerced into doing them the same way as
C#.

> >My concern these
> > past weeks has been to determine whether or not dealing with VB.NET is a
> > waste of time. Nothing you have said in your post suggests that VB.NET
> > offers any greater ROI than C# and, since the success of dotnet is still
> > problematical and its adoption as a desktop standard even more so,
> switching
> > to Java, or Kylix must be looked at as a viable alternative. Especially
> > since the suits will consider dotnet to be experimental and unproven.
(And
> > rightfully so, it is.)
> >
>
> As far as overall adoption, yes we are all waiting to see what happens.

More importantly, so are our bosses <grin>.

> However as far as ROI goes, I think that VB.NET will allow a current Vb
> developer to be much more productive then if they were to have to learn
C#.
> There is still a great deal of syntax that is still VB, and there is
> VisualBasic.dll that will make the learning process much easier.

You may be right. Or that may lull folks into a false sense of security.

> > >The there is the argument about it not
> > > being as easy to learn. In my mind this is a good thing.
> >
> > Okay, in your mind it is. In other peoples minds it isn't. If some
people
> > think VB's more accessible than other languages, then what skin is it
off
> of
> > your nose? It probably creates extra income for you when you are asked
to
> > bail them out. At any rate it's an opinion and not a matter of fact.
> >
>
> No, unfortunately it isn't extra income, it's just extra time that I don't
> have. I work in Corporate America., my paycheck is the same each week
> regardless.

Yeah, me, too. Difference is I like working with the newbies. They're like
puppies - not fully toilet trained, but cute and eager. And my bosses let
me track mentoring time as a separate project that is on-going.

> > Your point has nothing to do with the language, but seems to suggest
> you'll
> > feel better if you can say that you know a lnaguage thats not easy to
> learn.
> > So what's stopping you?
> >
>
> It has everything to do with the language, or at least in the MSFT
marketing
> of the language. Everyone knows that VB is easy to learn and to use, or
> that's what we all have been told. The guy in marketing thinks that means
he
> can write a new front end to his marketing database. He was told that if
you
> put the database name in this spot and the table name in this spot, the
data
> magically appeared in the grid. He had no clue about ADO, RDO, ODBC,
> recordset, what DBMS he was using, never mind that the grid he wanted
would
> have required a 4 table join (his response "What's a join?"). This is not
> easy to use,

I agree. Hey in your corp, who decides these guys get VB on their desktop?
That sounds like it's your real problem, not the jamoke who is using the
tools he's been told to use. It's the folks who are okaying the install that
you need to educate. I wouldn't be surprised if they are C++ folks, or
sysadmins who haven't looked as a BASIC-derived language since an intro to
VB3 in college.

> > > Bottom line to all of this is that we, the professional developers
that
> > give
> > > a crap about our future, that actually read book on occasion, that try
> to
> > > keep up with technology, now have multiple choices. You can stick with
> > > current version of VB. I see this to be a viable option for at 2 to 3
> > years.
> > > Move to .NET. Now you really have a choice of languages. Move to
Delphi
> > and
> > > hope that Borland stays afloat (see Hindenburg). Pick up Java and hope
> > that
> > > Sun does the right thing. Of course you won't be doing to many client
> > based
> > > apps, otherwise your users will hang you for the performance hit <g>.
> And
> > > then of course there is C++ if your feeling really geaky and you have
a
> > long
> > > development cycle. I can't imagine a better time to be in this
business.
> >
> > Interesting. We basically agree - although I think your time estimates
for
> > dotnet are way optimistic and I'm as much concerned about the
> > performance-hit that client-based apps will take with dotnet as with
Java.
> > However, and at the risk of repeating myself - why bother with VB.NET?
If
> > there were a viable migration path from what there is to what MSFT wants
> > there to be, that would make a difference. If there weren't all the
> > gratuitous incompatibilities, that would make a difference. If VB.NET
was
> > seen as the big pile of goo that maintained compatibility and VB# was
seen
> > as the really cool way to go for people who knew hard to learn
languages,
> > that would make a difference too. Any of the preceding would make me
feel
> > better about VB.NET's long-term prospects.
>
> The fact that MSFT has stated that VB6 will be around for a couple of more
> years answers your question. I don't look at it as a migration path. I
still
> have VB3 apps in production. I answered the why VB.NET before, because it
> will be easier to learn for a seasoned VB developer.

Of course, my mileage may vary. Presumably your prognostications carry a
money back guarantee only for as much as I paid for 'em.

Good Luck

[Jon Ogden]

"Jay Glynn" <jay_glynn@agla.com> wrote in message
news:3a6ba12f$1@news.devx.com...
> Bottom line, you can't tell me that someone hasn't snickered at you when
you
> say you are a Vb developer, saying something to effect of when are you
going
> to use real tools etc etc etc. This is because of MSFT marketing saying
how
> easy it is. There was a meeting of managers not to long ago. They wer
> looking at the salary structure, making sure that we were competitive in
the
> current market. A long time COBOL developer now manager made the statement
> "VB programmers should not be making as much as COBOL programmers.
Everyone
> knows VB is easier to use." This is the kind of attitude that I am getting
> tired of. If that makes me arrogant, so be it.
>

Nope, the technical term is defensive. I understand feeling that way from
time to time and I've heard the same stuff. However, it's all a pssing
contest and if you think it'll stop because of VB.NET, I'll offer the
money-back guarantee that it won't. If you were a COBOL programmer, you'd
be angry because everyone called you a dinosaur.

Good luck,
Jon

[Jay Glynn]

Jon,

> Nope, the technical term is defensive. I understand feeling that way from
> time to time and I've heard the same stuff. However, it's all a pssing
> contest and if you think it'll stop because of VB.NET, I'll offer the
> money-back guarantee that it won't. If you were a COBOL programmer, you'd
> be angry because everyone called you a dinosaur.
>

You may be right, but I hope that the attitude changes somewhat. It just
gets annoying.

--
Jay Glynn
Introducing .NET
ISBN: 1861004893
Wrox Press Ltd.

[mrfelis]

Bob Butler <butlerbob@earthlink.net> wrote in message
news:3a69f978@news.devx.com...
> Actually, for me the alternative is probably more like:
Honestly, I had originally coded the alternate as:
if x<5 and y<5 then
i=3
elseif y<5 then
i= 2
elseif x<5 then
i=1
end if

But i figured some one would complain. This isn't far off from what you have
here:

> If x<5 then
> if y<5 then
> i=3
> else
> i=1
> end if
> elseif y<5 then
> i=2
> else
> i=0
> end if

And how would you write the code for a condition like:

x<5 -> 1
y<5 -> 2
x<5 and y<5 -> 3
z<5 -> 4
z<5 and x<5 -> 5
z<5 and y<5 -> 6
z<5 and y<5 and x<5 -> 7

The expression:
i = (cint(x<5) and 1) + (cint(y<5) and 2) + (cint(z<5) and 4)

is very consice. If you are fimiliar w/ boolean arithmetic, it is also very
obvious what is going on. So why did MS take boolean arithmetic away from
us?

x<5 will be either true or false.
cint() converts this to 0 or -1 (no ibts set vs all bits set)
And 1 returns 0 or 1.

> Personally, I prefer the If/Then construct simply because I find
maintenance
> easier. When code is condensed down using IIF or conversion of boolean to

I'd say the opposite to be true since code is being repeated. If the
condition of y<5 needs to be changed to y<10, will the programmer remember
to change both y<5 expressions? If the boss is breathing down the
programmer's neck, most likely no. (You have to make 4 changes for the three
independent changes - using an extension of your sample above.)

Now you and I know that this is the reason for constans. However, would you
have defined two constants (1 for x and 1 for y) that were both 5? This
would be even more prone to errors since we would have add a new constant,
and use this new constant in the correct place.

The more changes that have to be made, the more chance Murphy has to do his
magic.
--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com
Bob Butler <butlerbob@earthlink.net> wrote in message
news:3a69f978@news.devx.com...
>
> "mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
> news:3a69d0e1$1@news.devx.com...
> > > > CInt(Bool)
> > >
> > > Ok ... btw, I've never ever done that sort of thing. Maybe I just
don't
> > > write clever algorithms. What's the point of converting bools to
ints?
> > Say you need a number 1 if x is <5, a 2 if y is < 5, or a 3 if x<5 and
> y<5.
> >
> > The following line of code will do this (in VB 6):
> > i = (cint(x<5) And 1) + (cint(y<5) And 2)
> >
> > The alternative is:
> > i = 0
> > if x<5 then
> > i = i +1
> > end if
> > if y<5 then
> > i = i + 2
> > end if
>
> Actually, for me the alternative is probably more like:
> If x<5 then
> if y<5 then
> i=3
> else
> i=1
> end if
> elseif y<5 then
> i=2
> else
> i=0
> end if
>
> and you could also use something like:
> i=iif( x<5, iif(y<5,3,1),iif(y<5,2,0))
>
> Personally, I prefer the If/Then construct simply because I find
maintenance
> easier. When code is condensed down using IIF or conversion of boolean to
> integer it quickly becomes easy to read it wrong. Unless there's a
pressing
> need to optimize execution the longer code is best IMO.
>
> That still does not mean that changing Boolean from -1 to +1 in VB.Net was
a
> good thing.
>
>
>

[Bob Butler]

"mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote in message
news:3a6c5571@news.devx.com...
> Bob Butler <butlerbob@earthlink.net> wrote in message
> news:3a69f978@news.devx.com...
> > Actually, for me the alternative is probably more like:
> Honestly, I had originally coded the alternate as:
<cut>
> But i figured some one would complain.

Somebody will always complain no matter how you write it. <g>

> And how would you write the code for a condition like:
>
> x<5 -> 1
> y<5 -> 2
> x<5 and y<5 -> 3
> z<5 -> 4
> z<5 and x<5 -> 5
> z<5 and y<5 -> 6
> z<5 and y<5 and x<5 -> 7

I might use a nested If/Then construct... I might use the booleans and bit
masks... I might do something like:
i=0
If x<5 then i=1
If y<5 then i=i+2
if z<5 then i=i+4

A lot depends on the overall context of the calculation in relation to the
rest of the code, the expected lifetime of the app and ho is likely to be
maintaining it.

> The expression:
> i = (cint(x<5) and 1) + (cint(y<5) and 2) + (cint(z<5) and 4)
>
> is very consice. If you are fimiliar w/ boolean arithmetic, it is also
very
> obvious what is going on.

I guess I've worked too long with people who don't understand the bit-level
manipulations; it isn't the boolean to integer that confuses them when
working on the code but rather the " (-1 And 4) " part that gets them lost.
Being too concise in the code doesn't help when you need several lines of
comments to explain it.

> So why did MS take boolean arithmetic away from us?

You can still do: i=(cint(x<5)) + (2*cint(y<5)) + (4 * cint(z<5))

> x<5 will be either true or false.
> cint() converts this to 0 or -1 (no ibts set vs all bits set)
> And 1 returns 0 or 1.
>
> > Personally, I prefer the If/Then construct simply because I find
> maintenance
> > easier. When code is condensed down using IIF or conversion of boolean
to
>
> I'd say the opposite to be true since code is being repeated. If the
> condition of y<5 needs to be changed to y<10, will the programmer remember
> to change both y<5 expressions? If the boss is breathing down the
> programmer's neck, most likely no. (You have to make 4 changes for the
three
> independent changes - using an extension of your sample above.)

If it's all together in a few lines of code then it is not so likely to be
missed.

> Now you and I know that this is the reason for constans. However, would
you
> have defined two constants (1 for x and 1 for y) that were both 5? This
> would be even more prone to errors since we would have add a new constant,
> and use this new constant in the correct place.

If the two constants represented different things then I probably would. As
an example, vbNormal is a Windowstate constant with a value of zero and
vbDefault is a MousePointer constant with a value of zero. Since they
represent different things they are unique constants even though they have
the same value. In the case you mentioned having a constant to represent
"5" means I may as well just use the literal value. Having a constant for
the "X-limit" and another for the "Y-limit" makes sense to me even if they
both happen to be 5 at the current time.

> The more changes that have to be made, the more chance Murphy has to do
his
> magic.

And the clearer and more explicit the code is the less likely he can worm
his way in. If I am coding something for myself only then I do use
"tricks" like the bit masks and boolean operations to reduce the amount of
code. If I'm coding something that may need to be maintained by somebody
else then I try to avoid them. Since I don't know the skill level of the
person who will need to work on it I just find it works best to be a little
more verbose, either in code or comments or both. YMMV

[Dan Barclay]

On Sat, 20 Jan 2001 21:15:12 -0800, "Michael \(michka\) Kaplan"
<former_mvp@spamfree.trigeminal.nospam.com> wrote:

>Actually, THAT anger is for entirely different reasons, they are not going
>through these stages.

True fact.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Zane Thomas]

"mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:

>The following line of code will do this (in VB 6):
>i = (cint(x<5) And 1) + (cint(y<5) And 2)

I understand your example, and the more complex one where x is x(). But
still I don't understand how you would frequently arrive at a situation
where computed numeric values need to be converted to booleans. It seems
somehow that you're computing integers when you want booleans.

I suppose maybe there are situations where there is no alternative design.
I don't recall every seeing one myself, in 25 years of programming. I
guess that's either because I work on different sorts of problems, or
maybe because I design differently.

What I'd like to _suggest_ is that perhaps you were influenced in your
design by knowing that you could use what appears to me as a risky
solution and that if you had tried to avoid that situation you would have
had a design which different. That's what I've been trying to say in this
thread - that designing to take advantage of oddities of a language is not
necessarily a good idea.


---
Ice Z - Straight Outta Redmond

[Zane Thomas]

"Jon Ogden" <jon@ogdenco.net> wrote:

>> >What is your guess as to which dotnet language you will use the most?
>>
>> C#
>
>I am beginning to believe that answer holds for me, too.

You should know that I've been writing components in c/c++ for the past
many years (since vb1) and so c# is a natural for me.

>but maybe we aren't really speaking the same language. Perhaps you'd like
>to give your (re)definition of the word "incompatible?"

I don't see any point in getting into such a discussion.


---
Ice Z - Straight Outta Redmond

[mrfelis]

Zane Thomas <zane@mabry.com> wrote in message
news:3a776dd3.582968671@news.devx.com...
> >i = (cint(x<5) And 1) + (cint(y<5) And 2)
> somehow that you're computing integers when you want booleans.

Nope, I don't want booleans. The expression return return booleans. I'm
converting them. The function feeds a state machine (select case) based on
the conditions provided.

> What I'd like to _suggest_ is that perhaps you were influenced in your
> design by knowing that you could use what appears to me as a risky
> solution and that if you had tried to avoid that situation you would have
Had this been a risky soultion, MS would not have documented (and very well
at that) that True = -1. MS well knows the principals of undocumented code
as evidenced by the extent of undocument DOS API functions they implemented
in the 80's and didn't tell anyone about.

Using undocumented features was considered risky since MS didn't want to be
bound by those features and reserved the right to change them at will.
Changing a documented rule is the equivalent of breaking a contract.

How happy would you be if mathmaticians decided to decide that 1+1=3? MS
made booleans that way: Not 0 = -1. Not False should = True. I assume this
is the reason Fred doesn't support bitwise operators anymore.

> had a design which different. That's what I've been trying to say in this
> thread - that designing to take advantage of oddities of a language is not
> necessarily a good idea.
Boolean algebra isn't an oddity. It is the foundation of digital
electronics, and by extension, computers and programming. So what oddity are
you talking about?


--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com

[Joe \Nuke Me Xemu\ Foster]

"Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote in message <news:3a6c45ae$1@news.devx.com>...

> It seems likely that it will NOT change, except to get worse, all things
> considered.
>
> But people ahve been rationalizing this one with each version, so its
> unsurprising that people such as yourself would rationalize now....

It *will* be different this time, if only the name were to actually
change to Fred. IMH(?)E, the cow-orkers who snickered at Visual
BASIC took Access apps seriously, simply because I'd always say
"Access Script Language" instead of "Visual Basic for Applications".
Yeesh!

--
Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <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!

[Joe \Nuke Me Xemu\ Foster]

"Mark Burns" <mark@iolofpa.com> wrote in message <news:3a6c2de8@news.devx.com>...

> "Mike Mitchell" <visual.basic@freeuk.com> wrote in message
> news:3a6a0587$1@news.devx.com...

> > call each other names, we shake our fists, and soon there's blood on the
> > carpet and the opinions are more entrenched than ever.
> >
> > We're humans. It's what we do.
>
> Correction: It's what we do <by default?> when we're too
> stupid/arrogant/prideful to understand there's a better way, then find that
> better way, and use it.

Naah, too much trouble to track the guy down, since his project at
a different company is on a death march and his team leader's locked
everybody in a dungeon to keep them from being distracted by useless
stuff like sleeping, bathing, eating, spouses, children, therapy
appointments, or divorce court appearances, let alone pesky former
cow-orkers with a question about old code...

--
Joe Foster <mailto:jfoster@ricochet.net> Got Thetans? <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!

[mrfelis]

Bob Butler <butlerbob@earthlink.net> wrote in message
news:3a6c5a19$1@news.devx.com...

> > But i figured some one would complain.
>
> Somebody will always complain no matter how you write it. <g>
Don't I know it!

> > And how would you write the code for a condition like:
> A lot depends on the overall context of the calculation in relation to the
> rest of the code, the expected lifetime of the app and ho is likely to be
> maintaining it.

True enough. It depends on what you're doing. It should never depend on what
a private corperation feels like changing though!

In corperate America, I find it unlikely to know who is going to inherit my
code. I've found code broken in my own projects (very simple things - no
tricks involved) that other developers have made. I've also worked
concurrently with a very green programmer who didn't understand the concept
of the IF statement. I came to work one morning to find that a very large
section of code had been changed. The programmer who did this had duplicated
the bulk of one the program and placed an IF..else..endif around the new and
old code. The new code was 99% identical to the old code; only 2 lines had
been added - one immediately followed the other.

So, I'm not really sure it is a valid notion to code to the lowest
denominator in programming skills. How far can you take it? I fell whoever
inherits code needs to get up to speed on how the code works.

> I guess I've worked too long with people who don't understand the
bit-level
> manipulations; it isn't the boolean to integer that confuses them when
> working on the code but rather the " (-1 And 4) " part that gets them
lost.
> Being too concise in the code doesn't help when you need several lines of
> comments to explain it.
Why not? Comments don't break code.

>
> > So why did MS take boolean arithmetic away from us?
>
> You can still do: i=(cint(x<5)) + (2*cint(y<5)) + (4 * cint(z<5))
Ironically, this requires a ABS() around the entire thing to work in VB6.

>
> > x<5 will be either true or false.
> > cint() converts this to 0 or -1 (no ibts set vs all bits set)
> > And 1 returns 0 or 1.
> >
> > > Personally, I prefer the If/Then construct simply because I find
> > maintenance
> > > easier. When code is condensed down using IIF or conversion of
boolean
> to
> >
> > I'd say the opposite to be true since code is being repeated. If the
> > condition of y<5 needs to be changed to y<10, will the programmer
remember
> > to change both y<5 expressions? If the boss is breathing down the
> > programmer's neck, most likely no. (You have to make 4 changes for the
> three
> > independent changes - using an extension of your sample above.)
>
> If it's all together in a few lines of code then it is not so likely to be
> missed.
Unfortunately, unless your he only one to work on the code, you can never
ensure that will remain the case.

> > Now you and I know that this is the reason for constans. However, would
> you
> > have defined two constants (1 for x and 1 for y) that were both 5? This
> > would be even more prone to errors since we would have add a new
constant,
> > and use this new constant in the correct place.
>
> If the two constants represented different things then I probably would.
As
> the "X-limit" and another for the "Y-limit" makes sense to me even if they
> both happen to be 5 at the current time.

I'll give you that one.

>
> > The more changes that have to be made, the more chance Murphy has to do
> his
> > magic.
>
> And the clearer and more explicit the code is the less likely he can worm
> his way in. If I am coding something for myself only then I do use
> "tricks" like the bit masks and boolean operations to reduce the amount of
Often enough, tricks are reqyuired to make the impossible possible. Video
games are the typical breeding ground of such "unorthodox" tactics.

> code. If I'm coding something that may need to be maintained by somebody
> else then I try to avoid them. Since I don't know the skill level of the
> person who will need to work on it I just find it works best to be a
little
> more verbose, either in code or comments or both. YMMV
>

I'm a bit intolerant here. If a programmer can't understand the code by
looking at it then he should step through it and figure out what is going
on. If he can't do that, he ain't worth his salt.

--
~~~
!ti timda I ,KO
..em deppals nocaeB sivaM
!draH
~~
C'Ya,
mrfelis@yahoo!com

[Sjoerd Verweij]

> But VB *is* easier to use. After all, I once managed to whip out a
> live demo that exceeded capacity and responsiveness requirements
> even on the old Dauphin DTR-1 I scrounged up on a lark (or maybe
> just to be "arrogant"?) while the MFC gurus were still chasing GPFs
> and wondering why populating list boxes was taking 90 seconds plus!

Erm, that's because you know how to *program*. We're talking users trying to
program (and defaming the language because of it), not programmers using VB
as the extremely productive programming language it is.

[Jonathan Allen]

> The expression:
> i = (cint(x<5) and 1) + (cint(y<5) and 2) + (cint(z<5) and 4)
>
> is very consice. If you are fimiliar w/ boolean arithmetic, it is also
very
> obvious what is going on. So why did MS take boolean arithmetic away from
> us?
>

That isn't Boolean Arithmetic as defined in mathematics. If it was, the +
would mean the same as Or and the resulting i could only equal 1 or 0.

From what I can tell, what you are trying to do is still possible by using
BitAnd.

--
Jonathan Allen

[Zane Thomas]

"mrfelis" <mrfelis@yahoo.NOSPAM.com> wrote:

>Zane Thomas <zane@mabry.com> wrote in message
>news:3a776dd3.582968671@news.devx.com...
>> >i = (cint(x<5) And 1) + (cint(y<5) And 2)
>> somehow that you're computing integers when you want booleans.
>
>Nope, I don't want booleans. The expression return return booleans.

Actually in both cases, x and x(), the expression you started with was an
integer which you then converted to boolean, then to bitwise boolean, and
then to an arithmetic expression. It's that mixing of boolean and integer
operations that I cannot recall having ever seen the need for.

>I'm converting them. The function feeds a state machine (select case)
>based on the conditions provided.

Having done a fair amount of realtime programming I'm very familiar with
state machines. You rejected, prima facie apparently, the use of
intermediate variables to hold results such as x() < 5. I wouldn't do
that, instead viewing the intermediate variables as a way to provide
symbolic names which when used in a boolean expression which actually
clarififies the logic of the situation. Of course I don't think most code
needs much in the way of comments when written that way. My sense of the
situation being that it makes a lot more sense to read code, which never
lies, as opposed to comments which are not executable.

>How happy would you be if mathmaticians decided to decide that 1+1=3?

I might be very happy if some class of problems could be better solved
with such a redefinition. But I probably wouldn't use it for balancing my
checkbook.

>> had a design which different. That's what I've been trying to say in this
>> thread - that designing to take advantage of oddities of a language is not
>> necessarily a good idea.
>Boolean algebra isn't an oddity. It is the foundation of digital
>electronics, and by extension, computers and programming. So what oddity are
>you talking about?

I never said boolean algebra is an oddity, so let's leave that strawman
for the crows ok? What I did say is that mixing integer and boolean
expressions seems unnecessary and odd. As I described above I prefer to
make the distinction clear to the reader by making the transition from
integer to booleans explicit in the code.


---
Ice Z - Straight Outta Redmond