Speaking of strings... - Page 5


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 5 of 17 FirstFirst ... 3456715 ... LastLast
Results 61 to 75 of 247

Thread: Speaking of strings...

  1. #61
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >So, if there's nothing wrong with functions, why introduce methods?
    >Why make strings objects? Why? What's the point?


    The point is that if you don't, then half the language is based on functions,
    and the other half is based on objects. This is purely legacy thinking,
    and it is the kind of thing that makes a language more complex than it needs
    to be.

    BASIC did not support objects 10 years ago. It does now. In both VB6 and
    VB.NET.

    Here is an example of complexity. Let's find the "length" of something.


    VB6

    String: Len(MyString)
    Collection: MyCollection.Count
    Array: UBound(MyArray) - LBound(MyArray) + 1
    That is, only if array is initialized.

    Okay, now look at C#:
    string: myString.Length
    IList: myList.Length
    Array: myArray.Length


    In VB6, every new feature got a new syntax, or at least a new function name
    (VB doesn't support overloading) so nothing is the same. Nothing is consistent.
    You don't think about this because you have been doing it so long it is
    second nature to you, but it makes the language disjoint and is more difficult
    for new programmers to learn.

    When you start to treat everything as an object (C# does this), it simplifies
    the language, conceptually. Some objects can be compared. Some can be copied.
    Some serialized. Some have a length.

    All objects that can be compared can be treated the same way.

    All objects that can be serialized can be treated the same way.

    All objects that can be copied can be treated the same way.

    It is consistent throughout the language, and throughout the framework.


    For a programmer, it is like when you buy a new program for Windows, and
    you open it up and start using it. It looks familiar to you, so you don't
    have as steep a learning curve. The same thing happens when code libraries
    have common designs.

    Once you learn part of the framework, other parts begin to look really familiar
    to you. When you learn a little more, other parts seem to make sense. It
    fits together and you can use it quickly, despite the fact that it is totally
    different from VB6, which is what you are used to.

    Of course, Mike, you can just continue to be stubborn, and continue to say,
    "I just don't understand..." or point out that Microsoft didn't sell 4 million
    copies of .NET in the first month of release. Until you actually take the
    time to study the software a bit, you won't understand.

    That is your choice. But quit asking silly questions when you haven't even
    tried to answer them yourself.

  2. #62
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Mark Hurd" <markhurd@ozemail.com.au> wrote

    > Also when using interfaces on value types:
    >
    > http://msdn.microsoft.com/library/en...VBSpec10_4.asp
    >
    > This does seem to mean that using IComparable for a sort on value types causes
    > 1 or 2 boxed instances of the type to be created on the heap for every
    > comparison. Am I understanding this correctly?


    Unless I've overlooked something, Structures are the only value type classes
    that you can create. If you then implement IComparable on a Structure the
    required routine is declared as:

    Public Function CompareTo(other As Object) As Integer Implements IComparable.CompareTo

    End Function

    ( http://msdn.microsoft.com/library/en...BSpec6_4_1.asp )

    Since the parameter is an Object type, that apparently means that it has to be boxed.

    "It's quite rare that you would write the code to do the boxing; it normally
    happens when you pass a value type variable to a parameter of type object."

    ( http://msdn.microsoft.com/library/en...rp02152001.asp )


    LFS






  3. #63
    Jay Glynn Guest

    Re: Speaking of strings...

    > >*-----------------------*--------------------------------------------*
    > >* CHANGE YOUR OWN OIL * http://www.valvoline.com *
    > >* * *
    > >* Without Costly * *
    > >* Repairs or Tools * *
    > >* * *
    > >* * *
    > >*-----------------------*--------------------------------------------*

    >


    snicker

    (The rest was well said BTW).



  4. #64
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >Subjective measurement is pointless. How can one thus compare
    >different projects or the tools that went to develop them by different
    >teams or companies? I have to know whether developing in .Net is, say,
    >20% more productive than Java, 38% more productive than plain C++, -5%
    >less productive than Delphi, and so on. If there is no way of knowing,
    >all my 'guesstimation' is just that, guesswork.
    >
    >MM


    You are asking meaningless questions. You may have 300 computer books, but
    have you read any of them?

    C++ is infinitely more productive than Java for writing device drivers.
    Java solves problems in certain types of applications, like putting out web
    pages, that C++ can't even touch. Java is much better for high-reliability
    server code, unless you have a lot of time and money for testing, and your
    feature set is not always changing. If execution speed is a big factor (such
    as real time), then Java is probably not a good choice.

    The languages are not equivalent.

    Nobody knows the answers to the questions you ask because no one thinks of
    software productivity in those terms. The best numbers I have seen have
    been wild guesses, even when C++ was in vogue, VB was up and coming, and
    Java was breaking onto the scene. It depends on the application you are
    developing. Some languages are better than others for certain tasks.

    And then there is the variability of programmer skill.



    Let me give you an example. See if you can follow along.

    Write me a VB program that calls out to a web service. But wait, you have
    to write the web service too. Make that in VB, on the server.

    Oh, yeah, and make sure I can change the code on the server without having
    to shut down the web service. Almost forgot to mention that. VB DLLs, once
    loaded into IIS, don't unload.

    Oh, yeah. The client code needs to be self-installing. I don't want my
    users to have to run an installation program every time there is an update.
    Can't use SMS either. And by the way, these are locked down machines, so
    users can't install anything anyway.



    I can't meet several of these requirements with VB6. Period. Won't happen.
    I can easily meet them with VB.NET or C#.

    How would you measure the productivity gain? 38%? 74%? -5%? Yeah, well
    your question doesn't make much sense either.

  5. #65
    Rune Bivrin Guest

    Re: Speaking of strings...

    Mike Mitchell <kylix_is@yahoo.co.uk> wrote in
    news:sat5qush02sa5a03sqafkcj5o2uahv4sk8@4ax.com:

    > Big deal! How many words do you imagine you know in the English
    > language? Quite a few thousand, I expect! I know German in some depth,
    > so I have roughly your vocabulary in English, plus a good 60% of the
    > same words in German. I know others who could speak and write four
    > languages fluently. How many words would they have command over? Just
    > a dozen or so keywords for string functions in VB presents no great
    > challenge at all.
    >

    Then memorizing 5000 classes shouldn't be too hard for you either, right?
    While the rest of us use the object browser, or something similar.

    --
    Rune Bivrin
    - OOP since 1989
    - SQL Server since 1990
    - VB since 1991


  6. #66
    Vinay Guest

    Re: Speaking of strings...


    "Mark Hurd" <markhurd@ozemail.com.au> wrote:
    >Larry Serflaten <serflaten@usinternet.com> wrote:
    >>
    >> After looking for documentation to specifically mention the boxing or
    >> unboxing, I find that it only applies when accessing the methods available
    >> to all objects (those implemented for the Object interface):
    >>

    IMO, this does not sound correct. ValueTypes have their own special implementation
    of these methods and to call them I wonder why one has to box them if I am
    using them from valuetypes themselves.

    >
    >Also when using interfaces on value types:
    >

    Yes. I would say valuetypes are boxed/unboxed when one convert them implicitely/explicitely
    to reference types (classes and interfaces).

    1-2 months back, I had read excerpt (I think on DevX) from some book that
    has explained valuetypes very nicely. The book was either "Applied .NET Framework
    Programming" by "J. Ritcher" or VB.NET book by "F. Balena", I am sorry I
    could not remember for sure.

    BTW, I found MS Documentation pathetic. Its far from comprehensive. Did u
    guys have same problem or its me alone?
    The problem is I don't know when they r going to improve it. I asked MS guys
    in TechEd(India), answer was "no idea" and I have been adviced perhaps I
    should look into CLI docs submitted to ECMA. So now I am waiting for few
    books to come to India sothat I can grab them.

    Vinay.


  7. #67
    Mark Hurd Guest

    Re: Speaking of strings...

    Larry Serflaten <serflaten@usinternet.com> wrote:
    > "Mark Hurd" <markhurd@ozemail.com.au> wrote
    >
    > > Also when using interfaces on value types:
    > >
    > > http://msdn.microsoft.com/library/en...VBSpec10_4.asp
    > >
    > > This does seem to mean that using IComparable for a sort on value types
    > > causes 1 or 2 boxed instances of the type to be created on the heap for
    > > every comparison. Am I understanding this correctly?

    >
    > Unless I've overlooked something, Structures are the only value type classes
    > that you can create.


    Yes, but the built-in value types, and String, all implement IComparable too.

    > If you then implement IComparable on a Structure the
    > required routine is declared as:
    >
    > Public Function CompareTo(other As Object) As Integer Implements
    > IComparable.CompareTo
    >
    > End Function
    >
    > ( http://msdn.microsoft.com/library/en...BSpec6_4_1.asp )
    >
    > Since the parameter is an Object type, that apparently means that it has to
    > be boxed.


    Yes -- I'm just noting the performance/memory usage issue of copying all these
    values to the heap just to do one compare.

    > "It's quite rare that you would write the code to do the boxing; it normally
    > happens when you pass a value type variable to a parameter of type object."
    >
    > ( http://msdn.microsoft.com/library/en...rp02152001.asp )


    In VB.NET I don't believe you can explicitly box, except by casting to Object.

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  8. #68
    Jonathan West Guest

    Re: Speaking of strings...


    "Jason" <jason@hotmail.com> wrote in message news:3da3a707$1@10.1.10.29...
    >


    > I can't meet several of these requirements with VB6. Period. Won't

    happen.
    > I can easily meet them with VB.NET or C#.
    >


    Jason

    The fact that you can do this with C# or VB.NET and not from VB6 is a
    consequence of the change in platform from COM to .NET, not of the change in
    language. The fact that you can do this with both VB.NET and C# is a
    demonstration of the fact that the language is largely irrelevant to this.

    You would be able to do this equally well with a version of VB that retained
    most of the VB6 syntax but which compiled onto the .NET platform.

    Much of the problem with the VB6/VB.NET debate is that there is quite
    inadequate understanding of which parts of the advantage of one or the other
    are down to the language, the IDE or the platform. Each of these can be
    changed largely independently of the others. Not totally independently - for
    instance the way that the platform has been implemented made it difficult to
    implement E&C, and so it got lost from v1.0.

    --
    Regards
    Jonathan West


  9. #69
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 8 Oct 2002 20:48:23 -0700, "Jason" <jason@hotmail.com> wrote:

    >You are asking meaningless questions.


    What? How productive a programming language/platform is, is
    meaningless?

    > You may have 300 computer books, but
    >have you read any of them?


    Of course. Why would anyone buy over 300 computer books over 20 years
    without reading any of them?

    >C++ is infinitely more productive than Java for writing device drivers.


    And, of course, device drivers are what EVERYbody is writing
    nowadays...!

    How about measuring productivity as an overall figure? Wouldn't that
    make a useful comparison between the languages/platforms that much
    easier? Here's an example: VB6 was designed and marketed as "The most
    productive tool for creating fast business solutions." Can you think
    of *any* tool that was faster overall? No, I didn't think you could
    argue with over three million VB programmers!

    But no, you appear to want to concentrate on the dozen or so who were
    stymied in their efforts to produce device drivers!

    >Java solves problems in certain types of applications, like putting out web
    >pages, that C++ can't even touch. Java is much better for high-reliability
    >server code, unless you have a lot of time and money for testing, and your
    >feature set is not always changing. If execution speed is a big factor (such
    >as real time), then Java is probably not a good choice.


    But is Java more productive than .Net? Here's another example: Suppose
    you have a client who commissions a Java application to be installed
    on Windows. A year after the application is installed, the client
    returns and requests that it now be made available for other
    non-Microsoft platforms.

    Now repeat exactly the same exercise, but substitute .Net for Java.

    What system do you suppose will be more productive? Well, the answer
    is Java, obviously.

    >The languages are not equivalent.
    >
    >Nobody knows the answers to the questions you ask because no one thinks of
    >software productivity in those terms.


    Oh, I'm sure they do. But they gave up asking prematurely because no
    one has so far been able to answer them!

    > The best numbers I have seen have
    >been wild guesses, even when C++ was in vogue, VB was up and coming, and
    >Java was breaking onto the scene. It depends on the application you are
    >developing. Some languages are better than others for certain tasks.


    That is, of course, true. But in this group the onus is on VB, and VB
    was always designed and marketed as "The most productive tool..." etc,
    and thus it is the kinds of tasks that are involved in developing
    business applications I'm interested in, not esoteric device driver
    production. Moreover, I suggest that it's business apps that *most*
    computer users are interested in. After all, Microsoft makes a huge
    chunk of money from Office and that is purely and simply about
    business. Period.

    >And then there is the variability of programmer skill.


    Of course, but how will, say, classic VB programmers reuse that skill
    in VB.Net, let alone C#? Classic VB users were often NOT professional
    programmers, but used VB as an 'extracurricular' means to an end, as a
    way of automating some repetitive task that was part of their normal
    everyday duties. How are people like that going to take to VB.Net in
    any meaningful way? What productivity increase can you forecast there?
    My guess is, "not much". But I'd like to get away from guesstimations,
    hence my questions, which you suggest are not being asked by anybody
    else.

    >Let me give you an example. See if you can follow along.
    >
    >Write me a VB program that calls out to a web service. But wait, you have
    >to write the web service too. Make that in VB, on the server.
    >
    >Oh, yeah, and make sure I can change the code on the server without having
    >to shut down the web service. Almost forgot to mention that. VB DLLs, once
    >loaded into IIS, don't unload.
    >
    >Oh, yeah. The client code needs to be self-installing. I don't want my
    >users to have to run an installation program every time there is an update.
    > Can't use SMS either. And by the way, these are locked down machines, so
    >users can't install anything anyway.
    >
    >I can't meet several of these requirements with VB6. Period. Won't happen.
    > I can easily meet them with VB.NET or C#.


    Or Java? Or Delphi?

    >How would you measure the productivity gain? 38%? 74%? -5%? Yeah, well
    >your question doesn't make much sense either.


    Ooh, I think given VB.Net, C#, Java, and Delphi some kind of
    measurement must be possible!

    MM

  10. #70
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 8 Oct 2002 16:48:55 -0700, "Jason" <jason@hotmail.com> wrote:

    >There just happens to be a whole lot of people who are on the theorist side
    >in OO circles, so it makes the rest of us look bad. On the other hand, you
    >have historically had the majority of bad or novice programmers using VB
    >because it was easy to create a form with buttons on it. That also makes
    >the rest of us look bad.


    "makes the rest of us look bad" seems to be a recurring complaint
    here! Firstly, it is the theorists' fault; but then it's the fault of
    those "bad or novice programmers" having the gall to use VB. I don't
    understand why providing a language/programming system that made it
    easy to create a form with buttons on is considered to be such a bad
    thing, because by implication you're saying that if the language had
    been a lot harder, your image would have been preserved! Of course, of
    the over three million VB programmers, not all were bad, despite your
    cavalier use of the word "majority", though all of us, even you, were
    novices once.

    MM

  11. #71
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 8 Oct 2002 14:24:33 -0700, "Jason" <jason@hotmail.com> wrote:

    >You would do better to spend your time trying to get Microsoft to revive
    >the VB6 platform (so it remains as relevant as possible).


    That is exactly what I *AM* trying to do! Like I said earlier, you're
    beginning to understand at last!

    > Microsoft could
    >do this as a separate product line, sort of the way they kept FoxPro around
    >all these years.


    Yes! Yes! Yes! Give than man a gold star!

    >But VB6 is not VB.NET.


    I never said it should be. I just said that VB.Net isn't backward
    compatible. I would prefer it if VB.Net had been flushed down the
    toilet at design stage. As it would have been if more classic VB
    programmers at the time had been let into the secret.

    >VB6 would not, could not, does not fit into the .NET architecture. Why?
    > Well, I would try to explain it to you, AGAIN, but you didn't seem to understand
    >the last 10 or so times.


    Others have suggested that Microsoft *could* have made VB.Net *far
    more* backward compatible! At least it would have got people like me
    more interested in wanting to give VB.Net a go. But rewrite
    everything? Lose umpteen years of carefully-crafted code libraries?
    Lose umpteen years of VBPJ's articles and others' hints and tips? Just
    because Microsoft wants to mimic Java? YeahRight!

    >Don't try to migrate. Don't think about doing it. It can't be done. That
    >was just some Microsoft marketing guys who got drunk one night and made some
    >promises...you know how it is.


    You said it!

    >Just stick with VB6 and don't worry about the rest of the world. The rest
    >of the world will use whatever gets the job done best for them, and in many
    >cases it will be .NET. In many cases, it will be VB6.


    But the latter increasingly less relevant, as you implied above,
    because the language has been officially discontinued.

    >But in no case will VB.NET ever be VB6.


    Just like VB6 was never VB3, yet the two versions are very much closer
    together.

    MM

  12. #72
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 8 Oct 2002 17:33:20 -0700, "Jason" <jason@hotmail.com> wrote:

    >VB6
    >
    >String: Len(MyString)
    >Collection: MyCollection.Count
    >Array: UBound(MyArray) - LBound(MyArray) + 1
    > That is, only if array is initialized.


    >
    >Okay, now look at C#:
    >string: myString.Length
    >IList: myList.Length
    >Array: myArray.Length


    The VB6 three make perfect sense. Len is one of the Ancient Keywords.
    I don't want to change it. I have code that goes way back containing
    Len. I don't want to change it. Calling it .Length changes it; I don't
    want that. I want Len to remain. Forever.

    ..Count is not the same as .Length. So why call it the same for
    supposed consistency, yet thereby cause confusion? You don't say "What
    is the length of a class of students?" You say "What is the count?"
    ..Count is the number of items in a collection. It is not a length at
    all.

    UBound/LBound (Upper/Lower Bound) is exactly right when talking of
    arrays. If you accept that any array has an upper and lower bound,
    then it makes perfect sense to base your new keywords on them! Thus,
    colloquially one speaks of an array having an "upper bound" and
    programmatically one speaks of an array having a UBound, once again
    making B.A.S.I.C. as close to conversational English as possible.
    Arbitrarily redefining what a "bound" is by referring to it as a
    length is again introducing confusion. What you're advocating here is
    yet more homonyms! Most foreign-language students confronted with
    learning English complain about words like hear and here, yet you
    prefer to use .Length for three different meanings! Weird.

    >In VB6, every new feature got a new syntax, or at least a new function name
    >(VB doesn't support overloading) so nothing is the same. Nothing is consistent.
    > You don't think about this because you have been doing it so long it is
    >second nature to you, but it makes the language disjoint and is more difficult
    >for new programmers to learn.


    Well, three million VB programmers found it dead easy to learn, as
    well as countless others who learned other B.A.S.I.C.s before them.
    Maybe this was *because* of and not in spite of the different keywords
    that more closely defined their area of application. Of course, if the
    new language (e.g. VB.Net) is inherently much more complex, oopified
    even, then learning it will be a steeper curve for many who would have
    been inspired to learn traditional, proper B.A.S.I.C.

    >When you start to treat everything as an object (C# does this), it simplifies
    >the language, conceptually. Some objects can be compared. Some can be copied.
    > Some serialized. Some have a length.


    Fine for an OOP language. B.A.S.I.C. was never designed to be OOP.
    There were, and are, other languages that OOP purists can use. Leave
    B.A.S.I.C. alone! (Specifically, the classic Visual variety.)

    >All objects that can be compared can be treated the same way.
    >
    >All objects that can be serialized can be treated the same way.
    >
    >All objects that can be copied can be treated the same way.
    >
    >It is consistent throughout the language, and throughout the framework.


    Ditto.

    >For a programmer, it is like when you buy a new program for Windows, and
    >you open it up and start using it. It looks familiar to you, so you don't
    >have as steep a learning curve. The same thing happens when code libraries
    >have common designs.


    I used code libraries from various sources which obviously were not
    following a common design, and yet they were all totally
    comprehensible, easy to learn, powerful and value for money. Here are
    some examples: Crescent, Microhelp, Desaware. There were many others.

    >Once you learn part of the framework, other parts begin to look really familiar
    >to you. When you learn a little more, other parts seem to make sense. It
    >fits together and you can use it quickly, despite the fact that it is totally
    >different from VB6, which is what you are used to.
    >
    >Of course, Mike, you can just continue to be stubborn, and continue to say,
    >"I just don't understand..." or point out that Microsoft didn't sell 4 million
    >copies of .NET in the first month of release. Until you actually take the
    >time to study the software a bit, you won't understand.
    >
    >That is your choice. But quit asking silly questions when you haven't even
    >tried to answer them yourself.


    Well, I think I have answered them! And they're not silly!

    MM

  13. #73
    Jon Ogden Guest

    Re: Speaking of strings...


    What I find really silly is that, after all this time, you are writing the
    same rants you were in the spring of 2001. Indeed I suspect that you have
    most of your cries and whimpers boilerplated for easy insertion.

    Here's a clue, M.M.: you are so nineties. Figure it out.

    j


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On 8 Oct 2002 17:33:20 -0700, "Jason" <jason@hotmail.com> wrote:
    >
    >>VB6
    >>
    >>String: Len(MyString)
    >>Collection: MyCollection.Count
    >>Array: UBound(MyArray) - LBound(MyArray) + 1
    >> That is, only if array is initialized.

    >
    >>
    >>Okay, now look at C#:
    >>string: myString.Length
    >>IList: myList.Length
    >>Array: myArray.Length

    >
    >The VB6 three make perfect sense. Len is one of the Ancient Keywords.
    >I don't want to change it. I have code that goes way back containing
    >Len. I don't want to change it. Calling it .Length changes it; I don't
    >want that. I want Len to remain. Forever.
    >
    >..Count is not the same as .Length. So why call it the same for
    >supposed consistency, yet thereby cause confusion? You don't say "What
    >is the length of a class of students?" You say "What is the count?"
    >..Count is the number of items in a collection. It is not a length at
    >all.
    >
    >UBound/LBound (Upper/Lower Bound) is exactly right when talking of
    >arrays. If you accept that any array has an upper and lower bound,
    >then it makes perfect sense to base your new keywords on them! Thus,
    >colloquially one speaks of an array having an "upper bound" and
    >programmatically one speaks of an array having a UBound, once again
    >making B.A.S.I.C. as close to conversational English as possible.
    >Arbitrarily redefining what a "bound" is by referring to it as a
    >length is again introducing confusion. What you're advocating here is
    >yet more homonyms! Most foreign-language students confronted with
    >learning English complain about words like hear and here, yet you
    >prefer to use .Length for three different meanings! Weird.
    >
    >>In VB6, every new feature got a new syntax, or at least a new function

    name
    >>(VB doesn't support overloading) so nothing is the same. Nothing is consistent.
    >> You don't think about this because you have been doing it so long it is
    >>second nature to you, but it makes the language disjoint and is more difficult
    >>for new programmers to learn.

    >
    >Well, three million VB programmers found it dead easy to learn, as
    >well as countless others who learned other B.A.S.I.C.s before them.
    >Maybe this was *because* of and not in spite of the different keywords
    >that more closely defined their area of application. Of course, if the
    >new language (e.g. VB.Net) is inherently much more complex, oopified
    >even, then learning it will be a steeper curve for many who would have
    >been inspired to learn traditional, proper B.A.S.I.C.
    >
    >>When you start to treat everything as an object (C# does this), it simplifies
    >>the language, conceptually. Some objects can be compared. Some can be

    copied.
    >> Some serialized. Some have a length.

    >
    >Fine for an OOP language. B.A.S.I.C. was never designed to be OOP.
    >There were, and are, other languages that OOP purists can use. Leave
    >B.A.S.I.C. alone! (Specifically, the classic Visual variety.)
    >
    >>All objects that can be compared can be treated the same way.
    >>
    >>All objects that can be serialized can be treated the same way.
    >>
    >>All objects that can be copied can be treated the same way.
    >>
    >>It is consistent throughout the language, and throughout the framework.


    >
    >Ditto.
    >
    >>For a programmer, it is like when you buy a new program for Windows, and
    >>you open it up and start using it. It looks familiar to you, so you don't
    >>have as steep a learning curve. The same thing happens when code libraries
    >>have common designs.

    >
    >I used code libraries from various sources which obviously were not
    >following a common design, and yet they were all totally
    >comprehensible, easy to learn, powerful and value for money. Here are
    >some examples: Crescent, Microhelp, Desaware. There were many others.
    >
    >>Once you learn part of the framework, other parts begin to look really

    familiar
    >>to you. When you learn a little more, other parts seem to make sense.

    It
    >>fits together and you can use it quickly, despite the fact that it is totally
    >>different from VB6, which is what you are used to.
    >>
    >>Of course, Mike, you can just continue to be stubborn, and continue to

    say,
    >>"I just don't understand..." or point out that Microsoft didn't sell 4

    million
    >>copies of .NET in the first month of release. Until you actually take

    the
    >>time to study the software a bit, you won't understand.
    >>
    >>That is your choice. But quit asking silly questions when you haven't

    even
    >>tried to answer them yourself.

    >
    >Well, I think I have answered them! And they're not silly!
    >
    >MM



  14. #74
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Mark Hurd" <markhurd@ozemail.com.au> wrote
    >
    > Yes, but the built-in value types, and String, all implement IComparable too.
    >
    > >
    > > Since the parameter is an Object type, that apparently means that it has to
    > > be boxed.

    >
    > Yes -- I'm just noting the performance/memory usage issue of copying all these
    > values to the heap just to do one compare.
    >


    How often are you going to write your comparisons using the CompareTo method?

    Dim a, b As Long

    If a.CompareTo(b) Then
    MsgBox ">"
    End if

    Would you not rather write it:

    If a > b Then
    MsgBox ">"
    End if

    Note that when you implement IComparable on a structure, you do not get to
    use > but must make the call to CompareTo, that is how it is with the version I've
    got, anyway. Likewise the other types that support IComparable also have their
    CompareTo method.

    I'm thinking that interface is more for objects you create and store in an Array.
    When you then call the Sort method of that array, that process uses the
    CompareTo method to determine the proper order of the elements.

    LFS







  15. #75
    Paul Clement Guest

    Re: Speaking of strings...

    On Tue, 08 Oct 2002 21:33:30 +0100, Mike Mitchell <kylix_is@yahoo.co.uk> wrote:


    >If you're admitting that you have never consulted the documentation, then I guess you're simply
    >better than the rest of us. It refreshing to know that there's actually someone out there who has
    >memorized all the string functions and associated syntax.

    I certainly did memorise all the string functions and associated
    syntax! Don't forget that I have been programming in B.A.S.I.C. since
    1978. In over two decades one gets to confront most keywords at least
    once, and all the important ones thousands of times. It sticks like
    glue to a blanket (though what one would be doing with glue in the
    bed, beats me). However, yes, of course I consulted the documentation!
    Man, I have close on 300 computer books here! You think I'm not
    serious? Ha!

    Well then that's why Intellisense in invaluable and a byproduct of the String being a class.


    >BTW, since you apparently haven't really done any work with VB.NET then I guess you're really not
    >aware of the rather extensive list of String class operations, several of which accept several
    >different sets of parameters. But I guess that wouldn't concern you because I'm sure you could
    >remember every one of them. ;-)

    This is all very fine, but still doesn't get to the nub of my
    question, which was: why change strings to objects? If I can consult
    documentation about methods in VB.Net, I can equally as well consult
    documentation about functions in classic VB. Intellisense is only a
    memory jogger, not a replacement for online help.

    No one has claimed it is a replacement for online help, but without Intellisense you would very well
    need to consult the documentation if you weren't likely to recall all the functions and multiple
    syntax possibilities (which have been expanded in VB.NET).

    Your question concerning why the String is a class has been answered. It is a function of the
    architecture (last time).

    >
    >Well I know you're just a tad bit brighter than that Mike. If you can remember all those functions
    >and syntax as you imply, you just keep on typing. The Intellisense dropdown is only there if you
    >actually need to look through the list.

    Oh? Does it work differently now in VB.Net? Because in VB6 when I type
    the dot and Intellisense kicks in and I carry on typing as you
    suggest, the menu doesn't disappear - it stays there and my typing
    causes the focus to move to the word I've typed, e.g. Dim conn As
    ADODB.Connection. I find this behaviour irritiating and intrusive
    after the first few goes. Sure, when I want to find out about and use,
    say, PersistFormatEnum, the first few times I use that, it's going to
    be a bit hard to keep in mind, so Intellisense is great to begin with,
    but later turns into one of those night-nurses that keeps coming back
    and asking you whether you're okay and did you take your pills yet.
    YES, GODDAMMIT! NOW BUGGER OFF! (That was to the virtual night-nurse,
    not your very good self!)

    >Are you really trying to convince me that you get confused so easily or is this just a bunch of B.S.
    >I would for your sake that it's the latter.

    None of what I write is BS; neither do I get confused easily. Whether
    this is your problem, or mine, I dunno. You've confused me now.

    The only issue I see with Intellisense is if in mid-type you decide to change your mind and select
    from the drop down. This will slow you down if you already know what needs to be entered.

    BTW, in .NET you can turn off what they refer to as "statement completion with autolist members" (by
    language) if you find it intrusive. The IDE is very powerful with respect to configurability.

    But it's still an invaluable tool, especially, as you mentioned, when you're learning. And in .NET
    you need all the help you can get. ;-)


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center