Re: Overflowing a Long

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Robert Morley <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Okay, at the risk of crossing sub-threads, I'm gonna respond to this
message, because I think it summarizes the fundamental point of the other
one, without being several screens long. :)

WRONG! That's the point, as well. To *learn* programming, objects are a
bad way to start.

This is something of a different point than the other. We'll leave .NET out
of this discussion, since that would just obfuscate your point (seeing as
pretty much EVERYTHING is an Object there). I suppose I would agree with
your statement above, at least insofar as any programmer worth their money
is concerned. If you want to write a two-bit program that does little more
than "Hello World", I'm not sure it matters whether you start with objects
or not. Certainly if you want to get into things like designing your own
classes and such, I think you'd better know a bit more about the
fundamentals than objects alone. They may provide an appropriate context to
your learning, though, so whether they should be introduced only later, or
presented in tandem with lower-level techniques is up for debate. But I'm
not an instructor, so I won't try to debate the best option there.

Surprise, surprise, surprise... We agree! :-)

But the original point wasn't whether or not objects are a good way to learn
programming, but whether or not the syntax of file handling in VB was good
or not.

Considering MSBasic is/was, at its core, a learning language (albeit one that could
subsequently be leveraged to do just about anything!), it seems your definition of
"good" is somewhat contextually removed.

And I'd have to say that while it may provide a good insight to how
things work at a low level, I still think there were MUCH better ways to
design it, even if you avoid OOP entirely. Take for example, this
function...why not incorporate THIS into the language as the main way of
opening files instead of what I consider to be the horrible syntax they're
using.

Well, because. <g> The *original* BASIC didn't have functions, per se. Certainly
nothing on a complexity scale such as that. And, since those very first days at
Dartmouth, the objective was to always allow code to move forward. That is, until
that fateful day in 2001 when forward-compatability was declared obsolete.

(This wouldn't work as written, and you'd probably want to add more
to it in terms of handling various things, but it demonstrates the point,
anyway.)

Public Function OpenFile(ByVal strFileName As String, _
Optional ByVal OpenMode As OpenModeEnum, _
Optional ByVal IOMode As IOModeEnum, _
Optional ByVal LockMode As LockModeEnum, _
Optional ByVal lngRecordLength As Long) As Integer

Dim intFileNum As Integer

intFileNum = FreeFile()
Open strFileName For OpenMode IOMode LockMode As intFileNum Len =
lngRecordLength
OpenFile = intFileNum
End Function

And besides, you've pretty much just replicated the intrinsic Open statement, with
the *only* possible real benefit being that it could now support Intellisense.

Then opening a file would be a standard function call with parameters that
would show up in Intellisense.

I swear, I didn't read ahead. <g>

Wouldn't that make a hell of a lot more
sense than the clunky format they chose to use instead?

See: Forward-Compatability. Or,

Language Stability
http://vb.mvps.org/tips/stability.asp

Written that way at
the low level, I doubt there would've been any speed differences, since
either way, you're wrapping around system calls. And after all, most other
non-primitive language elements are function calls or OOP (mind is blanking
on the proper term, but by "primitive" I mean things like comparison
operators, math, assignments, etc.). Same thing goes for the "Name"
statement. Pretty straightforward (in fact, I'll even go so far as to say
simpler than a sub), but to my mind, it still would've made a lot more sense
to have it as a sub like almost everything else, rather than a statement of
its own that doesn't match the grammar of the rest of the language.

Well, there ya go again. <g> The stuff you're complaining about goes back to
Dartmouth. It's the price we pay for being able to reuse our code. And it's really
not *that* bad. Really. :-)
--
..NET: It's About Trust!
http://vfred.mvps.org


.

Relevant Pages

  • Re: Overflowing a Long
    ... fundamentals than objects alone. ... Optional ByVal IOMode As IOModeEnum, ... Optional ByVal LockMode As LockModeEnum, ... Dim intFileNum As Integer ...
    (microsoft.public.vb.general.discussion)
  • Re: Overflowing a Long
    ... Considering MSBasic is/was, at its core, a learning language (albeit one ... Optional ByVal IOMode As IOModeEnum, ... Optional ByVal LockMode As LockModeEnum, ... Dim intFileNum As Integer ...
    (microsoft.public.vb.general.discussion)
  • Re: Overflowing a Long
    ... fundamentals than objects alone. ... Optional ByVal IOMode As IOModeEnum, ... Optional ByVal LockMode As LockModeEnum, ... Dim intFileNum As Integer ...
    (microsoft.public.vb.general.discussion)
  • Re: OT: The Geek defense
    ... underlying skill, that really shouldn't be language dependent... ... You are assuming the presence of fundamental programming skills. ... fundamentals, so for us changing languages or development environments is ...
    (comp.lang.cobol)
  • Re: OT: Tax the rich???
    ... just fundamentals with no religious ... affiliation. ... I was delighted to see students dressed properly, no bad language, and ... a significant parent turn-out. ...
    (sci.electronics.design)