17 respuestas en este tema

[Delphius]

Buenas, tengo una duda curiosa...

 

No estoy muy familiarizado con estas nuevas características helpers y me asalta la duda. Trato de leer sobre el tema, y se que es posible hacer un record helper para un enumerativo, y gracias a éste implementar un método como ToString() o ToChar() para tener una representación "texto" del tipo en cuestión:

delphi

TMiEnum = (meUno, meDos, ....);
 
TMiEnumHelper = record Helper for TMiEnum
  function ToChar: char;
end;
 
function TMiEnumHelper.Tochar: char
begin
  case Self of
    meUno: result := 'U';
    meDos: result := 'D';
    // ...
end;

Entonces con esto es posible esta gracia:

delphi

procedure MostrarTextoEnum;
var MiEnum: TMiEnum;
begin
  MiEnum := meUno;
  ShowMessage(MiEnum.ToChar);
end;

Ahora bien. Si yo quisiera (y necesitara) hacer lo inverso, ¿Es posible? Es decir, dado un carácter, texto, o un número entero si se quiere, ¿Es posible obtener el tipo enumerativo correspondiente? ¿O necesariamente debe recurrirse a la vieja escuela?

 

No se, imaginaba algo como esto:

delphi

MiEnum := TMiEnumHelper.ToEnum('U');

Pero como que parece algo raro... no encuentro una bibliografía que me aclare dudas. De si es "legal" esta vía o no.

 

Esto me lo pregunto porque justamente tengo unos tipos enumerativos y guardo en la base de datos una versión numerica o char de los mismos. Al momento de recuperar este valor me resultaría de interés materializar el tipo enumerativo.

Y justamente la idea es que ya que existen los helper pues... evitarme una función CharToEnum "suelta" a la vieja escuela.

 

Saludos,

 

 

[enecumene]

¿y no te sirve usar la Función toString() directamente?, no sé, algo como esto:

delphi

TMiEnum = (meUno, meDos, ....);
 
    TMiEnumHelper = record Helper for TMiEnum
      function ToChar: char;
      function ToString: String;
    end;
 
    function TMiEnumHelper.Tochar: char
    begin
      case Self of
        meUno: result := 'U';
        meDos: result := 'D';
        // ...
    end;
 
    function TMiEnumHelper.ToString: String;
    begin
       Result := ToString(Self);
    end;

Saludos.

[Delphius]

Pues para el primer paso quizá... tendré que ir probando. Lo que me interesa realmente es lo inverso.

Lo curioso es que aparentemente Lazarus no soporta helper sobre el enumerativo

 

Me arroja el error "Error record type expected".

Al menos eso da a entender... que se espera un record y no un enumerativo.

Se que con Delphi XE3+ es posible hacer esto sobre enumativos.Y encima hay que habilitar el modo:

delphi

{$ModeSwitch advancedrecords}

Para que compile.

 

Saludos,

[enecumene]

¿Has intentado lo siguiente?, digo, no lo he probado pero puede funcionar:

delphi

function TMiEnumHelper.ToEnum: TMiEnum;
    var c: char;
    begin
 
      c := char(Self);
      case c of
        'U': result := meUno;
        'D': result := meDos;
        // ...
    end;

Saludos.

[Delphius]

Recién vuelvo de cenar.

No lo he probado, pero el error me advierte ya de entrada en que no acepta el enumerativo en su declaración, asi que no tendría sentido ni intentarlo.

 

La opción que si me deja es utilizar una indirección, es decir: definir un record y que tenga como campo el tipo enumerativo.

 

Entonces probé esto:

delphi

unit Unit1;
 
{$mode objfpc}{$H+}
{$ModeSwitch advancedrecords}
 
interface
 
uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;
 
type
  TMiEnum = (meUno, meDos, meTres);
  TMiRec = record
    Value: TMiEnum;
  end;
 
  { TMiRecHelper }
 
  TMiRecHelper = record helper for TMiRec
    function Tochar: char;
    function ToEnum(Value: char): TMiRec;
  end;
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
var r: TMiRec;
begin
  r.Value := meUno;
  ShowMessage(r.Tochar);
