I had a feeling you couldn’t do that because the parser jumped in when it recognised the creature token and never gave you a chance for your before routine to do anything. However, a quick test proved that to be wrong.
I assume you meant for the before routine to move dog to player. A side effect of doing this is that you can exceed the inventory limits. The extra code needed to avoid this probably negates the advantage of saving one attribute.
For your particular game, maybe it would be better if the library had that extra attribute (I’m not convinced that even that is the case, since making the dog a non-animate object like you want forces you to write code for other cases or accept that the dog in treated as an inanimate object, i.e. when the player types “Rex, jump”). But the bigger question is - what’s most valuable for PunyInform games in general - another free attribute or the ability to make something inanimate male? With z3 being the most important target, attributes and common properties are in limited supply, and we’ve worked hard to find solutions that use up as few of them as possible for the library, to give game author’s a bit more freedom.
If one out of ten or maybe one out of twenty games need the ability to pick up animate objects, maybe it’s better that those games have code to make it happen. They could add a before rule for those objects - that rule can also check inventory limits if needed and even run after routines. Another option would be to replace TakeSub and/or RemoveSub.
Or we could add an entry point to allow the game author to decide whether to allow certain actions for animate objects. That would make sense if this was a somewhat common occurence. I’m not convinced it is.
at least one of the canonical Inform examples (Alice) indeed has a case of animals in the inventory (the two kittens, and there’s code for ensuring that only one is held by the player, so I think that Warrigal’s question makes sense, albeit I remain of the opinion that Puny is best for new works, albeit this debate has piqued my curiosity about if alice.inf can be ported to punyinform (no wonder that my WIPs are perennial… 
)
Best regards from Italy,
dott. Piergiorgio.
I’m just pointing out some of the side effects when you remove something from the standard library. Inanimate male objects are quite common (especially in foreign languages) and I know that I’ve used it a lot, e.g. statues of people where the people may be male. Whereas I’ve never had the need to add a global attribute, apart from legible, which is not really necessary anyway. If you run out of attributes, you can always use Globals.
This raises the question, do you need animate at all? (They could just be static objects and system responses carefully reworded to suit.) Do you need life rules at all? (You can just use before rules.) And so on.
True. Only we don’t care about any languages other than English. Any project needs boundaries and focus. We decided to focus entirely on English, as making sure the library is prepared to support other languages would make the library bigger and make the project take longer time. Some people are translating the library anyway, which is fine, but the library nowhere near as well prepared for translation as the standard library.
A dead object is neuter in English. While you may want to assign it an additional gender like male, the standard library doesn’t really support this. I.e. if you create a statue and give it both male and neuter, and the player types “turn the statue then open it”, the parser doesn’t know that “it” refers to the statue. This bothered me a bit more for Swedish than for English, so I added support for it in the Swedish translation of the standard library. But this is a nice-to-have feature, which we can live without for a minimalistic library.
I guess it depends on your programming style. I think they’re very handy and use them, and they’re especially good to have when story file size is important.
While there are ways to do the same thing without an attribute, they all produce slower and/or bigger code.
We could skip a lot of properties and attributes. We could leave it to the author to write a system of classes which set all the rules instead of using attributes such as static, scenery, animate, edible etc . before is unnecessary because you can always use react_before instead etc. But we’re trying to strike a balance where we provide just the right amount of functionality to make it as fun and easy as possible to write a text adventure, while doing everything we can to keep the size down. It’s a struggle, and it means saying Yes to some things and saying No to other things.
Not sure if you think this helps, but as a result of this thread we just added a way to make animate objects takable, since we think it makes a lot of sense that you should be able to pick up say a chicken or a puppy. Before including puny.h, define a routine for this new entry point, like this:
[ DisallowTakeAnimate;
if (noun ofclass Puppy) rfalse;
];
This was added the way we like to add things to the library - if you define the routine it is used, and adds the routine’s size plus a few bytes to the game. If you don’t define it, this mechanism doesn’t make the library bigger or slower in any way.