[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Hello, translated world!
- To: <michael>
- Subject: Hello, translated world!
- From: Eric Dean Tribble <tribble>
- Date: Sat, 28 Apr 90 16:30:10 PDT
- Cc: <roger>, <xtech>
- In-reply-to: <Michael>,30 PDT <9004282044.AA14906@xanadu>
Sorry about the gun reference. Hill suggested I use something more
obviously improbable like nukes, but wet noodles would do just as well.
I have no intention of slowing people down by making anyone
(especially me!) a bottleneck for translator changes. The message was
in fact targetted at all those (including myself) who change the
existing hacks in the translator, rather than add new ones. Often
those changes cause some previously compiling file to no longer
compile for some obscure reason. The translator is sufficiently
distributed that such changes can't be detected until the old version
is long gone. Your suggestion of documenting changes in the code (or
better yet in the class comment or both) is well taken, and we should
do that. That would make the sending out a message more a courtesy
than a necessity. (I still find it very useful because we often end
up solving the same problem at the same time).
As for your changes, if we have a way of knowing (mail message or
comment) what you changed, then it doesn't matter whether you
reimplemented an already existing capability. If you send out a
message, and someone happens to see it before you finish with your
hack, adn there happens to be a pre-existing solution, then we can
tell you, and put some documentation in for the next guy. If none of
the above happens, then you continue on at the speed you would have,
and either we throw the old way away, unify the new way and document
it, or have both (and perhaps document them?).
One of the reasons I had little incentive to document the structure
was because the original mapping structure only overrode messages.
You could just go into the 'message translation' category and see al
the interesting transaltion hacks. Their are now also definition
overrides, but most of hte hacks are in the message translations.
Almost all the hacks are represented in one of the map methods. We
should use these as places to start the documentation.
You may have already discovered a lot yourself, but I would be happy
to give a guided tour of the translator. It shouldn't take very long
to cover the structure and the ways in which things can be hacked :-).