end;
 
procedure TForm1.Button2Click(Sender: TObject);
var r: TmiRec;
begin
  r := TMiRecHelper.ToEnum('2');
  ShowMessage(r.Tochar);
end;
 
{ TMiRecHelper }
 
function TMiRecHelper.ToChar: char;
begin
  case self.Value of
    meUno: result := '1';
    meDos: result := '2';
    meTres: result := '3';
  end;
end;
 
function TMiRecHelper.ToEnum(Value: char): TMiRec;
var r: TMiRec;
begin
  case Value of
    '1': r.Value := meUno;
    '2': r.Value := meDos;
    '3': r.Value := meTres;
  end;
  result := r;
end;
 
end.

Y efectivamente ahora si no se queja del record esperado. El problema se traduce en que la expresión inversa inventada:

delphi

r := TMiRecHelper.ToEnum('2');

Es ilegal. El error concreto es: "unit1.pas(56,20) Error: Objective-C categories and Object Pascal class helpers cannot be used as types"

 

Si lograse hacerlo andar con records helpers, me parece un camino un tanto engorroso. Si ya se está por emplear una vía indirecta, ese tipo record; para tal caso me evito el helper y hago mi propia función EnumToChar y CharToEnum de toda la vida. Si soportara el enumerativo bueno la podría pelear para buscar el proceso inverso.

Me siento un tanto decepcionado porque pensé que por fin podría hacer uso de las cosas nuevas que trae Object Pascal. Me bajó un poco los ánimos.

 

Saludos,

[Agustin Ortu]

Usa una funcion de clase

Pero antes, hay otro "truco" para que funcione en Lazarus
 
No podes implementar un record helper sobre un enumerativo como en Delphi
 
Tenes que usar un type helper
 
La verdad que en el area de helpers FPC es mil veces mejor a Delphi (lo mas notable es que soporta herencia)
 
---
 
El truco para que ande es el siguiente:

delphi

{$ModeSwitch typehelpers}

Luego declaramos el Enumerativo y el Type Helper

delphi

type
  TEnum = (enUno, enDos);
 
  { TEnumHelper }
 
  TEnumHelper = type helper for TEnum
  public
    class function Parse(const Value: string): TEnum; overload; static;
    class function Parse(const Value: Integer): TEnum; overload; static;
 
    function ToInteger: Integer;
    class function ToString(const Value: TEnum): string; overload; static;
    function ToString: string; overload;
  end;

La implementacion es trivial..

delphi

{ TEnumHelper }
 
class function TEnumHelper.Parse(const Value: string): TEnum;
var
  I: TEnum;
begin
  for I := Low(TEnum) to High(TEnum) do
  begin
    if I.ToString = Value then
      Exit(I);
  end;
 
  raise Exception.CreateFmt('TEnumHelper.Parse (string) Value %s', [Value]);
end;
 
class function TEnumHelper.Parse(const Value: Integer): TEnum;
var
  I: TEnum;
begin
  for I := Low(TEnum) to High(TEnum) do
  begin
    if I.ToInteger = Value then
      Exit(I);
  end;
 
  raise Exception.CreateFmt('TEnumHelper.Parse (Integer) Value %d', [Value]);
end;
 
function TEnumHelper.ToInteger: Integer;
begin
  Result := Ord(Self);
end;
 
class function TEnumHelper.ToString(const Value: TEnum): string;
begin
  case Value of
    enUno: Result := 'Uno';
    enDos: Result := 'Dos';
  else
    raise Exception.CreateFmt('TEnumHelper.ToString Value %d', [Ord(Value)]);
  end;
end;
 
function TEnumHelper.ToString: string;
begin
  Result := ToString(Self);
end;

Ejemplo de uso:

delphi

procedure TForm1.BitBtn1Click(Sender: TObject);
var
  Enum: TEnum;
begin
  Enum := TEnum.Parse(Edit1.Text);
  ShowMessage(Enum.ToString);
end;

Editado por Agustin Ortu, 10 mayo 2016 - 09:25 .

