scriptorium 0.6.1 → 0.7.2

data/doc/imported/0016-an-in-operator-for-ruby/source.lt3

@@ -0,0 +1,106 @@
+.h1 An 'in' operator for Ruby
+
+.set post.num = 0016
+.set post.slug = an-in-operator-for-ruby
+.set post.date = 2019-11-13
+.set post.title = An 'in' operator for Ruby
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+I have had two fairly small changes I wanted to make in Ruby. The first
+was realized years ago. 
+Hashes now preserve insertion order and iterate in a predictable way.
+That's fairly minor, but it did/does have some use cases, and it had no impact
+on performance.
+
+Here's another one. Personally, this is a bigger thing to me.
+
+I've always believed personally that Ruby should have an in operator.
+
+I've mentioned this in speaking (including lightning talks) and in writing.
+It's not a giant big deal for me, but it is one of my personal favorite ideas.
+Here are some details.
+
+My proposal
+
+I propose to let  x in y be syntax sugar for y.include? x
+
+You may ask: Why?
+
+include? is backwards from common usage -- if the item is our focus, we don't ask whether a group includes an item, but whether an item is in a group. The same is true of a container.
+
+Ruby isn't English; and more generally, programming languages aren't human  languages. But programming languages are based on human languages and on  everyday experience. We do sometimes ask questions like "Does this container  or group include this item?" We are asking a question about the group.     if barrel.include? rotten_apple       # Is barrel going bad?
+
+But we also -- perhaps more often? -- ask questions like "Is this item part of this group?" We are asking a question about the item.      if fruit in [:apple, :pear, :peach]    # Is this fruit something I like?
+
+include? is backwards from mathematical usage -- we ask whether a member is in a set ("epsilon"-like notation), not whether a set contains a memeber.
+
+I ran across someone else a couple of years ago (I wish I could remember who it was!) who bemoaned the absence of this operator. His argument was that he would have a "conversation" with an object, for example, when he tested it repeatedly. Here's a contrived example I just made up.
+
+["    if foo == var1        ||", "       foo =~ var2        ||", "       foo  var5]"]
+
+To quote him as well as I remember: "I was having this perfectly nice conversation 
+with foo, and then var4 interrupted it..."
+
+Better:
+
+["    if foo == var1 ||", "       foo =~ var2 ||", "       foo  var5]"]
+
+I prefer to put the tested entity earlier in the statement:
+
+["    if [GA, VA, MS, TX, MD, NC].include? state      # ehhhh", "    if state in [GA, VA, MS, TX, MD, NC]            # better"]
+
+Also a "variable/constant" issue -- I tend to put the variable data on the 
+      left and the constant on right; this is unlike  people who say if 5 == x. 
+      (After all, 5 is only equal to x very  rarely; 5 is always equal to 5, 
+      even for very large values of 5.)
+
+Also a question of focus: Whatever entity you are really dealing with, 
+      name that one first.
+
+Many languages already have an in operator -- notably Python, Pascal, 
+      even SQL. It is familiar to users of those languages as well as those 
+      who use mathematical notation.
+
+in is already a reserved word in Ruby -- used in the for loop (syntax 
+      sugar for each). Let's increase the justification for its presence.
+
+An in operator would sometimes make parentheses unnecessary:
+
+["   if (10..100).include? x   # Need parens", "   if x in 10..100           # Don't need parens -- also prettier code"]
+
+The newer language Elixir (which I'm happy to report occupies a lot of my 
+      time lately) also sports this operator. This is yet another reason to 
+      love that language.
+
+Frequently Whined Whines
+
+I'd prefer a method. I understand this, but I find it to be 
+      needlessly ugly. I like less punctuation, more whitespace. And I 
+      find this inappropriate for something that is conceptually an operator.
+
+["    if x.in mylist    # ugly   ", "    if x.== 5         # also ugly   ", "    if c1.and c2      # ugly - if it worked    ", "    if x == 5         # better   ", "    if c1 and c2      # better   ", "    if x in mylist    # better"]
+
+I'd prefer a method with a ? on it. I understand 
+      the concept, too, but I find it inappropriate for what is inherently a relational operator.
+
+["     if x.in? my_set   # very ugly   ", "     if x.==? 5         # very ugly - if it worked", "", "     if x in my_set    # natural", "     if x == 5          # natural"]
+
+What about for x in list ? Would this evaluate as  
+      for true  or  for false ? Certainly not. It's a matter 
+      of parsing. The for loop itself is just syntax sugar.
+
+I'll bet you like junctions, too. No, in fact, I dislike junctions greatly. I don't even know Perl. Are junctions still a thing?
+
+If you like SQL's in , you must like not in also.  No, I don't condone its use of "not in":
+
+if item not in collection  # travesty!  if ! (item in collection)  # ok
+
+if x not == y              # horrible Ruby travesty - if it worked    Yes, I say this even though ! ( item in collection) requires parentheses.    See the comment about parentheses on ranges.
+
+What about precedence? I would place in at the same level of precedence as the (other) relational operators  = etc.Conclusion
+
+People have ignored me on this for at least ten years. They probably still will.
+That, as they say, is life.

