On Tue, 2010-03-30 at 09:27 +0000, David Siegel wrote:
> Consider keypaths used as abstract representations that just happen to
> coincide with the Linux implementation. The Linux interpretation of
> these keypaths is the identity function, and the Windows
> interpretation maps "/" to "\". This should be handled in the Windows
> backend, not changed at the level of the preferences interface.
>
That will be fine as long as nothing wants to use '\' in the keypath on
Linux or '/' in the keypath on Windows, which seems like a reasonable
assumption.
I wouldn't object to a path-component based interface - which would
basically be to pass in (string[] keypath) rather than (string keypath).
I don't think it's particularly necessary, though. I don't see a
problem with David's solution.
On Tue, 2010-03-30 at 09:27 +0000, David Siegel wrote:
> Consider keypaths used as abstract representations that just happen to
> coincide with the Linux implementation. The Linux interpretation of
> these keypaths is the identity function, and the Windows
> interpretation maps "/" to "\". This should be handled in the Windows
> backend, not changed at the level of the preferences interface.
>
That will be fine as long as nothing wants to use '\' in the keypath on
Linux or '/' in the keypath on Windows, which seems like a reasonable
assumption.
I wouldn't object to a path-component based interface - which would
basically be to pass in (string[] keypath) rather than (string keypath).
I don't think it's particularly necessary, though. I don't see a
problem with David's solution.