[Agustin Ortu]

Otra cosa, no hay que usar la clase helper para invocar los metodos estaticos.
 
En Delphi es problematico porque en la ventana de autocompletado de codigo te sale asi:
 

delphi

TEnumHelper.Parse
  TEnumHelper.ToString
  TEnumHelper. ...

Osea, sale como si fuera una "posible" sintaxis valida, pero resulta que despues no compila

 

Lo valido (y no que no sale en ese cuadro, para colmo ) es como puse en el ejemplo de arriba: TEnum.Parse

 

Osea el Helper extiende al tipo original, en un determinado scope 

 

Se puede interpretar como una suerte de "auto decorator" si se quiere

 

Cuando se trata de primitivos o enumerativos, te permite (como he dicho en otros post) cierta "syntaxis sugar", esa sintaxis fluida que parece que estas invocando metodos de un objeto pero es un simple enumerativo

Editado por Agustin Ortu, 10 mayo 2016 - 09:10 .

[Delphius]

Muchas gracias Agustín. Mañana lo pruebo.

Tengo el cerebro por demás quemado hace un buen rato y dejé de investigarlo. Demasiado código tuve el día de hoy... algo me dice que esta semana será larga.

 

Saludos,

[Delphius]

Interesante forma de encararlo Agustin.

He probado una versión alternativa, que prescinde de las funciones Parse() que tu tienes.

 

Básicamente se resume a algo como esto:

delphi

unit Unit1;
 
{$mode objfpc}{$H+}
{$ModeSwitch typehelpers}
 
interface
 
uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;
 
type
  TMiEnum = (meUno, meDos, meTres);
 
  { TMiEnumHelper }
 
  TMiEnumHelper = type helper for TMienum
  public
    class function ToChar(const AEnumValue: TMiEnum): Char; static;
    class function ToEnum(const ACharValue: char): TMiEnum; static;
  end;
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
var e: TMiEnum;
begin
  e := meUno;
  ShowMessage(TMiEnum.ToChar(e));
end;
 
procedure TForm1.Button2Click(Sender: TObject);
var e: TMiEnum;
begin
  e := TMiEnum.ToEnum('D');
  ShowMessage(e.ToChar(e));
end;
 
{ TMiEnumHelper }
 
class function TMiEnumHelper.ToChar(const AEnumValue: TMiEnum): Char;
begin
  case AEnumValue of
    meUno:  result := 'U';
    meDos:  result := 'D';
    meTres: result := 'T';
  end;
end;
 
class function TMiEnumHelper.ToEnum(const ACharValue: char): TMiEnum;
begin
  case ACharValue of
    'U': result := meUno;
    'D': result := meDos;
    'T': result := meTres;
  end;
end;
 
end.

El ejemplo es muy sencillo. Pero ilustra que de una u otra forma se necesita, terminar pasando como parámetro el enumerativo para que se pueda efectuar la "conversión" al tipo char o string. Ya sea que se haga de forma implícita (o indirecta) como en tu caso, o bien explícitamente como en el mio.

No es posible hacer esto:

delphi

class function ToChar: Char; static;
begin
  case Self of
    meUno: result := 'U';
    ...
  end;
end;

Necesariamente deberá pasarse como parámetro y es básicamente lo que termina haciendo tu implementación de ToString sobrecargada.

 

Para el botón 1, también se puede hacer esto:

delphi

ShowMessage(e.ToChar(e));

Lo que ilustra un buen sin sentido.

 

La posible ventaja que tendríamos con este helper es que directamente podemos tener en el un buen abanico de implementaciones interesantes que hagan juego... casi como una clase más. Aunque para estar pasando parámetros y tener que de una u otra forma termine de hacer un TMiEnum.Algo() me hace cuestionar su sentido.

 

¿Que diferencia hay que tenga ahora un juego de funciones de conversión de uno y otro sentido "sueltas" o en una clase propia (por darle un nombre TEnumConverter) y tener el helper? Basicamente es lo mismo:

 

MiConverter.ToChar(mivarEnum);

 

que esto:

 

