1Work notes
2==========
3
4These are my notes on the evolution of rc. I used to keep these in separate files on my development
5machine, but it makes more sense to include them here. Warning: geeky stuff ahead.
6
7Unlike in most parsers, the unary minus operator is currently not part of the 'data' rules, but
8  of 'integer' and 'float'. When expression support is more complete, it may make more sense to put
9  this in 'data'. However, 'integer' is used in other places as well and these places allow
10  negative numbers too. Maybe we can replace the calls to 'integer' with 'data' and allow the data
11  to the integer only (by always trying to cast it, perhaps). Then you can do stuff like
12  `resource(10 + 1) 123;` But maybe that goes too far.
13
14When filling in boolean fields of user-defined types or messages, you can do either
15  `field = true` or `field = false`. I thought it would be nice if you could also do just
16  `field` and `!field`. However, that introduced a reduce/reduce conflict in the parser. You see,
17  the name of the field is an IDENT token, but we already have something like that in the 'type'
18  rule of 'data'. The parser doesn't know what the IDENT is supposed to be: the name of the boolean
19  field or the name of the type. Maybe there is a solution for this by shuffling around the parser
20  rules a bit.
21
22Support for the built-in types point, rect, and rgb_color is currently hardcoded into the
23  decompiler. The other built-in types -- app_flags, mini_icon, etc -- are not supported at all.
24  It would be better to use the type symbol table for this as well. Then the decompiler can also
25  support user-defined types (although these type definitions must be provided to the decompiler
26  somehow). This is advanced stuff that probably no one will ever use.
27
28The builtin types are added to the symbol table "by hand". You can see this near the bottom of
29  'parser.y'. This is a bit cumbersome, so I have devised an alternative. We put the builtin type
30  definitions in an rdef script and install this in a "standard include dir", for example:
31  ~/config/include/rc. Before it compiles the user's rdef files, the compiler first loads all
32  scripts from that standard folder. (This also allows us to use these rdef files for decompiling,
33  and users can simply install their own. See above.)
34
35In "auto names" mode, the decompiler currently does not use the enum symbol table. So if two
36  resources have the same name and that name is a valid C/C++ identifier, the decompiler will add
37  two conflicting symbols to the enum statement. This can also happen when multiple input file
38  have conflicting resource IDs.
39
40When you decompile certain apps (BeMail, Slayer) and then compile these rdef files again, the
41  archive and message fields in the new .rsrc file are larger than the original's. I think this is
42  because rc doesn't add the message fields as "fixedSize" (see the BMessage docs from the BeBook).
43  This doesn't really hurt, though, since the BMessage will be properly unflattened regardless.
44
45Right now, archives are treated as messages. Maybe we should give them their own type,
46  B_ARCHIVED_OBJECT (type code 'ARCV').
47
48New options, stolen from other resource compilers (rez and beres):
49
50-D --define symbol[=value]
51    set the value of symbol to value (or 1 if no value supplied)
52
53--no-names
54    do not write any names in resource file
55
56-h
57    write resource as C struct in a header file
58
59-d
60    dump resource to stdout
61
62Attributes. I would be nice to have a tool that can take text-based descriptions of attributes and
63write out an attribute file. Of course, rc is the ideal candidate for this, since it already does
64the same for resources. However, resources and attributes are not the same. Attributes are
65name/data pairs. The name should be unique. They don't have IDs. They do have a type code, but it
66isn't used to identify the attribute. It is probably best to add a new kind of definition:
67attribute(). Should this statement allow only simple data, or must attributes be able to handle
68flattened messages, arrays, etc too? A source file should either contain resource() statements or
69attribute() statements, not both.
70
71User-defined symbolic constants. To keep things simple, adding a #define keyword would suffice,
72although this always creates global symbols so there is a chance of name collisions. In addition
73(or instead) we can extend user-defined types to have their own (local) defines too. If we use the
74#define keyword, we should infer the type of the constant from the data (100 is integer, 10.5 is a
75float, etc). This is necessary because we don't have a separate preprocessor step like C/C++ does --
76that is why our symbolic constants are typed.
77