Re: Implementing filters as callbacks / hashrefs / regexes

Your hash of coderefs is generally called a dispatch table in perl. It's an excellent choice, and a popular enough idiom to cause no confusion.

You may want to look into PerlIO::via, which addresses just your problem - preprocessing file I/O. It permits setting the processing scheme within the open mode argument, or with binmode.

After Compline,
Zaxo

Comment on Re: Implementing filters as callbacks / hashrefs / regexes

Replies are listed 'Best First'.
Re^2: Implementing filters as callbacks / hashrefs / regexes by clinton (Priest) on Jun 17, 2007 at 11:11 UTC
Hi Zaxo Your hash of coderefs is generally called a dispatch table in perl. It's an excellent choice, and a popular enough idiom to cause no confusion. It wasn't the dispatch table that I thought might cause the confusion, it was the fact that at object instantiation, I am "preresolving" each filter either to a coderef based on the parameter type (this part is fine), OR, to the codref returned by `$self->can($filtername)`. This second step returns a coderef to either a subclassed version of the filter, or to the default filter. If, after instantiation, the developer were to programatically add/change the subclassed version of the filter, then only new objects would notice. I realise this is an edge case, but this is why I was asking. You may want to look into PerlIO::via, which addresses just your problem Have a look at Re^4: Implementing filters as callbacks / hashrefs / regexes - maybe my use of the word filter was a bad choice here. The loading of data is handled by other modules. My filters control how it is treated after loading. thanks Clint	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Implementing filters as callbacks / hashrefs / regexes
by clinton (Priest) on Jun 17, 2007 at 11:11 UTC

Hi Zaxo

Your hash of coderefs is generally called a dispatch table in perl. It's an excellent choice, and a popular enough idiom to cause no confusion.

It wasn't the dispatch table that I thought might cause the confusion, it was the fact that at object instantiation, I am "preresolving" each filter either to a coderef based on the parameter type (this part is fine), OR, to the codref returned by $self->can($filtername).

This second step returns a coderef to either a subclassed version of the filter, or to the default filter. If, after instantiation, the developer were to programatically add/change the subclassed version of the filter, then only new objects would notice. I realise this is an edge case, but this is why I was asking.

You may want to look into PerlIO::via, which addresses just your problem

Re^4: Implementing filters as callbacks / hashrefs / regexes

thanks

Clint

[reply]
[d/l]