TMiEnum.ToChar(mivarEnum);

 

Parece que al menos, en los enumerativos, no supone demasiada ganancia esta nueva característica.

 

Saludos,

[Agustin Ortu]

Se puede hacer sin el parámetro, usando Self

Yo te mostré como lo uso yo porque me gusta tener las dos versiones, la estática y el método

no tengo pc a mano ahora para probarlo, en Delphi se puede

En el peor de los casos lo pones como private y listo

[Delphius]

Con el class function static no es posible hacer el case sobre el self de forma directa. Da error. Para solucionarlo debe pasarse como parámetro.

Es decir, si uno tiene pensado emplear class function, éstos requieren que sea estáticos, y a su vez provoca que no sepa interpretar el Self sobre el enumerativo. Debe recurrirse a ese "hack" que se ve en mi código:

 

case AEnumValue of ...

 

Para lograr que sea más "Self-pure-friendly" hay que prescindir del class y static. Lo siguiente compila sin problemas:

delphi

unit Unit1;
 
{$mode objfpc}{$H+}
{$ModeSwitch typehelpers}
 
interface
 
uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;
 
type
  TMiEnum = (meUno, meDos, meTres);
 
  { TMiEnumHelper }
 
  TMiEnumHelper = type helper for TMienum
  public
    function ToChar: Char;
    function ToEnum(AValue: char): TMiEnum;
  end;
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TMiEnumHelper }
 
function TMiEnumHelper.ToChar: Char;
begin
  case self of
    meUno: result := 'U';
    meDos: result := 'D';
    meTres: result := 'T';
  end;
end;
 
function TMiEnumHelper.ToEnum(AValue: char): TMiEnum;
begin
  case AValue of
    'U': result := meUno;
    'D': result := meDos;
    'T': result := meTres;
  end;
end;
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
var e: TMiEnum;
begin
  e := meUno;
  ShowMessage(e.ToChar);
end;
 
procedure TForm1.Button2Click(Sender: TObject);
var e: TMiEnum;
begin
 e := TMiEnum.ToEnum('D');
 ShowMessage(e.ToChar);
end;
 
{ TMiEnumHelper }
 
 
 
end.

Que implicancias o desventajas cabría de esperarse en no usar los estáticos ni métodos de clase... no he analizado todavía. Pero al menos de esta forma en la única vía en que hay menos indirección.

 

Saludos,

[Agustin Ortu]

 

Con el class function static no es posible hacer el case sobre el self de forma directa. Da error. Para solucionarlo debe pasarse como parámetro.

Es decir, si uno tiene pensado emplear class function, éstos requieren que sea estáticos, y a su vez provoca que no sepa interpretar el Self sobre el enumerativo. Debe recurrirse a ese "hack" que se ve en mi código:

 

A eso mismo me referia (desde el telefono a veces me dan menos ganas de escribir )

 

 

 

Que implicancias o desventajas cabría de esperarse en no usar los estáticos ni métodos de clase... no he analizado todavía. Pero al menos de esta forma en la única vía en que hay menos indirección.

 

No entiendo exactamente a que queres llegar (menos indireccion). Si te referis a eficiencia de ultima los podes declarar como inline. Los helper de Delphi, por ejemplo el de Integer, el metodo ToString lo define como inline e invoca a IntToStr(Self)

 

Yo siempre implemento las dos versiones, la estatica y la "normal" (como se le dice a este tipo de metodos?? laguna mental!!) por una cuestion de comodidad

 

La gran ventaja de hacerlo de esta manera y no como la vieja escuela es el scope (alcance) que queda mas limitado, y eso es siempre bueno

 

A la vieja escuela es tener funciones declaradas asi..

 

delphi

function StrToEnum(const Value: string): TEnum;
  function StrToEstadoCivil(const Value: string): TEstadoCivil;
 
  function EnumToStr(const Value: TEnum): string;
  function EstadoCivilToStr(const Value: TEstadoCivil): string; 

Estas tipeando codigo y para en la ventanita de sugerencias se te despliegan dos opciones

 

