Se puede hacer un array de procedures

[[coso]]

Si, es normal. El array que tu tienes lo has creado para objetos tipo procedure a secas, en tu ultimo codigo estabas intentando meter procedures con argumento alla. Seria como meter un TBitmap en un array de TShapes, por ejemplo. Si lo que quieres es hacer un array con procedures que le mandas argumentos, o con funciones, deberas declararlo de otra manera

Código Delphi [-]
    procedures_sin_nada   : array [0..10] of procedure of object;
    procedures_con_arg    : array [0..10] of procedure (s : string) of object;
    procedures_con_arg_2  : array [0..10] of procedure (a : double; td : TEdit) of object;
    funciones_con_arg     : array [0..10] of function (s : string) : string of object 
    ...

lo que se esta realmente guardando en el array es la direccion de memoria donde se encuentra cargada dicha funcion, su puntero o pointer.

Para tener varios tipos de funciones (con varios tipos y numero de argumentos) lo mejor es crear un solo tipo con una cadena de argumento y luego parsearlos. Ten en cuenta que es trabajoso, al menos hacerlo la primera vez , por lo que quiza no te acabe a salir a cuenta.

Te pongo un ejemplo

Código Delphi [-]
procedure TForm1.Funcion1(s : string);
var 
        sl : TStringList;
        arg_1 : integer;
        arg_2 : double;
        arg_3 : TEdit;
begin
        sl := TstringList.Create;
        sl.commatext := s; // siendo s, por ejemplo s := '3.2 test Edit1';
        
        arg_1 := strtofloat(sl[0]);
        arg_2 := sl[1];
        arg_3 := (FindComponent(sl[2]) as TEdit);
        ...
        sl.free;
end;

PD: en tu codigo, estas usando un array dinamico, esto es, sin indicarle la cantidad de elementos que tiene. No se si se le tiene que asignar o no memoria en este caso, pues es, a lo sumo, un array de enteros. A ver si alguien del foro lo aclara :/

Venga, saludos.

[[Delphius]]

Hola David, disculpa que te pregunte: ¿Van a cambiar mucho esos procedimientos? ¿Puede que en algún momento se agreguen más? ¿Tienen algo en común?

No me convence mucho la idea de tener arrays de procedures. Yo más bien considero que puede ser más indicado emplear una fábrica o Factory. Posiblemente alguna Fabrica abstracta.

Habría que estudiarle un poco la idea pero me parece más indicado y certero tener clases "Productos" y dejar que cada una asuma la responsabilidad de hacer su propio algoritmo. Y luego una Fábrica crea la/s clase/s Productos adecuadas.

Si no se me entiende la idea, te recomiendo la lectura de estos temas:

Wikipedia (Español)
Fábrica (o Factoría) Abstracta
Fábrica (o Factoría)

About.com (Inglés)
Factory Patterns

Por el tema de que se pueda elegir más de una cosa por hacer... habría que ver de que manera hacerlo. Lo más simple es tener un FOR e ir creando y destruyendo los productos que se necesiten:

for cantidad_de_productos hacer:
Crear_producto(¿NombreProducto?)
Producto.Hacer()
LiberarProducto()

No se si se entiende la idea. No se si estás puesto con el tema de clases y el uso de patrones. Pero al menos a mi me parece más adecuado el uso de una Fabrica que estar empleando esos arrays.

Saludos,

[[coso]]

No. Yo creo que lo mejor en tu caso son los arrays, incluso la solucion sencilla de fenareth o pcicom ya te sirven.

saludos.

[[Delphius]]

Empezado por coso

No. Yo creo que lo mejor en tu caso son los arrays, incluso la solucion sencilla de fenareth o pcicom ya te sirven.

saludos.

Puede servir.
Si sólo van a existir pocos métodos a realizar el tener así puede ser viable.

Mas bien yo ofrecí ese punto de vista por lo que estuve viendo a como se estaba llevando el hilo: funciones y procedimientos con o sin parámetros... muchos corchetes...

Imaginate si en vez de esos 4 o 10 son 20.
El código puede resultar un tanto ilegible y engorroso. ¿Y si hay métodos que comparten ciertas similitudes? ¿Y si luego es necesario ampliar las posibilidades?

Y algo que por el momento no se contempla ¿Y si un proceso o actividad necesita obligadamente de una secuencia determinada?

El uso de una fábrica puede facilitar muchas cosas. Por ejemplo, veo que en su ejemplo inicial menciona a CheckEntregas y CheckPedido. ¿Que diferencia a una de otra? ¿Se puede compartir algo en común y aligerar el código?

Para situaciones en donde el código a lo largo del tiempo va a ser estable la manera en que ofrecen sus códigos puede resultar viable.

Pero para situaciones en donde puede llegar a existir código redundante, o bastante similar, en donde no se prevee la cantidad la cantidad de opciones y "productos" a considerar considero que el uso de una Fábrica es más adecuado.

No pretendo imponer mi idea. Mas lo digo para que David analice objetivamente su situación.

Saludos,

[[coso]]

ok. Las discusiones sobre teoria abstracta no me van, puesto que transforman las soluciones en problemas.

saludos.

[[Delphius]]

Empezado por coso

ok. Las discusiones sobre teoria abstracta no me van, puesto que transforman las soluciones en problemas.

saludos.

Hola coso,
Me da un poco de mal sabor la forma en que escribiste
Yo ofrecí un punto de vista solo eso.
No se trata de una discusión.

¿Que causan problemas? ¿A que te refieres?

Yo simplemente hago un comentario y doy un punto de vista analítico a la situación pero no por ello va a traer problemas. Es posible que mi punto de vista no sea adecuado y esté equivocado.
Pero no por ello debo mantenerme callado.

Es preferible prepararse y examinar mejor un problema antes de dar un paso.
En ocasiones tener un diseño cerrado es muy favorable, y en otras no.

La elección de una Fabrica tiene sus desventajas, como muchas cosas de la vida, pero no por ello lo constituye una mala elección.

Si he dicho algo malo dime.

Tu y yo no sabemos lo que planea David, el verá y analizará las diversas alternativas y optará por la que le es más favorable.

Espero que tomes a bien mis comentarios.

Saludos,

[[coso]]

ok. Las discusiones sobre teoria abstracta no me van, puesto que transforman las soluciones en problemas.

saludos.