Julian Foad writes:
> Malcolm Rowe wrote:
> 1. Re. semantics: For this to be a public API, your new doc string is a good
> description of the implementation, and these are acceptable semantics for a
> public API, but its name ought to reflect the ASCII aspect of its semantics.
>
> At some later stage we're bound to want an "is_xml_name" with full UTF-8
> semantics, and I don't think it's OK to later change the meaning that much.
Yes, I think it is OK if we document the current limitation of this
function. I object to renaming this to something including _ascii_
(or whatever) because it will be cruft that no one will want to use
when (if) the function is properly and completely implemented. Note
that this function is new in 1.4, so are free to change its semantics.
>
> 2. Re. r18202: that commit purports to avoid sharing variables
> (svn_ctype_table) between libraries:
>
> That commit eliminated the single use of an svn_cytpe macro outside libsvn_subr
> at the time, but did nothing to prevent such use. The email discussion said
> that public access to svn_ctype_table[] was to be deprecated, which would
> require the svn_ctype_* macros to be converted to functions, but that has not
> been done. Now there are other uses outside libsvn_subr, so presumably the
> Win32 DLLs again don't build/work properly - is that the case?
I guess so.
> I think that commit wasn't a proper way to solve the problem. If we solve the
> variable-sharing problem properly, then that commit r18202 can be reverted, and
Agreed. Someone with enough motivation for Windows DLLs?
> the problem of how to name and describe the XML-name function goes away. That
> would be good because we've no reason to want such a function in our public
> API, as far as I know.
>
Other clients could find it useful to be able to validate a property
name, but let's not add a public API for that weak reason:-)
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 18 00:24:00 2006