[SUMMARY] AnsiString (#185)

It would seem that writing Transfire's desired `ANSIString` class is =20
more difficult that it appears. (Or, perhaps, y'all are busy preparing =20=

for the holidays.) The sole submission for this quiz comes from =20
_Robert Dober_; it's not completely to specification nor handles the =20
bonus, but it is a good start. (More appropriately, it might be better =20=

to say that the specification isn't entirely clear, and that Robert's =20=

implementation didn't match *my* interpretation of the spec; a proper =20=

`ANSIString` module would need to provide more details on a number of =20=

things.)

Robert relies on other libraries to provide the actual ANSI codes; =20
seeing as there are at least three libraries that do, Robert provides =20=

a mechanism to choose between them based on user request and/or =20
availability. Let's take a quick look at this mechanism. (Since this =20
quiz doesn't use the Module mechanism in Robert's `register_lib` =20
routine, I've removed the related references for clarity. I suspect =20
those are for a larger set of library management routines.)

	@use_lib =3D
	  ( ARGV.first =3D=3D '-f' || ARGV.first =3D=3D '--force'  ) &&
	    ARGV[1]
=09
     def register_lib lib_path, &blk
       return if @use_lib && lib_path !=3D @use_lib
       require lib_path
       Libraries[ lib_path ] =3D blk
     end

     register_lib "facets/ansicode" do | color |
       ANSICode.send color
     end

	# similar register_lib calls for "highline" and "term/ansicolor"

	class ANSIString
	  used_lib_name =3D Libraries.keys[ rand( Libraries.keys.size ) =
]
	  lib =3D Libraries[ used_lib_name ]
	  case lib
	  when Proc
	    define_method :__color__, &lib
	  else
	    raise RuntimeError, "Nooooo I have explained exactly how to =20=

register libraries, has I not?"
	  end

	  # ... rest of ANSIString ...
	end
=09
First, we check if the user has requested (via `--force`) a particular =20=

library. This is used in the first line of `register_lib`, which exits =20=

early if we try to register a library other than the one specified. =20
Then `register_lib` loads the matching library (or all if the user did =20=

not specify) via `require` as is typical. Finally, a reference to the =20=

provided code block is kept, indexed by the library name.

This seems, perhaps, part of a larger set of library management =20
routines; its use in this quiz is rather simple, as can be seen in the =20=

calls to `register_lib` immediately following. While registering =20
"facets/ansicode", a block is provided to call `ANSICode.send color`. =20=

This is then used below in `ANSIString`, when we choose one of the =20
libraries to use, recall the corresponding code block, and define a =20
new method `__color__` that calls that code block.

Altogether, this is a reasonable technique for putting a fa=E7ade around =
=20
similar functionality in different libraries and choosing between =20
available libraries, perhaps if one or another is not available. It =20
seems to me that such library management =96 at least the general =20
mechanisms =96 might be worthy of its own gem.

Given that we now have a way to access ANSI codes via =20
`ANSIString#__color__`, let's now move onto the code related to the =20
task, starting with initialization and conversion to `String`:

	class ANSIString
	  ANSIEnd    =3D "\e[0m"

	  def initialize *strings
	    @strings =3D strings.dup
	  end

	  def to_s
	    @strings.map do |s|
	      case s
		  when String
		    s
		  when :end
		    ANSIEnd
		  else
		    __color__ s
		  end
		end.join
       end
	end
=09
Internally, `ANSIString` keeps an array of strings, its initial value =20=

set to a copy of the initialization parameters. So we can create ANSI =20=

string objects in a couple of ways:

	s1 =3D ANSIString.new "Hello, world!"
	s2 =3D ANSIString.new :green, "Merry ", :red, "Christmas!", :end
=09
When converting with `to_s`, each member of that array is =20
appropriately converted to a `String`. It is assumed that members of =20
the array are either already `String` objects (so are mapped to =20
themselves), the `:end` symbol (so mapped to constant string =20
`ANSIEnd`), or appropriate color symbols available in the previously =20
loaded library (mapped to the corresponding ANSI string available =20
through method `__color__`). Once all items in the array are converted =20=

to strings, a simple call to `join` binds them together into one, =20
final string.

Let's look at string concatenation:

	class ANSIString
	  def + other
	    other.add_reverse self
	  rescue NoMethodError
	    self.class::new( *( __end__ << other ) )
	  end

	  def add_reverse an_ansi_str
	    self.class::new( *(
	      an_ansi_str.send( :__end__ ) + __end__
	    ) )
	  end

	  private
	  def __end__
	    @strings.reverse.find{ |x| Symbol =3D=3D=3D x} =3D=3D :end ?
	      @strings.dup : @strings.dup << :end
	  end
	end

