me dijeron que en php la sobre carga y la sobre escritura no existen

[jor_0203]

me dijeron que en php la sobre carga y la sobre escritura no existen
eso es cierto o es falso, yo pensaba que si existía en php
y por favor si existe me podrían dar un ejemplo muy básico

[guardarmicorreo]

sobrecarga de php (con ejemplo)

https://php.net/manual/es/language.oop5.overloading.php

sobreescritura de php (con ejemplo muy sencillo)

http://www.phpya.com.ar/poo/temarios...o=13&inicio=12

[Italico76]

- No hay es "sobre-carga de operadores"

- No existe polimorfismo de metodos a nivel de parametros (numero y tipo) sin herencia

[jor_0203]

Iniciado por Italico76

- No hay es "sobre-carga de operadores"

- No existe polimorfismo de metodos a nivel de parametros (numero y tipo) sin herencia

disculpa me puedes dar un ejemplo ya que no comprendo muy bien
gracias

[Italico76]

@jor_0203 : dar ejemplos aca seria de otros lenguajes ya que PHP no tiene esas "features" pero intentemos.....

- Sobrecarga de operadores:

Código PHP:

  <?php
include "sobrecarga.php";

/*
   Multiplicaciones de vectores
*/

$a = [2,3,6];
$b = [1,8];

var_dump($a * $b);   

Suponiendo que en sobrecarga.php se hiciera la sobrecarga de operadores (de forma similar a como explican aca), en este caso el '*', el resultado seria poder multiplicar vectores, dando una matriz de 3x2


- Polimorfismo de metodos a nivel de parametros (numero y tipo) sin herencia:
(con esto quiero decir que no sean las clases descendientes las que implementan variaciones)

Código PHP:

<?php
 
