On Sun, 2005-05-08 at 13:35, bulia byak wrote:
What I have at the moment is a couple of scripts that read the CSS2.1, SVG1.1 and CSS3Text specs as downloaded off the w3c site, find all the property definitions within them and automagically produce output such as:
/** \brief Representation of the CSS 'counter-reset' property
Generated from "[ <identifier> <integer>? ]+ | none | inherit" Inherit: False Initial: none */ struct inkscape::style::css::counter_reset { bool read(Glib::ustring const &str); Glib::ustring write() const; void set_to_initial(); unsigned set:1; unsigned inherit:1; unsigned type:1;
struct inkscape::style::css::identifier { unsigned integer_set:1; struct css_identifier value_identifier; struct css_integer value_integer; };
What exactly does this sort of nested declaration mean?
std::vector<struct identifier> value_identifier; enum {type_identifier, type_none};};
- Where do I go from here? The simplest answer is to bundle the whole
lot into SPStyle, like we have at the moment. The problem with that is of course that the current struct is at least 320 bytes and putting all 160+ css properties into it would consume a significant amount of memory in a large drawing. At the opposite end of the memory:cpu ratio spectrum is to have no SPStyle at all and require everyone to call read() themselves if they want a pre-parsed property. Half-way points are of course possible too, where particularly common properties like fill and stroke are held in SPStyle but everything else is evaluated on each request. There are also lazy evaluation schemes which save the results of the evaluation, and so on and so forth. My personal favorite at the moment is to have most things lazy but a selected few always calculated.
That's probably the best long-term goal. For the short-term lumping everything into SPStyle is best because it is simple and is known to work.
Longer-term I will have to get a better sense of the design before making any recommendations. Probably some sort of lazy thing backed by an associative data structure, queried by symbols (i.e. GQuark or the like) would be best. Whatever it ultimately is, the interface for lazy and non-lazy properties should remain uniform.
- The more fundamental question: am I even going in the right
direction? I'm replacing a simple yet difficult-to-maintain piece of code with a complex yet zero maintainance (or close to it, anyway) piece of code. What's the point anyway when I should only need to run it once, then throw it away? Since the majority of properties are simple enums, wouldn't it be easier to do it all by hand? Is this just refactoring for its own sake, without any useful new features in sight? (Actually that's not true; a proper implementation of shorthand properties is notably lacking at the moment).
In principle it's much better. Don't ever believe the "just once" part though. It's best to have the source specifications and the script that generates them in the source tree, and have them be authoritative. And generate the code as part of the build process.
Because Things Will Change, and the last thing you want is to tempt people into manual hacking of generated code.
Do see if you can hoist some of the stuff that's currently generated into non-generated superclasses though. Anything that gets repeated multiple places is screaming for refactoring.
The platonic ideal is that there should only be one place in the entire codebase which is authoritative for a particular pattern of code.
-mental