Front page | perl.perl5.porters |
Postings from January 2014
demerphq wrote: >Nonsense. Your example is a straw man. The example I gave is where a >piece of code *specifically* marks a scalar as being binary and thus >it does not break ANY existing code, I'm presuming that new code that uses the mark-as-octets and mark-as-characters functions will proceed to pass these strings to existing code. In my example, I'm supposing that $name_octets came from some other code that might be new and mark it as octets. If the new marks are only to be used in self-contained code that will never interchange marked strings with any other code, then theoretically that won't break anything. Of course people will inevitably use these marks across APIs, and they wouldn't be much use if they couldn't be so used, so theoretically a distinction arises between mark-aware APIs and mark-unaware APIs. Any sub parameter, sub return value, or slot in a data structure can be so classified. New code must make sure to strip marks before putting strings in a mark-unaware place. In theory this can work. In practice, hardly anyone will keep it straight. The skill required to correctly track which interfaces are mark-aware, and to translate between the two worlds at all the right points, is pretty much the same skill that's required in the present system to track which interfaces are for character strings and which for octet strings. Your suggestion also seems to be predicated on attaching new semantics to existing code, contrary to this vision of separate mark-aware and mark-unaware worlds. If the aim is to help unaware programmers then it has to apply to mark-unaware code, but that's exactly the place where it can't be correct to apply it. -zeframThread Previous | Thread Next