Class Algo
{
 
    public function metodo ($param1,$param2)
    { // ... }
 
    public function metodo (int $param1)
    { // ... }
 
    public function metodo (string $param1, int $param2, array $param3)
    { // ... }
 
}
 

Notas que el metodo siempre se llama igual (metodo) ? bueno segun el numero de parametros y el tipo. cuando invocas a metodo() se mete en una "version" u otra de metodo()

En PHP no puedes ni en sueños hacer eso porque con parametros opcionales puedes hacer "algo" pero llegas a emular ese comportamiento y las interfaces de PHP son muyyy rigidas tambien.

Mira un ejemplo en JAVA para que veas no estoy "inventado":

Código Java:

class Overload
{
    void demo (int a)
    {
       System.out.println ("a: " + a);
    }
    void demo (int a, int b)
    {
       System.out.println ("a and b: " + a + "," + b);
    }
    double demo(double a) {
       System.out.println("double a: " + a);
       return a*a;
    }
}
class MethodOverloading
{
    public static void main (String args [])
    {
        Overload Obj = new Overload();
        double result;
        Obj .demo(10);
        Obj .demo(10, 20);
        result = Obj .demo(5.5);
        System.out.println("O/P : " + result);
    }
}
 

Nota que el numero de parametros y tipo son disntintos en demo() ... eso se resuelve en tiempo de "compilacion", pero en PHP por ahora se trabaja como interprete......asi que esas cosas son un poco dificiles de lograr

[guardarmicorreo]

Buenos apuntes Italico76.

Sobre la sobrecarga de metodos solo se me ocurrió algo parecido a lo siguiente, que se basa en trasladar esa dinamicidad al lado externo de la clase.

Código PHP:

class Encuentro{
    
    private function __construct() {
        return new Encuentro();
    }
    
    function hola(){
        echo "hola<br>";
    }
    
    function ponencia(){
        echo "que tal<br>";
    }
    
    function adios(){
            echo "adios<br>";
    }
}
 
$method="hola";
 
Encuentro::$method();
 
$method="ponencia";
 
Encuentro::$method();
 
$method="adios";
 
Encuentro::$method();
 

Es decir, llamada dinámica a los metodos desde fuera de la clase, ahora quedaría el asunto de los parámetros de forma variable.

Un saludo.

[dashtrash]

Iniciado por Italico76

Nota que el numero de parametros y tipo son disntintos en demo() ... eso se resuelve en tiempo de "compilacion", pero en PHP por ahora se trabaja como interprete......asi que esas cosas son un poco dificiles de lograr

El problema no es que PHP trabaje como interprete.El problema es que PHP es no tipado, por lo que, basicamente, todas las signatures de metodos con 2 parametros y mismo nombre..es la misma.
El Type-hinting ayuda a los editores de texto, pero no sé (no creo) que esté implementado en el motor.

[jor_0203]

Iniciado por dashtrash

El problema no es que PHP trabaje como interprete.El problema es que PHP es no tipado, por lo que, basicamente, todas las signatures de metodos con 2 parametros y mismo nombre..es la misma.
El Type-hinting ayuda a los editores de texto, pero no sé (no creo) que esté implementado en el motor.

y tu que piensas de lo que dice Italico76
estas totalmente de acuerdo

[Italico76]

Iniciado por jor_0203

y tu que piensas de lo que dice Italico76
estas totalmente de acuerdo

Logicamente @dashtrash con razon no esta de acuerdo en la argumentacion de porque no esta implementada la segunda caracteristica (polimorfismo sin herencia). Y tiene razon!

Finalmente aclarar que PHP si implementa "method overriding" (sobre-escritura) pero no "method overloading" que es lo que mencioné en segundo lugar; puedes leer mas aqui

[dashtrash]

Iniciado por jor_0203

y tu que piensas de lo que dice Italico76
estas totalmente de acuerdo

Lo que dice Italico76 es, en general, cierto.Mi pega no era sobre "el qué", sino "el por qué"
Lo que ocurre es que el propio manual de PHP llama "sobrecarga" a cosas que no lo son, pero se pueden utilizar para simularla.
En el link que daba @guardarmicorreo, https://php.net/manual/es/language.oop5.overloading.php, se llama "overload" a algo que no lo es (como también opina el primer comentario de usuarios que hay en esa página). Los métodos mágicos te permiten simularlo:

Código PHP:

class A
{
     function __call($func,$args)
     {
 
             $n=count($args);
             call_user_func_array(array($this, $func."_".$n), $args);
      }
      private function overloaded_0()
      {
               echo "No args";
      }
      private function overloaded_1($arg1)
      {
               echo "One arg";
      }
      private function overloaded_2($arg1,$arg2)
      {
               echo "Two args";
      }
}
$c=new A();
$c->overloaded(); // "No args"
$c->overloaded(1); // "One arg"
$c->overloaded(1,2); // "Two args"
 

De la misma forma se puede hacer con tipos de dato:

Código PHP:

class A
{
     function __call($func,$args)
     {
             $n=count($args);
             if($n>0)
             {
                    $func=$func."_".implode("_",array_map("gettype",$args));
             }
             call_user_func_array(array($this, $func), $args);
      }
      private function overloaded()
      {
              echo "No args";
       }
      private function overloaded_integer($i)
      {
               echo "Received integer";
      }
      private function overloaded_boolean_array($b,$a)
      {
               echo "Received boolean and array";
      }
      private function overloaded_object_double($o,$d)
      {
               echo "Received object and double";
      }
}
$c=new A();
$c->overloaded(); // No args
$c->overloaded(1); // Received integer
$c->overloaded(false,array(1,2,3)); // Received boolean and array
$c->overloaded(new A(),1.5); // Received object and double
 

Significa esto que PHP soporta polimorfismo? No, significa que ese código simula polimorfismo.

[Italico76]

@dashtrash : wow .. pedazo de ejemplos!


Siempre me quedo con una frase que he leido por ahi: "PHP hace lo Facil, muy facil y lo Dificil mucho mas dificil" xD

[jor_0203]

Iniciado por Italico76

@dashtrash : wow .. pedazo de ejemplos!


Siempre me quedo con una frase que he leido por ahi: "PHP hace lo Facil, muy facil y lo Dificil mucho mas dificil" xD

eres un genio

[jor_0203]

Iniciado por dashtrash

Lo que dice Italico76 es, en general, cierto.Mi pega no era sobre "el qué", sino "el por qué"
Lo que ocurre es que el propio manual de PHP llama "sobrecarga" a cosas que no lo son, pero se pueden utilizar para simularla.
En el link que daba @guardarmicorreo, https://php.net/manual/es/language.oop5.overloading.php, se llama "overload" a algo que no lo es (como también opina el primer comentario de usuarios que hay en esa página). Los métodos mágicos te permiten simularlo:

Código PHP:

class A
{
     function __call($func,$args)
     {
 
             $n=count($args);
             call_user_func_array(array($this, $func."_".$n), $args);
      }
      private function overloaded_0()
      {
               echo "No args";
      }
      private function overloaded_1($arg1)
      {
               echo "One arg";
      }
      private function overloaded_2($arg1,$arg2)
      {
               echo "Two args";
      }
}
$c=new A();
$c->overloaded(); // "No args"
$c->overloaded(1); // "One arg"
$c->overloaded(1,2); // "Two args"
 

De la misma forma se puede hacer con tipos de dato:

Código PHP:

class A
{
     function __call($func,$args)
     {
             $n=count($args);
             if($n>0)
             {
                    $func=$func."_".implode("_",array_map("gettype",$args));
             }
             call_user_func_array(array($this, $func), $args);
      }
      private function overloaded()
      {
              echo "No args";
       }
      private function overloaded_integer($i)
      {
               echo "Received integer";
      }
      private function overloaded_boolean_array($b,$a)
      {
               echo "Received boolean and array";
      }
      private function overloaded_object_double($o,$d)
      {
               echo "Received object and double";
      }
}
$c=new A();
$c->overloaded(); // No args
$c->overloaded(1); // Received integer
$c->overloaded(false,array(1,2,3)); // Received boolean and array
$c->overloaded(new A(),1.5); // Received object and double
 

Significa esto que PHP soporta polimorfismo? No, significa que ese código simula polimorfismo.

me podrias esplicar esto que dijiste
Significa esto que PHP soporta polimorfismo? No, significa que ese código simula polimorfismo
no entiendo bien el polimorfismo de java y el de php, que vez que yo no alcanzo a ver

[lolainas]

Este tema ya se trató en alguna ocasión
http://www.forosdelweb.com/f18/aport...imple-1093873/

[jor_0203]

Iniciado por lolainas

Este tema ya se trató en alguna ocasión
http://www.forosdelweb.com/f18/aport...imple-1093873/

gracias buen aporte
estoy leyendo

[dashtrash]

Iniciado por lolainas

Este tema ya se trató en alguna ocasión
http://www.forosdelweb.com/f18/aport...imple-1093873/

No había visto eso...
La primera solución es igual a la que propuse más arriba , con el añadido del chequeo de clases, y la complicación de no usar __call, pero funciona.
Sin embargo, si se quiere hacer una solución "completa" (ya que está marcado como "aporte"), debería gestionar clases derivadas.No es suficiente con llamar a get_class para hacer matching de clases.Si B extiende de A , un metodo que está declarado como que recibe un parametro de tipo A , debería poder recibir un parametro de tipo B (uso de get_parent_class tantas veces como sea necesario).
Gestionar namespaces también sería un bonito añadido.Y métodos estáticos.

La segunda solución, usando Reflection, es innecesariamente complicada (una clase abstracta sin métodos abstractos??), y no funciona.Utilizar los nombres de parámetros como discriminador, significa que no puedes declarar una función que reciba 2 parametros del mismo tipo ($array,$array).
Utilizar Reflection sólo sería necesario para una cosa: permitir parámetros con valores por defecto.Una funcion con signature a_integer_integer_integer($a,$b,$c=null), podria ser invocada
aunque sólo se llamara con a(1,1).

La tercera solución, aún más complicada, vuelve a no funcionar por el mismo motivo anterior, aparte de que hacer varias expresiones regulares en __call..Al menos, eso debería cachearse en el constructor, y no chequearlo en cada llamada.

Todas las soluciones utilizan innecesariamente el numero de argumentos como parte del nombre del método, cuando la coincidencia del numero de argumentos está implícito en el chequeo de tipos.

Es un post interesante, porque muestra el peligro de hacer sobre-ingeniería de las cosas.La primera solución era simple y básicamente correcta, sólo faltaba el conveniente detalle de __call y el retorno de valores.El resto de cosas a añadir para una solución completa, se podría hacer de forma igualmente simple.

[jor_0203]

Iniciado por dashtrash

No había visto eso...
La primera solución es igual a la que propuse más arriba , con el añadido del chequeo de clases, y la complicación de no usar __call, pero funciona.
Sin embargo, si se quiere hacer una solución "completa" (ya que está marcado como "aporte"), debería gestionar clases derivadas.No es suficiente con llamar a get_class para hacer matching de clases.Si B extiende de A , un metodo que está declarado como que recibe un parametro de tipo A , debería poder recibir un parametro de tipo B (uso de get_parent_class tantas veces como sea necesario).
Gestionar namespaces también sería un bonito añadido.Y métodos estáticos.

La segunda solución, usando Reflection, es innecesariamente complicada (una clase abstracta sin métodos abstractos??), y no funciona.Utilizar los nombres de parámetros como discriminador, significa que no puedes declarar una función que reciba 2 parametros del mismo tipo ($array,$array).
Utilizar Reflection sólo sería necesario para una cosa: permitir parámetros con valores por defecto.Una funcion con signature a_integer_integer_integer($a,$b,$c=null), podria ser invocada
aunque sólo se llamara con a(1,1).

La tercera solución, aún más complicada, vuelve a no funcionar por el mismo motivo anterior, aparte de que hacer varias expresiones regulares en __call..Al menos, eso debería cachearse en el constructor, y no chequearlo en cada llamada.

Todas las soluciones utilizan innecesariamente el numero de argumentos como parte del nombre del método, cuando la coincidencia del numero de argumentos está implícito en el chequeo de tipos.

Es un post interesante, porque muestra el peligro de hacer sobre-ingeniería de las cosas.La primera solución era simple y básicamente correcta, sólo faltaba el conveniente detalle de __call y el retorno de valores.El resto de cosas a añadir para una solución completa, se podría hacer de forma igualmente simple.

una pregunta tu a que le llamas peligro de hacer sobre-ingeniería de las cosas
porque es un peligro

[dashtrash]

Iniciado por jor_0203

una pregunta tu a que le llamas peligro de hacer sobre-ingeniería de las cosas
porque es un peligro

Aplicando KISS: Hay que aplicar KISS (Keep It Simple, Stupid).

Resumo la lista de cosas que faltan en las implementaciones:
- Soporte de clases derivadas en métodos con argumentos de clases base, interfaces o traits.
- Soporte de métodos con 2 parámetros del mismo tipo
- Soporte de clases dentro namespaces
- Soporte de métodos estáticos.
Sin embargo, se intenta poner cuidado en otras cosas puramente estilísticas, y (como es muy habitual), discutiblemente aplicadas: declarar la clase Overridable como abstracta, para que no se puedan crear instancias (eso no es una clase abstracta, es una clase con constructor protected), o lanzar una ReflectionException (cuando en este caso, cualquiera entendería mejor el mensaje "function 'xxx.xxx.xxx' not found" que una "ReflectionException", aparte de que no es un error que un programa deba gestionar vía catch()).

El foco pasa del "qué", al "como",y eso es una cosa a evitar siempre.

[jor_0203]

Iniciado por dashtrash

Aplicando KISS: Hay que aplicar KISS (Keep It Simple, Stupid).

Resumo la lista de cosas que faltan en las implementaciones:
- Soporte de clases derivadas en métodos con argumentos de clases base, interfaces o traits.
- Soporte de métodos con 2 parámetros del mismo tipo
- Soporte de clases dentro namespaces
- Soporte de métodos estáticos.
Sin embargo, se intenta poner cuidado en otras cosas puramente estilísticas, y (como es muy habitual), discutiblemente aplicadas: declarar la clase Overridable como abstracta, para que no se puedan crear instancias (eso no es una clase abstracta, es una clase con constructor protected), o lanzar una ReflectionException (cuando en este caso, cualquiera entendería mejor el mensaje "function 'xxx.xxx.xxx' not found" que una "ReflectionException", aparte de que no es un error que un programa deba gestionar vía catch()).

El foco pasa del "qué", al "como",y eso es una cosa a evitar siempre.

lo que eres tu y Italico76 son geniales
ojala con estudio pueda alcanzarlos algún día

[Italico76]

Iniciado por jor_0203

lo que eres tu y Italico76 son geniales
ojala con estudio pueda alcanzarlos algún día

Me da pena me pongas en la misma sentencia con @dashtrash : él es un programador profesional verdaderamente experimentado y yo apenas un eterno aprendiz

Por cierto tambien admiro a dashtrash

[NSD]

Iniciado por dashtrash

Aplicando KISS: Hay que aplicar KISS (Keep It Simple, Stupid).

Resumo la lista de cosas que faltan en las implementaciones:
- Soporte de clases derivadas en métodos con argumentos de clases base, interfaces o traits.
- Soporte de métodos con 2 parámetros del mismo tipo
- Soporte de clases dentro namespaces
- Soporte de métodos estáticos.
Sin embargo, se intenta poner cuidado en otras cosas puramente estilísticas, y (como es muy habitual), discutiblemente aplicadas: declarar la clase Overridable como abstracta, para que no se puedan crear instancias (eso no es una clase abstracta, es una clase con constructor protected), o lanzar una ReflectionException (cuando en este caso, cualquiera entendería mejor el mensaje "function 'xxx.xxx.xxx' not found" que una "ReflectionException", aparte de que no es un error que un programa deba gestionar vía catch()).

El foco pasa del "qué", al "como",y eso es una cosa a evitar siempre.

hola, dashtrash, aprecio tus criticas, serias tan amable de pasar nuevamente por el post y ver la version que acabo de publicar? contempla todo lo que vos sugeriste y tambien lo que menciono hhs me gustaria si es posible que des una nueva opinion de la ultima version. no publico nada aca para no intrometerme en este tema mas de lo indispensable. gracias.