From fc66a34dee34c56d6c1b5cf643d90b87f374d534 Mon Sep 17 00:00:00 2001 From: David Hilvert Date: Wed, 25 Nov 2009 01:23:43 +0000 Subject: [PATCH] bugs: Don't require client knowledge of flattened representations. Ditz-issue: 507685b9ac970ed0fdbc479e4d25fc07ee13efe5 --- bugs/issue-507685b9ac970ed0fdbc479e4d25fc07ee13efe5.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/bugs/issue-507685b9ac970ed0fdbc479e4d25fc07ee13efe5.yaml b/bugs/issue-507685b9ac970ed0fdbc479e4d25fc07ee13efe5.yaml index a6cda56..ddf3159 100644 --- a/bugs/issue-507685b9ac970ed0fdbc479e4d25fc07ee13efe5.yaml +++ b/bugs/issue-507685b9ac970ed0fdbc479e4d25fc07ee13efe5.yaml @@ -505,4 +505,17 @@ log_events: older ALE code, so that current ALE code could be used as a starting point for acceleration, while still allowing migration to an approach providing an API for alternative UIs. +- - 2009-11-25 01:23:35.614857 Z + - David Hilvert + - commented + - |- + A couple of notes on the previous -- (a) I think there were four (or five) methods proposed + if all variants are considered; (b) better than having the client do the flattening would be to + make use of the currently outlined API facilities for returning things such as filters, renderers, etc. + to the client, so that the library could perform flattening, and the client could be passed a flattened + version (pointer thereto, etc.). + + In this way, the details of flattening into some sort of convenient representation would be wholly contained + in the library, while the client could specify a more abstract name (e.g., the text names currently used for + naming filters and renderers; which should follow notes hereto). git_branch: -- 2.11.4.GIT