add demo functionality to Spec class

[jsilhan]

add demo functionality to Spec class

[eskultety]

you changed the API, thus removing the methods and only preserving the class attributes. It would be nice if you changed it back so we could stay consistent

[jsilhan]

Sorry for that, I thought we agreed about it at meeting. What changed later was removal of mark_doc and mark_docdir - this helpers will be useful so I will put them back. add_tag is no longer useful since there is the same attribute. Having files as list of tuples can represent all the files while tagging them as %doc, %dir, %docdir, %config and setting permission attributes. What exactly you want back and why? In this phase we have to design convenient API - Spec class will be accessed through plugins. Plugin should be able to remove/change/add files and other Spec attributes.

[jsilhan]

One more thing I'd like to change is to make tags dict[key -> set(vals)] instead of list so we can be sure that Requires and BuildRequires will occur only once without any checking.

[eskultety]

I follow your thoughts, I understand, that getters and setters are obsolete in python, but in terms of designing a convenient API, we have to think about things to be a little bit foolproof, to be specific, nobody can guarantee that if somebody inserts a tag into the dictionary they'll follow the correct syntax, e.g. 'Requires' cannot be used as 'requires' or REQUIRES, same for the syntax of script directives => this is why I think it could be much more convenient to have methods like add_tag, add_script/remove_XYZ, because the user would just call a method and the method would take care of everything necessary, otherwise the user/plugin developer would be completely responsible for how they access our attributes and what they use them for...
nevertheless, if you insist on dropping all the methods, there really is nothing for me to code if we provide no methods, don't you think???

[jsilhan]

It's not the more code, the better. We have to think about maintainability at first. It's hard to read code with a lot of generic crap (like Java get/setters). Some use case could be to iterate over Requires elements. Do you wanna create another iterating method for each tag?
When you write method with wrongly mixed lower and upper case letters you also don't get desired result. Somewhere still has to be static list of all allowed tags to avoid writing bullshit to Spec file (with ignore case checking or not). Plugin programmer will know what to use from documentation.
We can also revert changes more backward where common tags were represented by attributes. Do it as you want but keep it clean/simple with no generic stuff, please. These one liner methods could be added anytime in emergency case. BTW there will always be work, you can take another issue from Alpha version milestone when you're done.