> > I can't think of a logical reason why the guy who wrote the Format() > > function would do this. In fact, I would think it would be best to > > convert anything passed in, no matter what, into a string, do the > > formatting (which is now easier cause it is a string) and > then return > > the result. > > Not being a VB6 user, I have a hard time imagining this is a > good thing. > Could you not specify any type of formatting for the results? > If what I > handed to Format was converted to strings by the system > before Format even > got a look at it, that's potentially quite wasteful. Who's to > say it was in > the right format, and that all precision was maintained? I > suppose in some > lucky instances, the passed in string might be right, but in > many others I > could forsee having to turn that string back into a native > type, so it could > then be properly formatted. >
No, it was converted for display according to local settings. And then formatted based on those values. IMO, type safe formatting would lead to either aggregation behind the scenes, or duplicated code, as handlers for each type and formatting were written. Plus each handler may not necessarily be true across all types. FWIW, this is what we now have in VB.NET. The code which interprets and displays the format for the date datatype is apparently *not* the same as that which is used for numbers, or for strings. It's not an issue of running format on string data and not getting the same results as if you ran it on date data. That is actually expected and has hung people up in VB before. It is a common issue. It is more that the functionality of the format function for string data no longer works. The function accepts a string, a number, or a date (and probably other things), the function should then be able to handle formatting the data in any way the user requested. Even if, to the original developers, that may seem nonsensical (formatting a string as if it were a date). What we have now is a less robust function. IMO, it is not an issue of type safety. They've obviously overloaded the function to accept arguments of multiple types. It should behave the same on all those types. > But perhaps this is my C++ bias. Our formatting possibilities > were quite > powerful. Your e-mail illustrates to me how badly VB > programmers need to be > yanked out of their type-less world for their own good. > LOL. I think of variables in terms of the information stored in them (integer = 32 bytes, for instance). Choosing to store my 32 bytes as an integer or in an array of 32 bytes doesn't make a difference in my mind. The only reason I would choose one over the other is the functionality that data type may give me. But in C++ I can't pass my int to a function that expects an HWND. It gives me a type mismatch. Even though it is the same amount of data. I find *that* inferior to VB. You talk about VB hand holding and type coercion and then you go on and on about the virtues of type safety. It's just another form of hand holding. One that the compiler, IMO, does *not* need to be doing. I may have perfectly legitimate reasons for using a value as an int in one place, a byte array in another, and a HWND in yet another. I don't need the compiler making those decisions for me. We (VB developers) develop this mentality through use of the API and translating between C++ and VB. And really, that's what it comes down to. It is differences in development style and mentality and thought. I mean, I *know* you C++ guys don't think like this. Only a good VB developer would. You simply don't work with the languages in the same way. The worse decision Microsoft made, IMO, was getting C++ developers to create VB.NET--and then not change the name to something besides VB. As a language, there is nothing wrong with VB.NET, except that it was obviously not designed by someone who used VB regularly. I mean, I don't mind using C++. A language is a language as long as it allows me to accomplish my task with a minimum amount of effort. But I prefer the way I work with VB6. In many ways, it allows you more flexibility with less work than C++. And is (IMO) a more natural way of thinking about code. Patrick Burrows I was stirring my brandy with a nail boys -------------------- Now Playing: depeche mode - everything counts -------------------- You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
