Why no overloading in PHP5?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Chung Leong

    #16
    Re: Why no overloading in PHP5?

    [color=blue]
    >"Terje Slettebø" <tslettebo@hotm ail.com> wrote in message
    >news:110673440 6.359050.69950@ z14g2000cwz.goo glegroups.com.. .
    >Yes, that's one way, but then the class has to implement the
    >PrintInterface . If it doesn't, e.g. a third party class not
    >implementing that interface, then you can't use the above function.
    >Then you would need to modify it for each type. With only three cases,
    >as above, the code is reasonably clear. However, with many types,
    >unless you make some kind of uniform dispatch mechanism to other
    >functions, it can quickly grow into a rather large and messy
    >switch-case or if-else ladder.[/color]

    In the case of printing object, how else could you have implemented it? I
    mean if it's a third party class, you have no access to its properties and
    no idea how the data should be formatted.

    There aren't that many scalar types in PHP. About the only ones where the
    default type-conversion might be inadequate are boolean, null, and float. So
    six if clauses--hardly something to sweat about.


    Comment

    • Ashmodai

      #17
      Re: Why no overloading in PHP5?

      Terje Slettebø scribbled something along the lines of:[color=blue]
      > "Michael Fesser" <netizen@gmx.ne t> wrote in message
      > news:e6edv0dfab i0db38u0qqm0d4k uq3kb2tbm@4ax.c om...[color=green]
      >>In some cases you can solve such issues with interfaces.[/color]
      >
      >
      > Yes, for regular function calls. However, if you have a function like:
      >
      > function add($a, $b)
      > {
      > return $a + $b;
      > }
      >
      > then without operator overloading, this function simply can't work for
      > objects of user-defined types (classes).[/color]

      Yes, but PHP has only recently evolved into a (less or more) OOP
      language and was never meant to care about types.
      The entire problem of user-defined types only exists when you're using
      instances of classes (i.e. objects).

      Without classes PHP's approach works well. Once you're using classes,
      you need to be a bit more careful.

      The OCP may be a bit harmed by PHP's approach, but traditional function
      overloading would not work in PHP because of the way it treats types.

      I think in PHP it's better to think of classes as something different
      than types. An object is of type "object", so to say.
      It seems awfully wrong from the perspective of a C++ or Java programmer
      but we're not talking about C++ or Java anyway.

      Arrays are very different from those in C++ too so I don't see what your
      problem is.


      As for overloading in PHP, I think the name is descriptive and correct,
      but I can see why you were confused about its use.

      --
      Ashmo

      Comment

      • Terje Slettebø

        #18
        Re: Why no overloading in PHP5?

        Chung Leong wrote:[color=blue][color=green]
        > >"Terje Slettebø" <tslettebo@hotm ail.com> wrote in message
        > >news:110673440 6.359050.69950@ z14g2000cwz.goo glegroups.com.. .
        > >Yes, that's one way, but then the class has to implement the
        > >PrintInterface . If it doesn't, e.g. a third party class not
        > >implementing that interface, then you can't use the above function.
        > >Then you would need to modify it for each type. With only three[/color][/color]
        cases,[color=blue][color=green]
        > >as above, the code is reasonably clear. However, with many types,
        > >unless you make some kind of uniform dispatch mechanism to other
        > >functions, it can quickly grow into a rather large and messy
        > >switch-case or if-else ladder.[/color]
        >
        > In the case of printing object, how else could you have implemented[/color]
        it? I[color=blue]
        > mean if it's a third party class, you have no access to its[/color]
        properties and[color=blue]
        > no idea how the data should be formatted.[/color]

        With conventional overloading you wouldn't need a "dispatcher " object,
        and could simply provide an overloaded function:

        function printer(SomeTyp e $value)
        {
        // Print code here
        }

        Yes, you still need to know how to print it, to implement that
        function, but my point was about the dispatcher being a "dependency
        hog", which, unless you use something like the code in my posting, has
        to be modified for each new type added. There's no way to include just
        one simple function for the type you want to print.
        [color=blue]
        > There aren't that many scalar types in PHP. About the only ones where[/color]
        the[color=blue]
        > default type-conversion might be inadequate are boolean, null, and[/color]
        float. So[color=blue]
        > six if clauses--hardly something to sweat about.[/color]

        Sure, but my main concern was the user-defined types (also, printing is
        a bad example, since they have the toString() method, but it was just
        an example).

        Regards,

        Terje

        Comment

        Working...