[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Feature proposal: \x## notation in strings
- From: "Rogers, Doug" <Doug.Rogers@...>
- Date: Wed, 11 Mar 2009 15:00:23 -0400
> > It would be interesting to
> > know why decimal ones were chosen in the first place ?
> (Also, we wanted to make easy the encoding of IPs ;)
> -- Roberto
Ah, I had forgotten that reason. I have a vague recollection of hearing
it before. With IPv6 (and Ethernet) we can use that argument for hex! :)
A search through the history of this subject will show my view (and
probably a few more to add to the 20) - I would LOVE hexadecimal escape
sequences in strings. Its lack is a violation of PoLS (Principle of
Least Surprise), which is what made me create and post my own patch back
then (though PoLS wasn't in vogue then!). But such a violation is not
enough to warrant addition to the language.
The first time I looked up information on this issue, I saw that LHF had
provided the X'abcdef0939' answer. And indeed, since I stopped updating
my usual patch, I've employed a similar solution. But it always sticks
in my craw - it always feels like an uncomfortable irritation. But
"sticks in my craw" is also not enough to warrant addition to the
And though Roberto reasonably asks us not to use the "many languages
support it" argument, we should see such arguments for what they are: a
manifestation of the "it is VERY useful" argument. Why is it that so
many languages support hexadecimal escape sequences?
I love Lua's small size but I think the technical merits are enough in
this case. I have always humbly respected (and always will respect) the
authors decisions. Even so, the reluctance to accept hexadecimal escape
sequences into Lua is something I have never understood.
The information contained in this email transmission may contain proprietary and business
sensitive information. If you are not the intended recipient, you are hereby notified that
any review, dissemination, distribution or duplication of this communication is strictly
prohibited. Unauthorized interception of this e-mail is a violation of law. If you are not
the intended recipient, please contact the sender by reply email and immediately destroy all
copies of the original message.
Any technical data and/or information provided with or in this email may be subject to U.S.
export controls law. Export, diversion or disclosure contrary to U.S. law is prohibited.
Such technical data or information is not to be exported from the U.S. or given to any foreign
person in the U.S. without prior written authorization of Elbit Systems of America and the
appropriate U.S. Government agency.