Peter,
Peter Row said:
If that implementation of Len() is correct then why in your original
example
code did you write MsgBox(CStr(Len(s)) when the CStr() according to
your implementation of Len is not needed.
Notice that 'Len'/'String.Length' return an 'Int32', which must be converted
to a string either explicitly or implicitly to be shown as part of the
messagebox's text. 'CStr' is simply VB.NET's replacement of 'ToString'.
Both are not mandatory, even when 'Option Strict' is set to 'On', but it's
better to explicitly specify them to make more clear that the developer who
wrote the code knew what he/she was doing
.
No - I suggest you stop trying to be all high and mighty and read
correctly what I have said. My original post and aim was to remove
functions and constants which are replicated in the framework, i.e.
Left().
From my point of view, there is no 1:1 replacement for 'Left'. There is a
method that can be used to archieve the same result, but is more low-level
because it is more generic in name and functionality. Maybe 'Left' is not
the best example. Consider the 'Right' method. 'Right' cannot be replaced
by 'Substring' directly without doing some position calculations.
'Strings.*' provides a complete and consistent set of functions for string
manipulation. 'Mid' assignment, 'Right', 'Split', for example, do not
duplicate functionality provided by the 'String' class.
+ could work on number but it could just as well work on strings.
Your argument seems to say "read the function called, ignore all the
parameters involved and you should be able to say exactly what is
happening".
That's what I mean. The more information a function's name carries the
better. When reading 'Left' or 'Right', I know more about what's done when
reading 'Substring'. In a 2nd step, I analyze the parameters.
Left(myVariable, 5) does not necessarily tell you that it is working with
strings. And you have fallen foul of your own argument.
Why doesn't it tell that it's working with strings? That's what every
VB.NET programmer should know...
You say, and I quote "Everybody who /learns/ VB.NET will
learn what 'Left' does", so therefore why is it so bad to /learn/
what Substring() does and use that instead of Left(). And don't
say "because it's easier to read" because it is not.
My answer is that 'Left' is easier to read. The name simply contains more
information than 'Substring'. It's not bad to learn what 'Substring' does,
but even when knowing that it either takes a part of the string from the
left side or a part from the middle of the string the reader will have to
analyze the parameter list to decide what's done.
You either know what a function is for or you don't and when
reading code to find out what it's doing you read it and take into account
the parameters passed not just the name of the function.
The name of the function gives a fist idea of what's going on, which is very
important. Otherwise we could simply name methods from 'Method1' to
'Methodn' and always rely on analyzing the parameter list.
I have not checked if what you have said about WithEvents is correct but
it sounds like you are. I apologise for not checking myself first.
No problem. We are all here to learn
.
- VB has no operator overloading, C# does.
VB 2005 will contain operator overloading.
- VB requires use of function calls when adding event handlers
programmatically
No. 'AddHandler' is not a function, it's a statement.
C# does not.
- VB requires a function call to convert the simplest of types C# does
not, i.e.:
CStr(myNumber) as opposed to - (string)myNumber
Although 'CStr' looks like a function call, 'CStr' does the same as
'(string)' in C# (casting or conversion, depending on the case).
MSDN:
| These ['C*'] keywords act like functions, but the compiler generates
| the code inline, so execution is slightly faster than with a function
call.
