On Wed, 17 Nov 1999, M.-A. Lemburg wrote:
>...
> Anyway, I think that factory functions are the way to go,
> because they offer more flexibility w/r to reusing already
> instantiated codecs, importing modules on-the-fly as was
> suggested in another thread (thereby making codec module
> import lazy) or mapping encoder and decoder requests all
> to one class.
Why a factory? I've got a simple encode() function. I don't need a
factory. "flexibility" at the cost of complexity (IMO).
> So here's a new registry approach:
>
> unicodec.register(encoding,factory_function,action)
>
> with
> encoding - name of the supported encoding, e.g. Shift_JIS
> factory_function - a function that returns an object
> or function ready to be used for action
> action - a string stating the supported action:
> 'encode'
> 'decode'
> 'stream write'
> 'stream read'
This action thing is subject to error. *if* you're wanting to go this
route, then have:
unicodec.register_encode(...)
unicodec.register_decode(...)
unicodec.register_stream_write(...)
unicodec.register_stream_read(...)
They are equivalent. Guido has also told me in the past that he dislikes
parameters that alter semantics -- preferring different functions instead.
(this is why there are a good number of PyBufferObject interfaces; I had
fewer to start with)
This suggested approach is also quite a bit more wordy/annoying than
Fred's alternative:
unicode.register('iso-8859-1', encoder, decoder, None, None)
And don't say "future compatibility allows us to add new actions." Well,
those same future changes can add new registration functions or additional
parameters to the single register() function.
Not that I'm advocating it, but register() could also take a single
parameter: if a class, then instantiate it and call methods for each
action; if an instance, then just call methods for each action.
[ and the third/original variety: a function object as the first param is
the actual hook, and params 2 thru 4 (each are optional, or just the
stream funcs?) are the other hook functions ]
> The factory_function API depends on the implementation of
> the codec. The returned object's interface on the value of action:
>
> Codecs:
> -------
>
> obj = factory_function_for_<action>(errors='strict')
Where does this "errors" value come from? How does a user alter that
value? Without an ability to change this, I see no reason for a factory.
[ and no: don't tell me it is a thread-state value :-) ]
On the other hand: presuming the "errors" thing is valid, *then* I see a
need for a factory.
Truly... I dislike factories. IMO, they just add code/complexity in many
cases where the functionality isn't needed. But that's just me :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4