Announcement

Collapse
No announcement yet.

Oop 101?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    >that will accept any numeric variable.

    Not BYVAL it wont... the number of bytes on the stack is different. However, the PB compiler will do a silent conversion if called with a different datatype parameter so it will "work."

    For functions requiring an integer parameter (eg "isPrime") conversion to EXT is not a problem, but for a 'general purpose' function accepting floats you might be introducing rounding errors.

    I use CUR a lot because there are no rounding issues, at least in the number range in which I work, which is integer or maybe two decimal quantities and price/extension in dollars.
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #42
      It was just an example to show that there are other ways. COM classes don't support overloading. To simulate it, the compiler will have to create additional methods under the hood, IsPrime2, IsPrime3, etc., and determine which one to call.
      Forum: http://www.jose.it-berater.org/smfforum/index.php

      Comment


      • #43
        Not to keep picking on this, but nobody has yet to answer my primary question about OOP. Take your "large project". What if each programmer were give the same requirements. Could they not have just as easily compiled their section into a DLL and said "here, these are the parameters you pass to this specific function to get your return value." And, as for the example of creating a pool of database connections, could not the same program been done with procedural code as well? What does OOP have to do with the design of the solution here?
        Of course you can do the job procedurally.

        Joe, I've been involved with this issue for about 25 years as a developer, consultant and manager.

        In most cases of development conflicts ("Joe's code is stepping on Sally's code which is stepping on Jummy's code....") the simple answer is, management failure.

        The sad part is there is no good reason for these failures, other than managers cannot plan the work correctly because they do not understand how applications software works.

        And even it they don't understand it well enough to do this planning themself, how hard can it be to go to your 'lead' programming people to ask for a little help? All the manager really has to do is ask the question: "Will doing it this way result in Joe's code stepping on Sally's code?"

        Now I *have* seen cases where a new development tool (e.g a 'shiny new OOP-style compiler') is used by managers as the "excuse" for enforcing discipline, but for crying out loud, shouldn't the manager have been enforcing some kind of discipline all along?

        Shortsightedness and failure to invest in thinking about projects like this before commiting the resources is why we end up with $30 million taxpayer bucks totally written off on three separate State of Wisconsin software projects in the past five years.

        I'm not one to automatically blame management, but in this case there simply is no other explanation. Poor management is poor management is poor management.

        MCM
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #44
          And I forgot this:
          I can hear people complaining that they don't want a dozen+ DLL files. Ok, I can appreciate that
          As a manager, I can't. If you - an allegedly professional Windows' programmer - can't deal dynamic link libraries, you have already exceeded your theoretical "Peter Principle Peak Performance" and I'll be by to see you at your new job next week where I *will* have fries with that, thank you very much for asking.

          As programmer, well, that's not my call, is it? So maybe I should just go back to my cubicle and do my job to the best of my ability.
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #45
            And in an utterly shameless display of promotion for my own line of work.....

            This is why bringing in outside consultants from time to time is a really good idea. It exposes your people - not just the programmers, but the managers as well - to new ideas and new thinking.

            The other source for new ideas? I personally like dealing with 'rookies' fresh out of programming school.

            Since they don't know "we always do it this way" they simply "do it a different way."

            Since they don't know "what can't be done" they just do it anyway.

            And since they have not yet mastered the fine art of butt-covering when asked a pointed question, they simply tell you the truth.
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment

            Working...
            X