On Oct 5, 3:56 pm, Christian Boos <cb...@neuf.fr> wrote: > On 10/1/2010 9:47 PM, osimons wrote: > > > 1. Complex classes. Formatter, Context, GenericObject (or whatever) > > contains an inner life and structure that I'd need to understand. > > Complex, nested in several layers. They have non-descript names and > > what they do and how they do it is not obvious by looking at them. > > To improve the situation a bit, I'd like to rename Context to > RenderingContext, on trunk. > The old name will be kept for compatibility, Context = RenderingContext. > > In the WikiParser branch, the new formatter classes could be renamed > WikiFormatter. > > For Resource, I think it might be clearer to have an explicit `copy()` > method when creating a resource from another one, rather than the > shortcut `__call__` form (as a proof, before looking again at the code, > I thought `__call__` would do the same as `child()` ;-) ). > > Same clarification needed for RenderingContext, were a `nested()` method > would be better than `__call__()`. > > -- Christian
+1. Better names. Particularly the .copy() method should be added and used in our code. I don't mind it also supporting the short-form via __call__ -> copy(), but we should make our own code as readable as we can. As for nested (parent-child) contexts (and resources), could we not just use the familiar .append()? :::simon -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
