Re: Some thoughts on VB9

I agree with you wholeheartedly... you hit the nail on the head much better
than I did.
Indeed, the problem is overuse I think. Implicit typing while convenient in
*some* situations, should not become a "standard practice." I am terrified
that- in the VB community- it will become so.

However, if you look at the LINQ stuff and how that works (IMO it's very
B.A.S.I.C. "statement" - like.... which we've lost a lot of in VB.NET like
"Open file For Input As Access... or many of the screen drawing statements)
implicit typing is very useful and makes more sense.

--
-C. Moya
www.cmoya.com
"_AnonCoward" <abcdef@xxxxxxxxxx> wrote in message
news:1fZNf.51095$no3.31361@xxxxxxxxxxxxxxxxxxxxxxxxxxx

"CMM" <cmm@xxxxxxxxxx> wrote in message
news:%23TTqVpKPGHA.2624@xxxxxxxxxxxxxxxxxxxxxxx
:
: To answer your questions about implicit types:
: While Strings might be obvious, and it might seem obvious that
: Dim s = 1
: is an Integer.
: But, is it obvious that later in the method
: s / 2 will produce the results you might later expect if Option Explicit
: is Off or was removed by some other developer in the code's chain of
: custody?
: or that
: Dim s = 1.0
: is a floating point single, floating point double, or a decimal type.
: or that
: Dim s = GetFormattedNumer()
: returns a stringbuilder and not a number or a string
:
: The use of it in For/Loops is even more ingratiating.
:
: From what I've read the C# community already has come out against
: overusing implicit type declarations. They're pretty good with not
: adopting bad habits. The fact that implicit types encourage laziness
: is something that has incredible potential for abuse.
:
:
: --
: -C. Moya
: www.cmoya.com


<snip for space>

I've debated submitting this response as I'm really not adding anything to
the discussion but I've come to the conclusion I agree that implicit types
are not a good idea. I've just reach this conclusion for a different
reason.


You seem concerned that this will encourage laziness and lead to abuse.
Perhaps, but I don't think that is all that great of a concern. Your
statement that the "C# community already has come out against overusing
implicit type declarations" implies (at least to me) that it isn't
implicit
typing that is the issue, but overuse of the mechanism. When all is said
and
done, the variable is being instantiated as a specific type with all the
safeguards that entails. I may not know that "Dim s = GetFormattedNumer()"
will set s to a StringBuilder object, but I am still constrained to using
s
identically as if I'd explicitly declared the variable type up front.


That said, the more I play with this, the less I'm liking it. What struck
me
at first as being a convenient shorthand now seems more like a maintenance
headache. I may know as the original coder what my intentions were for the
following:


Dim s = GetFormattedNumer()


But as someone coming after the fact to maintain the code, it isn't nearly
so obvious. In fact, I'll run into that problem even if I'm the original
coder returning to the code six months later. I recognize now that every
time I come across an implicit type statement, I will have to mentally
discern the assignment type. It could cost me in time and additional bugs
in
the code if I misread the type. The following may be equivalent, but the
second statement is much clearer:


Dim I = 1
Dim I As Integer = 1


So, yeah - on further reflection, I agree that implicit typing is not that
good of an idea after all.


Ralf
--
AA #2250
-------------------------------------------------------------
* ^~^ ^~^ *
* _ {| |} {| |} _ *
* /_``>*< >*<''_\ *
* (\--_)++) (++(_--/) *
-------------------------------------------------------------
Nature is the canvas of creation and evolution but one of
the brushes. Religion points to the mind of God; Science
reveals its unfolding. The subjective apprehends knowledge
while the objective facilitates understanding.

In all things, yin and yang - ever flowing, one into the
other; always overtaking, always overtaken.




.

Relevant Pages

  • Re: fortran 90/95 standard
    ... > I've a small question about fortran 90/95 standard: ... > I've a function using implicit types: ... First: try to avoid implicit typing :-) ... > This occur with gfortran but not with intel compiler nor IBM xlf ...
    (comp.lang.fortran)
  • Re: IMPLICIT NONE (F2k8+/-)
    ... Nobody will be inordinately placed in hardship. ... > big enough of a deal to add a switch as to even argue against it. ... To make it the default disadvantages those of us who like implicit typing - ...
    (comp.lang.fortran)
  • Re: Exponetial Interpolation VBA Code
    ... Function ExpInterp2(D As Variant, P As Variant, V As Double) As ... Dim DDiff As Double, Logslope As Double, LogInterp As Double ... Goofy implicit assumptions are that D and P are single column ranges ...
    (comp.apps.spreadsheets)
  • Re: IMPLICIT NONE (F2k8+/-)
    ... >> like implicit typing, and those who don't, so that to change the standard to ... that would provide the appropriate compiler action. ...
    (comp.lang.fortran)
  • Re: Problem when creating a.out and -convert big_endian compiler option
    ... Fortran programs really means. ... of "implicit typing" where the first letter of a name ... Fortran has had a statement "implicit none" to disable the implicit ... First letter in, ...
    (comp.lang.fortran)