[DB-SIG] paramstyles, again (and now voting)

[Carl Karsten]

Art Protin wrote:
 > Dear folks,
 >    Carsten Haese wrote:
 >
 >> On Mon, 2007-06-04 at 12:13 -0500, Carl Karsten wrote:
 >>
 >>
 >>> Hmm, default style brings up a new issue:
 >>> If there will be more than one style, should there be a common
 >>>
 >> default?
 >>
 >> No, the default will be implementation-defined for backwards
 >> compatibility. There will be a common way of switching to the common
 >> mandatory paramstyle.
 >>
 >>
 >>
 >>>> might want to convey which paramstyles the module can accept. I see
 >>>>
 >> two
 >>
 >>
 >>>> options:
 >>>>
 >>>> * Invent a new module attribute called paramstyles that is a list or
 >>>>
 >> set
 >>
 >>
 >>>> of supported paramstyles.
 >>>> * Simply raise ValueError if the programmer requests an unsupported
 >>>> parameter style.
 >>>>
 >>> I kinda think it been decided that the set of styles will be required
 >>>
 >> of all
 >>
 >>> modules.  But given that it was never voted on, add it to the ballot.
 >>>
 >>
 >> I think we're more leaning towards making only one common style
 >> mandatory, and allowing other styles as optional extensions.
 >>
 >>
 >>
 > The collective may be leaning toward a more status quo with allowing
 > other styles
 > as extensions, BUT I for one, strongly endorse forbidding whatever is
 > not required
 > in the the way of parameter styles (or at the very least dropping any
 > mention of any
 > parameter style that is not required).  I do not care much about how
 > easy it is to
 > implement.  I care more about how easy it is for users of the interfaces
 > to understand

da!

I have been meaning to bring that up: The module should make the users life
easier.  "because it will be easier for the module developer" should not be a
reason for anything.

Also, on the point of backwards computability - I think that can be addressed
with a 'backwards compatibility module" that is a shim between legacy
application code and a dbv3 module.  It would basically be the v2 code that
would use the v3 module.  it would contain the who's use case for V3 is
backwards computability.  It would simplify V3 module code and use, and would
help V2 applications use V3 modules.  It would help channel new development of
all code to the simpler V3.

Carl K