a few remarks * you probably want to make the wml_object virtual (i.e with "=0" methods) so it's never implemented directly * would it be possible to get rid of the "initialize" method somehow, and merge it with the constructor ? * there is no handy way to "export the allowed syntax" which, to me, would be the point... i.e to extract a "meta WML" string... * in animation WML I have childs of [animation] that are [xxx_frame] where xxx can be any string. Similarly, i have xxx_offset attributes... would your method handle that ? * I don't really understand what the "buisness_object" is, could you explain ? if it's only used to cast in and out of unknown types, maybe use a "void*" or an empty class that we could inherit from to avoid the casts... * could the "buisness object" be a template class ? or would that screw the inheritence from the (non-templatable) wml_object class * if we need to do a new class for every WML object, there will be a huge growth in code base... it might be worth working on a way to simplify the most common cases with helper objects, macros etc... that's a job for our C++ experts...
Overall this is a great idea, and your ideas sounds nice... However we have all seen how WML is criticall, and we really need to have this fundation right. Let's refine it some more, our C++ experts can probably get rid of some quirks, and we can improve some more on that... but please go for it, this is a really valuable goal... On Tue, Apr 22, 2008 at 11:39 PM, Jörg Hinrichs <[EMAIL PROTECTED]> wrote: > Hi everyone, > > > > this is a proposal about an idea i had for a long time: A framework for > processing WML. My original goal for this was to encapsulate the processing > of config objects (they really clutter the code quite a bit). But there are > more reasons i found out about when I started implementing lazy loading for > unit types: > > - Config objects take a lot of memory which can be reduced > substantially if properly handled. > > - Config objects have bad performance in retrieving values out of > them. Replacing them by "true" objects should benefit config-heavy > processing (like AI for example). > > - A WML framework gives us the opportunity to do a much more > rigorous checking of config objects than is done now. > > > > I started putting together an example for unit traits (something I would > need for replacing configs in unit_type). I have some working code that I > believe is good enough to present an overview of all important technical > details. The WML for unit traits is not processed completely in all details, > but it is able to process the mainline traits that are global to all races. > > > > Technical stuff: > > The main idea is to represent a WML tag as a class and an attribute as a > member of that class. Nested tags will be implemented as object members. > Actually every tag will need two classes: One that represents the object and > one that is responsible for building that object out of a config. > > There are circumstances where inheritance comes in handy. You can see that > by looking at processing [effect]. Each possible value of the "apply_to" > attribute is built as a new subclass. That way you are able to implement a > better check for allowed attributes. When using the object later on, one can > think of virtual methods applying the effect on a unit_type as well. > > > > You might ask why I didn't use templates. Well, actually that was my first > idea. But there are situations where I need inheritance with virtual methods > and I didn't find a proper way to realize that in combination with > templates. I have searched for some patterns, that combine templates and > virtual methods, but they seemed too restrictive to fulfill what I have in > mind. If someone more skilled in C++ has any ideas on that I am all ears. > > I also know that esr is aiming at realizing the WML checking with wmllint. > I think that is a good idea. I also did it in the code for a simple reason: > If there is a tag which is valid WML, but the code doesn't know how to deal > with it because it wasn't implemented there yet, we should be notified of > that. That's in my opinion the most important and the only necessary check > for the code. Everything else I am happy to have done elsewhere. > > > > What I would like to know from you: > > 1. Do you see any fundamental flaws either in the architecture > itself or in its application on WML, that goes against the above defined > goals? > 2. Do you think, WML is developing so fast, that such a framework is > too much overhead to keep synchronized? > 3. Do you know of certain WML that doesn't fit with this framework > well? > 4. Have you got any suggestions for technical details regarding the > framework implementation? I am not a C++ guru so I know I overlook some > nasty things here and there, unwanted copies and unproper deleting of > instances are probably top of the list ;-) > > > > Finally: > > Yes I know, it's a _*huge*_ task, since WML is almost almighty, meanwhile. > But I also think the benefits outweigh that, performance and memory as well > as a much better code organization. The good news is, that it can be done > step by step, one tag at a time. If I seriously go for this task, I will > write a code generator, that is doing most of the typing for me. I am also > glad for every help I can get for this, once the framework is completed and > implementation starts. > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev > >
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