Before we get to the concatenation itself, take a quick look at helper =20=

method `__end__`. It looks for the last symbol and compares it against =20=

`:end`. Whether true or false, the `@string` array is duplicated (and =20=

so protects the instance variable from change). Only, `__end__` does =20
not append another `:end` symbol if unnecessary.

I was a little confused, at first, about the implementation of =20
`ANSIString` concatenation. Perhaps Robert had other plans in mind, =20
but it seemed to me this work could be simplified. Since `add_reverse` =20=

is called nowhere else (and I couldn't imagine it being called by the =20=

user, despite the public interface), I tried inserting `add_reverse` =20
inline to `+` (fixing names along the way):

	def + other
       other.class::new( *(self.send(:__end__) + other.__end__) )
	rescue NoMethodError
	  self.class::new( *( __end__ << other ) )
	end

And, with further simplification:

	def + other
	  other.class::new( *( __end__ + other.send(:__end__) ) )
	rescue NoMethodError
	  self.class::new( *( __end__ << other ) )
	end

I believed Robert had a bug, neglecting to call `__end__` in the =20
second case, until I realized my mistake: `other` is not necessarily =20
of the `ANSIString` class, and so would not have the `__end__` method. =20=

My attempt to fix my mistake was to rewrite again as this:

	def + other
	  ANSIString::new( *( __end__ + other.to_s ) )
	end
=09
But that has its own problems if `other` *is* an `ANSIString`; it =20
neglects to end the string and converts it to a simple `String` rather =20=

than maintaining its components. Clearly undesirable. Obviously, =20
Robert's implementation is the right way... or is it? Going back to =20
this version:

	def + other
	  other.class::new( *( __end__ + other.send(:__end__) ) )
	rescue NoMethodError
	  self.class::new( *( __end__ << other ) )
	end

Ignoring the redundancy, this actually works. My simplification will =20
throw the `NoMethodError` exception, because `String` does not define =20=

`__end__`, just as Robert's version throws that exception if either =20
`add_reverse` or `__end__` is not defined. So, removing redundancy, I =20=

believe concatenation can be simplified correctly as:

	def + other
		self.class::new( *(
			__end__ + (other.send(:__end__) rescue [other] )
		) )
	end

For me, this reduces concatenation to something more quickly =20
understandable.

One last point on concatenation; Robert's version will create an =20
object of class `other.class` if that class has both methods =20
`add_reverse` and `__end__`, whereas my simplification does not. =20
However, it seems unlikely to me that any class other than =20
`ANSIString` will have those methods. I recognize that my assumption =20
here may be flawed; Robert will have to provide further details on his =20=

reasoning or other uses of the code.

Finally, we deal with adding ANSI codes to the ANSI strings (aside =20
from at initialization):

	class ANSIString
	  def end
	    self.class::new( * __end__ )
	  end

	  def method_missing name, *args, &blk
	    super( name, *args, &blk ) unless args.empty? && blk.nil?
	    class << self; self end.module_eval do
	      define_method name do
	  		self.class::new( *([name.to_sym] + =
@strings).flatten )
	      end
	    end
	    send name
	  end
	end
=09
Method `end` simply appends the symbol `:end` to the `@strings` array =20=

by making use of the existing `__end__` method. Reusing `__end__` (as =20=

opposed to just doing `@strings << :end`) ensures that we don't have =20
unnecessary `:end` symbols in the string.

Finally, `method_missing` catches all other calls, such as `bold` or =20
`red`. Any calls with arguments or a code block are passed up first to =20=

the superclass, though considering the parent class is `Object`, any =20
such call is likely to generate a `NoMethodError` exception (since, if =20=

the method was in `Object`, `method_missing` would not have been =20
called). Also note that whether "handled" by the superclass or not, =20
all missing methods are *also* handled by the rest of the code in =20
`method_missing`. I don't know if that is intentional or accidental. =20
In general, this seems prone to error, and it would seem a better =20
tactic either to discern the ANSI code methods from the loaded module =20=

or to be explicit about such codes.

In any case, calling `red` on `ANSIString` the first time actually =20
generates a new method, by way of the `define_method` call located in =20=

`method_missing`. Further calls to `red` (and the first call, via the =20=

last line `send name`) will actually use that new method, which =20
prepends `red.to_sym` (that is, `:red`) to the string in question.

At this point, `ANSIString` handles basic initialization, =20
concatenation, ANSI codes and output; it does not handle the rest of =20
the capabilities of `String` (such as substrings, `gsub`, and others), =20=

so it is not a drop-in replacement for strings. I believe it could be, =20=

with time and effort, but that is certainly a greater challenge than =20
is usually attempted on Ruby Quiz.