Las StrToXXX se "chocan" con todo! StrToInt, StrToFloat.. si le podes poner otro nombre, es cierto. 

 

De esta forma te queda:

 

delphi

TEstadoCivil.[Parse/ToString/ToInteger/etc..]

Ponele que sea TextoToEnum, pero es lo mismo, te salen todos los TextoTo.. y tenes que elegir la adecuada. Parece tonto pero a mi me resulto muy util los type helper. Hoy los implemento para absolutamente todos los enumerativos

 

Tambien tengo metodos asi:

delphi

TEstadoCivilHelper = type helper for TEstadoCivil
  public
    class function GetItems: TStrings; static; // devuelve un TStrings con todos los TEstadoCivil.ToStr
    class procedure AssignItems(AStrings: TSTrings); static; // Asigna GetItems al parametro AStrings
  end; 

Esos metodos los uso para asignar por ejemplo los estados civiles a un TComboBox

 

Ademas, siempre tengo la esperanza de que implementen herencia y/o genericos

 

Si los de FPC pudieron quiere decir que los de Embarcaderos son vagos! Osea yo quiero declarar un helper generico para los enumerativos y redefinir ToString! El resto es "siempre lo mismo"

 

[Delphius]

A eso mismo me referia (desde el telefono a veces me dan menos ganas de escribir )

 

 

No entiendo exactamente a que queres llegar (menos indireccion). Si te referis a eficiencia de ultima los podes declarar como inline. Los helper de Delphi, por ejemplo el de Integer, el metodo ToString lo define como inline e invoca a IntToStr(Self)

 

Yo siempre implemento las dos versiones, la estatica y la "normal" (como se le dice a este tipo de metodos?? laguna mental!!) por una cuestion de comodidad

 

La gran ventaja de hacerlo de esta manera y no como la vieja escuela es el scope (alcance) que queda mas limitado, y eso es siempre bueno

 

A la vieja escuela es tener funciones declaradas asi..

 

delphi

function StrToEnum(const Value: string): TEnum;
  function StrToEstadoCivil(const Value: string): TEstadoCivil;
 
  function EnumToStr(const Value: TEnum): string;
  function EstadoCivilToStr(const Value: TEstadoCivil): string; 

Estas tipeando codigo y para en la ventanita de sugerencias se te despliegan dos opciones

 

Las StrToXXX se "chocan" con todo! StrToInt, StrToFloat.. si le podes poner otro nombre, es cierto. 

 

De esta forma te queda:

 

delphi

TEstadoCivil.[Parse/ToString/ToInteger/etc..]

Ponele que sea TextoToEnum, pero es lo mismo, te salen todos los TextoTo.. y tenes que elegir la adecuada. Parece tonto pero a mi me resulto muy util los type helper. Hoy los implemento para absolutamente todos los enumerativos

 

Tambien tengo metodos asi:

delphi

TEstadoCivilHelper = type helper for TEstadoCivil
  public
    class function GetItems: TStrings; static; // devuelve un TStrings con todos los TEstadoCivil.ToStr
    class procedure AssignItems(AStrings: TSTrings); static; // Asigna GetItems al parametro AStrings
  end; 

Esos metodos los uso para asignar por ejemplo los estados civiles a un TComboBox

 

Ademas, siempre tengo la esperanza de que implementen herencia y/o genericos

 

Si los de FPC pudieron quiere decir que los de Embarcaderos son vagos! Osea yo quiero declarar un helper generico para los enumerativos y redefinir ToString! El resto es "siempre lo mismo"

 

Por indirección me refiero a esto:

Enumerativo -> método clase estático -> método normal

Enumerativo -> método normal

 

Los caminos conducen a Roma. El 1er método cuenta con pase indirecto. El 2do es directo.
No me refería eficiencia, sino a ese detalle tan peculiar que, al menos en tu propuesta, me parece que podría evitarse. ¿Que se gana con que sea un método de clase y estático? La pregunta va en serio. Entiendo el objetivo de un método de clase cuando estamos hablando de una clase, pero ahora aplicado a un tipo de dato, como el numérico en este caso, ¿que rol cumple?

 

 

