On Aug 12, 2009, at 2:55 PM, Gary Wright wrote:

> On Aug 12, 2009, at 10:12 AM, Gregory Brown wrote:
>>
>> # encoding: UTF-8
>> puts "Welcome to GIF Builder=85"
>>
>> bin_data =3D %b{}
>> bin_data << %b{GIF}
>>
>> Or, if we didn't want new syntax, something like:
>>
>> class String
>> def bin
>>    force_encoding("BINARY")
>> end
>> end
>>
>> However, new syntax would make the strings visually identifiable
>> immediately, helping the programmer spot potential problems.
>> What do you think?
>
> It seems like it is just a quirk of the GIF format that the header
> for a GIF file consists of the ascii codes for 'G', 'I', 'F'

PNG and PDF would face similar issues and those are the formats I am =20
familiar with off the top of my head.

> and that the encoding you used in your example (UTF-8) is ASCII
> compatible.  Your example wouldn't be as persuasive if the source
> file was encoded in UTF-16, for instance.

At this time, I don't believe Ruby supports source code in non-ASCII =20
compatible encodings.

> I like your %b{} suggestion since the string literal could be
> constructed at parse time instead of runtime as with force_encoding
> but your example is dependent on the source encoding. What I
> mean is that your %b{} construct will generate different binary
> strings if the source encoding is changed.  I think it would be
> better to have a literal construct that was not sensitive to
> the source encoding.  Maybe something like:
>
> bin_data =3D %b{71 73 70}   # decimal values of bytes
> bin_data.encoding         # =3D> #<Encoding:ASCII-8BIT>

Interesting idea.  I wish there was a way to keep that and Greg's =20
simple ASCII usage both=85

James Edward Gray II=