Dan Sugalski wrote: > ># Instead, lets just give an entry number. We can have arbitrary data > ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having > ># names attached. > > > >What happens if two tools (say, a custom debugger and the Perl compiler) > >both use the same segment number for something? Names make collisions > >less likely. > > Whoever's writing the bytecode file needs to deal with > that--hopefully there's only one writer. I'm in the middle of getting > the API down on electrons, so we should have something to savage > reasonably soon.
I don't think you can guarantee that. Sooner or later someone will download the packfile spec and write a stand-alone compiler that generates bytecode directly, using none of the Parrot tools. If such a compiler needs an extension section, what number do they give it? (I'll be using imcc for C#, but others might want to do things manually). Numbers need to be centrally managed to prevent conflicts, because it is impossible for an independent person to "make up a number" and guarantee no conflicts. Names are easier to make unique, as the name of the language/project/author/DNS name will normally be unique enough to act as a prefix. No central management required. e.g. compare the MIME type system with SNMP's ASN.1 based object identifiers. Picking a new MIME type out of thin air is easy. Adding a new field identifier in SNMP requires massive co-ordination, and sacrificing of large numbers of rubber chickens to the IETF gods. Names are also easier to remember. Quick now: what is the MIME type for HTML? What is the SNMP object identifier for the IP default TTL? Cheers, Rhys.