Yo tampoco recuerdo como es que se les llama a los "no dinámicos", no eres el único con lagunas mentales.

 

 

Por supuesto que es preferible algo que nos evite la vieja escuela. Y por eso es que me vi tentado en tratar de darle una oportunidad a los helpers.

 

Lo que me estuve preguntando después de estas prácticas es que tan diferente es tener por ejemplo una clase extra, que contar con el helper. Después de todo... ¡para ambos tenemos que declararlos e implementarlos! Si, te entiendo que la gracia del helper es que con el propio tipo podemos hacer nuevas cosas y se hace más amena la "lectura" del código. Pero  tampoco me parece que es tan pecaminoso MiClaseExtra.AlgoConEnum() contra un MiVarEnum.AlgoConEnum() o incluso el que debamos hacer el TMiEnum.AlgoParaObtenerEnum() como vamos a necesitar en ciertas ocaciones.
 

No me parece tonto que tu los uses. No te critico, en buena parte soy yo el rezagado. Vengo desde D6 en donde las cosas estaban lejos de esto y cuesta abandonar algunos vicios.

El ejemplo que das sobre GetItems para poner todo el listado en un combo me parece genial. ¡La verdad no me lo había pensado! ¡Y ahora que lo pones, le da un buen puntaje extra a los helpers!

 

Me llama la atención que digas que en FPC los helpers tengan herencia y no los de Delphi. Vi el artículo wiki de Lazarus que lo describe, y asumí que en Delphi las cosas serían igual. ¿No será que en las últimas versiones de Delphi se han puesto al corriente? No creo que les guste estar "detrás" de esa movida... cuando se está "promocionando" bastante los helpers ultimamente. O al menos a mi me da esa impresión (busquen sobre helpers y delphi y vean)

 

Saludos,

[Agustin Ortu]

No, los helper de Delphi no soportan herencia (1er punto critico)

 

El segundo punto aun más critico es que no se te permite extender una interface usando helpers

 

Lo ultimo que cambiaron en los helper hace poco en Delphi 10.1 Berlin, es que ahora no pueden acceder a la parte privada de las clases. Pueden acceder a la parte publica y protegida

 

En realidad la parte de las funciones estaticas es una

 

A mi la que mas me gusta y mas uso es la parte "normal", es decir el Enumerativo.ToString, Enumerativo.ToInteger, 

 

Pero lo de la herencia es una cagada! No solo para los helper que declara uno. Queres extender un helper que ya viene "de fabrica" y no podes! Osea quiero agregar un metodo a TStringHelper y cual es la solucion? Copiar y pegar todo el helper de nuevo y agregar los metodos nuevos!

[Delphius]

Ya me está convenciendo de sus utilidades el tema de helpers.

 

Hoy estuve divagando en una idea medio loca que podría ayudarme en mi proyecto. Tengo algunos tipos enumerativos definidos y pensé que ya que FPC ofrece la herencia para los helpers en tratar de hacer un helper base para mis enumerativos, con métodos como ToInteger, ToIndex, ToChar, ToString. Y que luego existan helpers que sobreescriban estos métodos para usarlos con el tipo enumerativo adecuado y ampliar las funcionalidades.

 

En principio la idea era buena... después de todo estos métodos tienen una "interfaz" común:

delphi

function ToInteger: integer; abstract; virtual;
function ToIndex: integer; abstract; virtual;
function ToChar: char; abstract; virtual;
function ToString: string; abstract; virtual;

Pero allí llegó mi cabeza y me dijo: Momentito... Para tener un helper base, éste aplicará a un tipo enumerativo en concreto. Ergo, cualquier helper que herede de éste también por fuerza deberá aplicar al mismo enumerativo.

 

Es decir, esto:

delphi

TEnum1 = (...);
TEnum2 = (...);
//...
TEnumN = (...);
 
THelper1 = type Helper(HelperBase) for TEnum1
 // etc...
end;
THelper2 = type Helper(HelperBase) for TEnum2
 // etc...
end;
 
