Re: Managing metadata about attribute types

On Wed, 5 Nov 2003 13:27:05 +0900, Simon Kitching wrote:
> On Wed, 2003-11-05 at 17:09, Austin Ziegler wrote:
> One of the goals of xmldigester is to be able to instantiate and
> initialise objects from some input xml without making any changes
> to the classes themselves.

> Thus if you already have a library of warehouse management
> classes, I can write some rules that can take an xml description
> of the contents of that warehouse and build appropriately
> configured objects without changing that library. And once the
> parsing is complete, the resulting tree of objects should look no
> different than one created using normal calls to the library API.

You're right, they shouldn't. But if your warehouse management
classes don't do what they can to ensure their data integrity, then
there's a problem with the classes -- not with the XML library. I'm
not trying to be difficult here; just pointing out that I think
you're trying to fix the problem from the wrong end.

> In addition, the approach you suggest is quite labour-intensive;
> for every attribute, a "wrapper" method needs to be written.

Not really. See below for one option. The way that I've implemented
this makes it easy to drop into place.

> I feel Ryan's MetaTags approach is easier to use; a simple string
> format can be used to document the types to which strings from the
> xml input should be converted before assignment to various
> attributes.

Ryan's MetaTags really does not do anything different than I'm
talking about except that it could can it (although I think
StrongTyping does that better). See, you can make a simple
metamethod that wraps this for you and it becomes a relatively
simple change to make it "simple." If you don't want to create a
method for each, define a proc and use the following extension to
attr_accessor. (Does anyone else think that this is a good idea? I
do. I'd love to see it become part of "standard" Ruby.)

  class Module
    alias_method :__attr_accessor, :attr_accessor

    def attr_accessor(block, *symbols)
      if block.kind_of?(Symbol)
        symbols.unshift(block)
        __attr_accessor(*symbols)
      else
        symbols.each do |get|
          var =3D "@#{get}"
          set =3D "#{get}=3D".intern
          self.class_eval do
            define_method(get) { self.instance_variable_get(var) }
            define_method(set) { |*val|
              self.instance_variable_set(var, block.call(*val))
            }
          end
        end
      end
    end
  end

  class Foo
    attr_accessor :item
    attr_accessor proc { |x| x.to_i }, :item_id
    attr_accessor proc { |x| x.to_f }, :cost
  end

  f =3D Foo.new
  f.item    =3D "item"
  f.item_id =3D "37352"
  f.cost    =3D "12.50"
  p f.inspect

(I've actually attached a further enhanced and unit-tested version
of this extension to this message. If anyone wants to add to the
test cases, such as for array parameters, feel free.)

On Wed, 5 Nov 2003 14:06:55 +0900, Simon Kitching wrote:
>> As you can see, any code that that relies on this kind of "type
>> checking" in Ruby is naive. Worse than that, the desire to
>> shoe-horn Ruby into Java-like "strictness" can blind the user
>> into missing the point, and therefore the full benefit, of what
>> Ruby has to offer.
> Yep. I can't see how to offer what I want without some type info,
> though.
> 
> If you look at my original example, how to I know that
>     item.cost =3D '3.50'
> is wrong (the instance will eventually trigger some error), and
>     item.cost =3D '3.50'.to_f
> is the right thing to do?
> 
> With Java it just happens magically and "does the right thing"
> (except in the abstract type case mentioned above). Surely Ruby
> can't be inferior :-).

It isn't inferior, and you don't need type info. Remember -- an
object should validate or transform its own data. Using the method I
described above, it becomes "cheap" to fix the problem as I see it
without imposing a requirement for the use of type strictness that
IMO, is a really bad idea for a Ruby library.

> Yep. Tedious indeed. And as mentioned in my reply to Austin, it is a goal
> to instantiate and initialise objects without requiring any changes to
> their code. Digester manages this fine.

Digest manages this because the objects in Java automatically take
care of their own type. Sort of. The compiler prevents you from
using any type except those that are signaled. If you have not
massaged your own type attributes to make sure that they are
receiving valid data, then there's something wrong with the classes
themselves. NOT with Ruby for not providing type strictness.

In several libraries I've written, I have either rejected types that
I can't handle, or I have transformed types into what I can handle,
or I have operated on the data and thrown an error because it can't
be handled. I prefer being proactive, so I choose the former two
methods most often.

> The problem is : in order to automatically generate the filters, I need
> to know what type of object is required for each attribute. Full circle!

Again, not really. The class you're building has to know what it
expects. It's an inverse of what you'd expect from a statically
typed language, but I have found it easier to understand in the long
run.

> That code in the Person class you show above could only be generated
> because a human "knew" that Integer was an appropriate type to store into
> the age attribute (and String was not). I just want to represent that
> info in the code somehow...

But defining the Person class to convert its "age" parameter into an
Integer does exactly that. Not as meta-data, to be sure, but in the
only way that matters, IMO.

-austin
--
austin ziegler    * [e-mail] * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.05
                                         * 02.12.59