data/doc/imported/0017-the-forgotten-mathematician/metadata.txt

@@ -0,0 +1,7 @@
+    num  0017
+  title  The Forgotten Mathematician
+   date  2019-12-25
+pubdate  2019-12-25
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0017-the-forgotten-mathematician/post.html

@@ -0,0 +1,161 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>The Forgotten Mathematician</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="The Forgotten Mathematician">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2019-12-25">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>The Forgotten Mathematician</h1>
+      <time datetime="2019-12-25">December 25, 2019</time>
+    </header>
+    
+    <div class="content">
+      <p>
+We all know his name... but many of us only "sort of" know it.
+ 
+<div class='mydrop'>W</div>
+<div style="padding-top: 1px">e all remember Boole in our own way, if at all. His work comes up in discrete
+math and in electrical engineering, among other places. But computer science students and 
+programmers in general remember him chiefly for the Boolean operators and the concept of the 
+Boolean data type.
+
+<p>
+I decided to Google for "who was Boole"... this was the result.
+
+<p>
+<img src='gooboo.png'></img>
+
+<p>
+
+<p>
+Notice the top autocomplete. This seems to suggest that "Boolean" was the person's name. I
+decided to make this blog post to set the record straight. 
+
+<p>
+But that isn't the only reason I'm writing this. I want to speak up for this historical figure
+just a little and correct what I perceive as a minor injustice.
+
+<p>
+Did anything look unusual in the previous sentences? Perhaps the capitalization of "Boolean"?
+It's often lowercased in the computing community, and there are reasonable historical reasons
+for this.
+
+<p>
+In the old days, it was often inconvenient or impossible to type or even to render lowercase
+letters. As recently as the 1980s, I have seen terminals and printers that were strictly uppercase.
+Take a look at a textbook or manual from that era, and you will often see the same thing.
+
+<p>
+On the other hand, people have always known that in English and similar languages, lowercase was
+an essential part of reality. As it became practical to use computers for applications such as
+typesetting and word processing, we started to take mixed case for granted.
+
+<p>
+Somewhere in this time frame (or a little earlier), UNIX came along. And yes, we did spell it 
+in all caps at the time. This was true of most computer language names and such, many of which
+were some kind of acronym or abbreviation: FORTRAN, COBOL, BASIC. There was no particular reason
+to put PASCAL in all caps... but people often did, out of a strange kind of habit.
+
+<p>
+But let's get back to UNIX. Have you ever wondered why we type <font size=+1><tt>ls</tt></font>, <font size=+1><tt>cp</tt></font>, and <font size=+1><tt>mv</tt></font> rather than
+<font size=+1><tt>list</tt></font>, <font size=+1><tt>copy</tt></font>, and <font size=+1><tt>move</tt></font>? It's not just that old terminals could be slow to echo. One of the
+UNIX creators basically <i>hated to type</i>. (I remember it as Brian Kernighan, but it may have been 
+Thompson or Ritchie.) And I argue this laziness also extended to a reluctance to type capital letters. 
+Can you think of a command flag that is capitalized (such as <font size=+1><tt>-F</tt></font>) <i>except</i> where the lowercase
+(such as <font size=+1><tt>-f</tt></font>) was already used by something more fundamental? I can't think of one.
+
+<p>
+So as we made a transition from all-caps to mixed case, programming languages that were traditionally
+written in upper case were now written in all lower case. In Pascal, we might once have written
+<font size=+1><tt>FOR I:=1 TO 10</tt></font>, but a little later, we wrote <font size=+1><tt>for i:=1 to 10</tt></font> instead.
+
+<p>
+Do you see where this is going? Where we once wrote <font size=+1><tt>BOOLEAN</tt></font>, we wrote <font size=+1><tt>boolean</tt></font> instead. And
+because we saw this so often in our programs, we started writing it that way when we wrote <i>about</i>
+our programs.
+
+<p>
+Sometimes this is necessary. If you are using a language where identifiers are case-sensitive (like
+most or all modern languages), there may well be an actual data type named <font size=+1><tt>boolean</tt></font>, and it would
+be an error to capitalize it (even outside our code). 
+
+<p>
+So typography matters here. For many years we have tended to write code in some kind of monospaced
+typeface, harking back to the days when we had no choice in the matter. So consider these three
+sentences, which might appear in any manual or piece of documentation:
+
+<p>
+<ol>
+<li>This function takes a <font size=+1><tt>boolean</tt></font> parameter.</li>
+<li>This function takes a boolean parameter.</li>
+<li>This function takes a Boolean parameter.</li>
+</ol>
+It's reasonable to use lowercase in (1), because we're presumably referring to an actual identifier 
+or reserved word in some language. As for (2) &mdash; I think we see that all the time, but I'm arguing 
+here it's not appropriate. The usage in (3) is more appropriate.
+
+<p>
+Now, before I am misunderstood and/or flamed &mdash; here are the things I am <i>not</i> saying:
+
+<p>
+<ul>
+<li>  I'm not saying we should change the compilers or interpreters.</li>
+<li>  I'm not saying that all the books and manuals should be rewritten.</li>
+<li>  I'm not saying you're ignorant or a bad person if you don't capitalize "Boolean."</li>
+<li>  I'm not saying we should call out people who don't capitalize it.</li>
+</ul>
+But for comparison, let's look at some other scientists and mathematicians whose names have been 
+converted to adjectives. So far I have searched for these: Einsteinian, Newtonian, Galilean, 
+Ptolemaic, Copernican, Wronskian, Laplacian, Lagrangian, Riemannian, Euclidean, Keplerian, 
+Gaussian, Hamiltonian, Archimedean, Diophantine, Pythagorean, Darwinian, Lamarckian, Eulerian,
+Cartesian, Napierian, Bayesian, and Brownian.
+
+<p>
+These terms have this in common: They are <i>always capitalized</i>. (Interestingly, <i>Abelian</i> seems
+to be an exception in many people's usage.) And yes, you may find places where these names are
+<i>not</i> given capital letters, but I contend they are very few in number.
+
+<p>
+Let's range further afield, into the realms of philosophers, religious figures, writers, and 
+artists. I have searched for these: Socratic, Aristotelian, Mosaic, Benedictine, Kafkaesque, 
+Epicurean, Shakespearean, Elizabethan, Edwardian, Spenserian, Petrarchan, Smithsonian, Botticellian, 
+Dickensian, Orwellian, Jungian, Freudian, and Adlerian. I've found very few uncapitalized
+names. The lowercased <i>kafkaesque</i> is not unheard of, and we may informally call someone an 
+<i>epicurean</i> (though we refer specifically to the <i>Epicurean</i> philosophers in uppercase).
+
+<p>
+It's worth noting that units of measure named after people are not capitalized:
+newton, ampere, coulomb, gauss, fermi, kelvin, henry, hertz, pascal, and watt. I can't find an
+exception to this. Sometimes, though, the person's name is tacked on as <i>part</i> of the unit or 
+system of measure; we do capitalize the names when we refer to degrees Fahrenheit, degrees 
+Celsius, Richter scale, Mohs scale, and the Dobson unit. 
+
+<p>
+Of course, in many cases, we just don't convert a name to a different form: Hilbert space, 
+Schwarzschild radius, Feynmann diagram, Bohr model, Fermi principle, Drake equation, Rohrschach
+test, Hall effect, and so on. Why is this so common? I think it's because an adjective form 
+might often be hard to spell or pronounce, and overall we have less of a tendency for "fancy"
+adjectives nowadays. But in any event, we'd never think of lowercasing these names.
+
+<p>
+And yet Boole is shortchanged so often in our world! Mathematicians talk about Boolean algebra, 
+and even electrical engineers talk of Boolean logic; but programmers talk of <i>boolean</i> data and
+<i>boolean</i> operators. 
+
+<p>
+Come on, guys. Give him his due. By the way, his first name was George.
+
+<p>
+So I am making a pledge: Where it's possible and practical, I will capitalize <i>Boolean</i> whenever 
+I write an article, a book, or a piece of documentation. I encourage you to do the same.
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0017-the-forgotten-mathematician/source.lt3

@@ -0,0 +1,119 @@
+.h1 The Forgotten Mathematician
+
+.set post.num = 0017
+.set post.slug = the-forgotten-mathematician
+.set post.date = 2019-12-25
+.set post.title = The Forgotten Mathematician
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+We all know his name... but many of us only "sort of" know it.
+
+W
+e all remember Boole in our own way, if at all. His work comes up in discrete
+math and in electrical engineering, among other places. But computer science students and 
+programmers in general remember him chiefly for the Boolean operators and the concept of the 
+Boolean data type.
+
+I decided to Google for "who was Boole"... this was the result.
+
+Notice the top autocomplete. This seems to suggest that "Boolean" was the person's name. I
+decided to make this blog post to set the record straight.
+
+But that isn't the only reason I'm writing this. I want to speak up for this historical figure
+just a little and correct what I perceive as a minor injustice.
+
+Did anything look unusual in the previous sentences? Perhaps the capitalization of "Boolean"?
+It's often lowercased in the computing community, and there are reasonable historical reasons
+for this.
+
+In the old days, it was often inconvenient or impossible to type or even to render lowercase
+letters. As recently as the 1980s, I have seen terminals and printers that were strictly uppercase.
+Take a look at a textbook or manual from that era, and you will often see the same thing.
+
+On the other hand, people have always known that in English and similar languages, lowercase was
+an essential part of reality. As it became practical to use computers for applications such as
+typesetting and word processing, we started to take mixed case for granted.
+
+Somewhere in this time frame (or a little earlier), UNIX came along. And yes, we did spell it 
+in all caps at the time. This was true of most computer language names and such, many of which
+were some kind of acronym or abbreviation: FORTRAN, COBOL, BASIC. There was no particular reason
+to put PASCAL in all caps... but people often did, out of a strange kind of habit.
+
+But let's get back to UNIX. Have you ever wondered why we type ls, cp, and mv rather than
+list, copy, and move? It's not just that old terminals could be slow to echo. One of the
+UNIX creators basically hated to type. (I remember it as Brian Kernighan, but it may have been 
+Thompson or Ritchie.) And I argue this laziness also extended to a reluctance to type capital letters. 
+Can you think of a command flag that is capitalized (such as -F) except where the lowercase
+(such as -f) was already used by something more fundamental? I can't think of one.
+
+So as we made a transition from all-caps to mixed case, programming languages that were traditionally
+written in upper case were now written in all lower case. In Pascal, we might once have written
+FOR I:=1 TO 10, but a little later, we wrote for i:=1 to 10 instead.
+
+Do you see where this is going? Where we once wrote BOOLEAN, we wrote boolean instead. And
+because we saw this so often in our programs, we started writing it that way when we wrote about
+our programs.
+
+Sometimes this is necessary. If you are using a language where identifiers are case-sensitive (like
+most or all modern languages), there may well be an actual data type named boolean, and it would
+be an error to capitalize it (even outside our code).
+
+So typography matters here. For many years we have tended to write code in some kind of monospaced
+typeface, harking back to the days when we had no choice in the matter. So consider these three
+sentences, which might appear in any manual or piece of documentation:
+
+This function takes a boolean parameter.
+This function takes a boolean parameter.
+This function takes a Boolean parameter.
+
+It's reasonable to use lowercase in (1), because we're presumably referring to an actual identifier 
+or reserved word in some language. As for (2) — I think we see that all the time, but I'm arguing 
+here it's not appropriate. The usage in (3) is more appropriate.
+
+Now, before I am misunderstood and/or flamed — here are the things I am not saying:
+
+I'm not saying we should change the compilers or interpreters.
+  I'm not saying that all the books and manuals should be rewritten.
+  I'm not saying you're ignorant or a bad person if you don't capitalize "Boolean."
+  I'm not saying we should call out people who don't capitalize it.
+
+But for comparison, let's look at some other scientists and mathematicians whose names have been 
+converted to adjectives. So far I have searched for these: Einsteinian, Newtonian, Galilean, 
+Ptolemaic, Copernican, Wronskian, Laplacian, Lagrangian, Riemannian, Euclidean, Keplerian, 
+Gaussian, Hamiltonian, Archimedean, Diophantine, Pythagorean, Darwinian, Lamarckian, Eulerian,
+Cartesian, Napierian, Bayesian, and Brownian.
+
+These terms have this in common: They are always capitalized. (Interestingly, Abelian seems
+to be an exception in many people's usage.) And yes, you may find places where these names are
+not given capital letters, but I contend they are very few in number.
+
+Let's range further afield, into the realms of philosophers, religious figures, writers, and 
+artists. I have searched for these: Socratic, Aristotelian, Mosaic, Benedictine, Kafkaesque, 
+Epicurean, Shakespearean, Elizabethan, Edwardian, Spenserian, Petrarchan, Smithsonian, Botticellian, 
+Dickensian, Orwellian, Jungian, Freudian, and Adlerian. I've found very few uncapitalized
+names. The lowercased kafkaesque is not unheard of, and we may informally call someone an 
+epicurean (though we refer specifically to the Epicurean philosophers in uppercase).
+
+It's worth noting that units of measure named after people are not capitalized:
+newton, ampere, coulomb, gauss, fermi, kelvin, henry, hertz, pascal, and watt. I can't find an
+exception to this. Sometimes, though, the person's name is tacked on as part of the unit or 
+system of measure; we do capitalize the names when we refer to degrees Fahrenheit, degrees 
+Celsius, Richter scale, Mohs scale, and the Dobson unit.
+
+Of course, in many cases, we just don't convert a name to a different form: Hilbert space, 
+Schwarzschild radius, Feynmann diagram, Bohr model, Fermi principle, Drake equation, Rohrschach
+test, Hall effect, and so on. Why is this so common? I think it's because an adjective form 
+might often be hard to spell or pronounce, and overall we have less of a tendency for "fancy"
+adjectives nowadays. But in any event, we'd never think of lowercasing these names.
+
+And yet Boole is shortchanged so often in our world! Mathematicians talk about Boolean algebra, 
+and even electrical engineers talk of Boolean logic; but programmers talk of boolean data and
+boolean operators.
+
+Come on, guys. Give him his due. By the way, his first name was George.
+
+So I am making a pledge: Where it's possible and practical, I will capitalize Boolean whenever 
+I write an article, a book, or a piece of documentation. I encourage you to do the same.

data/doc/imported/0018-ruby-puns/metadata.txt

@@ -0,0 +1,7 @@
+    num  0018
+  title  Ruby puns
+   date  2020-01-21
+pubdate  2020-01-21
+  views  computing computing
+   tags  
+ pinned  

data/doc/imported/0018-ruby-puns/post.html

@@ -0,0 +1,46 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Ruby puns</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Ruby puns">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2020-01-21">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Ruby puns</h1>
+      <time datetime="2020-01-21">January 21, 2020</time>
+    </header>
+    
+    <div class="content">
+      <p>
+These are pretty bad. You've been warned.
+
+<p>
+<pre>
+    cheese = ""           # String cheese
+    browns = {}           # Hash browns
+    hiphip   = []         # hiphip array
+    case; end             # brief case
+    foods.freeze          # frozen foods
+    love.taint            # tainted love
+    attr_writer :irish    # Irish setter
+    {"corned" => "beef"}  # corned beef hash
+    raise "hell"          # raising hell
+    $village              # global village 
+    
+    usual_suspects = 1.99
+    usual_suspects.ceil      # round up the usual suspects
+    
+    class JesusChrist < God
+      super(*)               # Jesus Christ Superstar
+    end
+</pre>
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0018-ruby-puns/source.lt3

@@ -0,0 +1,28 @@
+.h1 Ruby puns
+
+.set post.num = 0018
+.set post.slug = ruby-puns
+.set post.date = 2020-01-21
+.set post.title = Ruby puns
+.set post.tags = 
+.set post.views = computing computing
+.set post.published = yes
+.set post.deployed = no
+
+These are pretty bad. You've been warned.
+
+cheese = ""           # String cheese
+    browns = {}           # Hash browns
+    hiphip   = []         # hiphip array
+    case; end             # brief case
+    foods.freeze          # frozen foods
+    love.taint            # tainted love
+    attr_writer :irish    # Irish setter
+    {"corned" => "beef"}  # corned beef hash
+    raise "hell"          # raising hell
+    $village              # global village
+
+usual_suspects = 1.99
+    usual_suspects.ceil      # round up the usual suspects
+
+class JesusChrist

data/doc/imported/0019-custom-exceptions-via-metaprogramming/metadata.txt

@@ -0,0 +1,7 @@
+    num  0019
+  title  Custom exceptions via metaprogramming
+   date  2020-02-17
+pubdate  2020-02-17
+  views  computing computing
+   tags  
+ pinned  

data/doc/imported/0019-custom-exceptions-via-metaprogramming/post.html

@@ -0,0 +1,138 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Custom exceptions via metaprogramming</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Custom exceptions via metaprogramming">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2020-02-17">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Custom exceptions via metaprogramming</h1>
+      <time datetime="2020-02-17">February 17, 2020</time>
+    </header>
+    
+    <div class="content">
+      <p>
+Suppose you want a large number of custom exceptions. And suppose you're not afraid of metaprogramming.
+A few months back, I found myself wanting to be "more specific" with the exceptions
+I raised in my ongoing RuneBlog project (which is used to create this blog). I
+wanted to raise specific exceptions with custom parameterized messages (without
+repeating myself too much).
+
+<p>
+Here's an example of the "usual" way to do this:
+
+<p>
+<div class="highlight">
+<span class="k">class</span> <span class="nc">MyException</span> <span class="o">&lt;</span> <span class="no">StandardError</span>
+
+  <span class="k">def</span> <span class="nf">initialize</span><span class="p">(</span><span class="n">file</span><span class="p">,</span> <span class="n">dir</span><span class="p">)</span>
+    <span class="n">msg</span> <span class="o">=</span> <span class="s2">"Could not find </span><span class="si">#{</span><span class="n">file</span><span class="si">}</span><span class="s2"> under </span><span class="si">#{</span><span class="n">dir</span><span class="si">}</span><span class="s2">"</span>
+    <span class="k">super</span><span class="p">(</span><span class="n">msg</span><span class="p">)</span>
+  <span class="k">end</span>
+
+<span class="k">end</span>
+
+<span class="k">raise</span> <span class="no">MyException</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="s2">"stuff.txt"</span><span class="p">,</span> <span class="s2">"/home/willard"</span><span class="p">)</span>
+
+<span class="c1"># Output:</span>
+<span class="c1"># exc.rb:10:in `&lt;main&gt;': Could not find stuff.txt under /home/willard (MyException)</span>
+</div>
+<br>
+Now there is nothing particularly wrong with that. But as it happens, I wanted a 
+large number of exceptions with fairly descriptive names. I didn't want to type
+(or even paste) this stuff over and over.
+
+<p>
+Here comes the "not afraid of metaprogramming" part. This is what I did:
+
+<p>
+<div class="highlight">
+<span class="k">def</span> <span class="nf">make_exception</span><span class="p">(</span><span class="n">sym</span><span class="p">,</span> <span class="n">str</span><span class="p">,</span> <span class="n">target_class</span> <span class="o">=</span> <span class="no">Object</span><span class="p">)</span>
+  <span class="k">return</span> <span class="k">if</span> <span class="n">target_class</span><span class="p">.</span><span class="nf">constants</span><span class="p">.</span><span class="nf">include?</span><span class="p">(</span><span class="n">sym</span><span class="p">)</span>
+  <span class="n">target_class</span><span class="p">.</span><span class="nf">const_set</span><span class="p">(</span><span class="n">sym</span><span class="p">,</span> <span class="no">StandardError</span><span class="p">.</span><span class="nf">dup</span><span class="p">)</span>
+  <span class="n">define_method</span><span class="p">(</span><span class="n">sym</span><span class="p">)</span> <span class="k">do</span> <span class="o">|*</span><span class="n">args</span><span class="o">|</span>
+    <span class="n">msg</span> <span class="o">=</span> <span class="n">str</span><span class="p">.</span><span class="nf">dup</span>
+    <span class="n">args</span><span class="p">.</span><span class="nf">each</span><span class="p">.</span><span class="nf">with_index</span> <span class="p">{</span><span class="o">|</span><span class="n">arg</span><span class="p">,</span> <span class="n">i</span><span class="o">|</span> <span class="n">msg</span><span class="p">.</span><span class="nf">sub!</span><span class="p">(</span><span class="s2">"%</span><span class="si">#{</span><span class="n">i</span><span class="o">+</span><span class="mi">1</span><span class="si">}</span><span class="s2">"</span><span class="p">,</span> <span class="n">arg</span><span class="p">)</span> <span class="p">}</span>
+    <span class="n">target_class</span><span class="p">.</span><span class="nf">class_eval</span><span class="p">(</span><span class="n">sym</span><span class="p">.</span><span class="nf">to_s</span><span class="p">).</span><span class="nf">new</span><span class="p">(</span><span class="n">msg</span><span class="p">)</span>
+  <span class="k">end</span>
+<span class="k">end</span>
+</div>
+<br>
+Now, what does this do? The method takes two parameters (or three if you count the
+target class which defaults to <font size=+1><tt>Object</tt></font>). You specify a symbol (for the
+name of the exception) and a string (for the exception message). It then does
+two things: It creates an exception class (named after the symbol); and it creates
+a method of the same name.
+
+<p>
+Here are examples of calling <font size=+1><tt>make_exception</tt></font>:
+
+<p>
+<div class="highlight">
+<span class="n">make_exception</span><span class="p">(</span><span class="ss">:NotImplemented</span><span class="p">,</span> <span class="s2">"Feature not yet implemented"</span><span class="p">)</span>
+<span class="n">make_exception</span><span class="p">(</span><span class="ss">:CantOpen</span><span class="p">,</span>       <span class="s2">"Can't open '%1'"</span><span class="p">)</span>
+<span class="n">make_exception</span><span class="p">(</span><span class="ss">:InternalError</span><span class="p">,</span>  <span class="s2">"Internal error: Method %1 got arg '%2'"</span><span class="p">)</span>
+</div>
+<br>
+And here are examples of raising these exceptions:
+
+<p>
+<div class="highlight">
+<span class="k">raise</span> <span class="no">NotImplemented</span>
+<span class="k">raise</span> <span class="no">CantOpen</span><span class="p">(</span><span class="n">somefile</span><span class="p">)</span>
+<span class="k">raise</span> <span class="no">InternalError</span><span class="p">(</span><span class="n">__method__</span><span class="p">,</span> <span class="n">arg</span><span class="p">)</span>
+</div>
+<br>
+You might ask: Why define a method returning an exception object? The answer
+is that I don't want to write these this way:
+
+<p>
+<div class="highlight">
+<span class="k">raise</span> <span class="no">NotImplemented</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="s2">"Feature not yet implemented"</span><span class="p">)</span>
+<span class="k">raise</span> <span class="no">CantOpen</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="s2">"Can't open '</span><span class="si">#{</span><span class="n">somefile</span><span class="si">}</span><span class="s2">'"</span><span class="p">)</span>
+<span class="k">raise</span> <span class="no">InternalError</span><span class="p">.</span><span class="nf">new</span><span class="p">(</span><span class="s2">"Internal error: Method </span><span class="si">#{</span><span class="n">__method__</span><span class="si">}</span><span class="s2"> got arg '</span><span class="si">#{</span><span class="n">arg</span><span class="si">}</span><span class="s2">'"</span><span class="p">)</span>
+</div>
+<br>
+I perceive four advantages doing it the first way: I don't have to specify the 
+message string each time; I still get to have a descriptive, unique class name
+without the message making it seem redundantly; I don't have to interpolate
+values into the message string explicitly; and I don't have to say <font size=+1><tt>.new</tt></font> 
+every time.
+
+<p>
+Some of you may have two questions: Can you (or should you) really have a 
+capitalized method name? Can a method have the same name as a class without
+confusing the interpreter?
+
+<p>
+I'll answer both those questions with an example from the Ruby core: There
+is an <font size=+1><tt>Integer</tt></font> class and an <font size=+1><tt>Integer</tt></font> method (naturally related to each other).
+Ruby distinguishes between these by context. It's not impossible, and I argue
+it's not a bad practice.
+
+<p>
+As for the parameters, it's intuitive how they work. A <font size=+1><tt>%</tt></font> sign signals a 
+numbered replaceable piece of text, and these are replaced with the parameters
+specified when the method is called. 
+
+<p>
+That part of the code is not really robust, by the way. As it is written now,you could easily confuse it-- make it misbehave or crash. But you get the idea.
+
+<p>
+So far, I have defined 23 custom exceptions in this project. Each definition
+occupies a single line. If I want to change the behavior of all of them in
+some way, I will go and change the <font size=+1><tt>make_exception</tt></font> method (which itself is
+only 9 lines).
+
+<p>
+Like it, hate it? Comments welcome.
+    </div>
+  </article>
+</body>
+</html>