From: Tom Cloyd Date: 2008-03-17T01:08:29+09:00 Subject: Re: argh! more undocumented mysteries: to_yaml Phillip Gawlowski wrote: > Tom Cloyd wrote: >> Documentation? WHAT documentation? Please read my email. >> >> Also, replicate my example in irb - with any object you wish. (I >> tried Array, Fixnum, Float - all raise the same error) >> >> Finally, consider this statement from the general documentation for >> the Class Object at http://www.ruby-doc.org/core/: >> "Object is the >> parent class >> of all >> classes in Ruby. Its methods >> are >> therefore available to all objects unless explicitly overridden." >> >> My problem remains as I stated it. >> >> Thanks for your response, in any case. I will hold out for the >> possibility that with a little more examination you'll see what I >> have so far missed - the reason for this problem. > > You don't use the tools Ruby/irb gives you: > >> Object.methods.sort > => ["<", "<=", "<=>", "==", "===", "=~", ">", ">=", "__id__", > "__send__", "allocate", "ancestors", "autoload", "autoload?", "class", > "class_eval", "class_variable_defined?", "class_variables", "clone", > "const_defined?", "const_get", "const_missing", "const_set", > "constants", "display", "dup", "eql?", "equal?", "extend" > , "freeze", "frozen?", "hash", "id", "include?", "included_modules", > "inspect","instance_eval", "instance_method", "instance_methods", > "instance_of?", "instance_variable_defined?", "instance_variable_get", > "instance_variable_set", "instance_variables", "is_a?", "kind_of?", > "method", "method_defined?", "methods", "module_eval", "name", "new", > "nil?", "object_id", "private_class_method", > "private_instance_methods", "private_method_defined?", > "private_methods", "protected_instance_methods", > "protected_method_defined?", "protected_methods", > "public_class_method", "public_instance_methods", > "public_method_defined?", "public_methods", "respond_to?", "send", > "singleton_methods", "superclass", "taint", "tainted?", "to_a", > "to_s", "type", "untaint"] > > As you can see, the method is not, by default, defined You already > know that the documentation leaves some things desirable, so start > using Google, or Ruby's capabilities of inspection, to narrow down > your mistakes/errors and do some troubleshooting. You'll need these > skills when writing applications, anyway. > > And as an MS/MA you certainly learned research skills at college. If > they've atrophied, now's a good chance to resurrect them, no? > > -- Phillip Gawlowski > > Phillip, good research begins with careful observation - in this case, of the materials at hand. In my immediately previous email I pointed out that the ruby core documentation, for which I gave a reference, so you could check my accuracy (basic scholarly method), tells me that Object#to_yaml should be available to all object unless "explicitly overridden". I then present some cases where it isn't available. That contradiction is what I could not explain. I do not expect such a blatant error/omission/contradiction - or whatever - in the ruby core documentation. If I can't trust what it says about the root object of all objects, then what can I trust? That, to me, looks like a problem - and not exactly one I'd expect Google or some blog entry to solve. Your ">> Object.methods.sort " tip is useful, as is the suggestion that I learn more of Ruby's self-inspection tools. I will pursue this. It didn't occur to me that irb would deny use of this method. That was clearly an erroneous assumption, howsoever reasonable it may have seemed at the time. t. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tom Cloyd, MS MA, LMHC Private practice Psychotherapist Bellingham, Washington, U.S.A: (360) 920-1226 << tc@tomcloyd.com >> (email) << TomCloyd.com >> (website & psychotherapy weblog) << sleightmind.wordpress.com >> (mental health issues weblog) << directpathdesign.com >> (web site design & consultation) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~