THelperN = type Helper(HelperBase) for TEnumN
 // etc...
end;

No es posible.

 

Al momento de definir el HelperBase, este va "atado" a un enumerativo en cuestión:

php

THelperBase = type helper for TEnum0 // Enum0 es otro enum cualquiera...
  // etc...
end;

Y por tanto ahora, todo Enumerativo que lo extienda, debe ser para dicho Enum:

delphi

THelper1 = type helper(HelperBase) for TEnum0
  // etc...
end;

Avisenle a mis neuronas que no es posible crear un gato desde un perro.     Algo me dice que tengo que hacerme una nueva "mental note"   

 

Para llegar a una idea "similar" a esta, se me hace que si podría ser útil ya el enfoque de tener una clase TEnumClass (por darle un nombre) abstracta con métodos virtuales y abstractos. Luego extender de ésta para mis enumerativos. Esta clase ya me la imagino que la podría disponer en mis módulos bases. Este diseño incluso ya me justificaría una capa Services. Hasta el momento no veía necesario que disponga de una capa así, pero quizá sea sano que algunas cosas que ya tengo puedan ir a ésta. Lo estaba medio evitando para no estar añadiendo más unidades al proyecto.

 

Saludos,

[Agustin Ortu]

Estoy como el nene cuando le pinchan el globito..

 

Entonces los muchachos de FPC no "implementaron herencia en los helper"; seguro fue algo que "se les escapo" por como implementaron los helper; del mismo modo que Delphi se les "escapo" el acceder a metodos privados desde los helper

 

Yo crei que lo habian mejorado basandose tambien un poco en lo que protestamos los Delphinianos

 

En fin.. todo se resume en: 

 

Avisenle a mis neuronas que no es posible crear un gato desde un perro.

 

[Delphius]

Estoy como el nene cuando le pinchan el globito..

 

Entonces los muchachos de FPC no "implementaron herencia en los helper"; seguro fue algo que "se les escapo" por como implementaron los helper; del mismo modo que Delphi se les "escapo" el acceder a metodos privados desde los helper

 

Yo crei que lo habian mejorado basandose tambien un poco en lo que protestamos los Delphinianos

 

En fin.. todo se resume en: 

 

OJO. En parte tienen razón, si se está haciendo un helper para un tipo en cuestión, si se hereda dicho helper es natural que aplique al mismo tipo o especie. Tiene sentido esto cuando hablamos de que dicho tipo sea una clase y por tanto es de utilidad en un class helpers, o bien en un record helper (aunque no he probado con esto último) ya que desde una clase o un record podemos ir ampliando ramas.

El asunto es que cuando el tipo al que vamos a "hackear" es un enumerativo las cosas son un tanto diferentes. Sino pensemos: ¿Podemos definir un sub tipo enumerativo? Que yo sepa no:

delphi

type
  TEnumBase = (ebUno, ebDos, ebTres, ...);
 
  TSubEnum = (// ¿Cómo indico que este Sub enumativo sea una "especie" de TEnumBase?);

Cada enumativo es una "raiz". Es independiente de otro ¡No admite ramas! Por tanto intentar hacer sub enumerativos, e incluso pretender que un enumerative helper definido para un enumativo en particular aplique a otro carece de sentido.

Lo que si es legal es heredar un enumerative helper para el mismo enumativo. En ocasiones puede ser por razones de legibilidad y necesidad ir ampliando con nuevas características y hasta incluso sobreescribir otras.

 

Lo que podríamos probar es si tiene sentido una herencia sobre "subtipo" en los conjuntos (Al menos matemáticamente el concepto de subconjunto existe) No hice experimentos para comprobar si es posible hacer un set helper, y por consiguiente heredar de éste. Es decir intentar definir un set, un helper para éste y luego hacer un subset y un sub helper para el subset.

 

A pesar de que el concepto de los helpers es una vía para "cruzar" la barrera del POO y "meternos en donde no se debe por la puerta trasera" debe seguir los mismos principios elementales: herencia y polimorfismo.

 

Saludos,

[Agustin Ortu]

Quiza esto pueda ser viable