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' 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.

Perhaps the use of \x escapes in strings literals should force
a string to be marked as BINARY.  Currently \x escapes only
trigger the BINARY encoding if the bytes are in the range of
80 to FF so that there is no way to force the construction of
a BINARY literal without using force_encoding("BINARY").

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>

Gary Wright