[xen-tools] Re: More changes

[Steve Kemp]

On Wed Sep 05, 2007 at 07:03:55 -0700, C.J. Adams-Collier wrote:

> I personally find it a useful thing to do.  apt-get install xen-tools
> is nice, but it would like to be able to use this module from other
> distributions.

  And that's one of reasons why I'm not keen on the Moose overhead.
  Right now I use the minimum of modules required...

> I don't want to cause fragmentation or overhead.  Let me know where
> the problem is and I'll try to address it.  The new Build.PL and your
> Makefile are not mutually exclusive.  They should both be able to
> function separately with no problem.

  Really the problem is that people don't read documentation, so
 seeing lots of things in the top-level directory will confuse them.
 (Seriously!)

  Given that I don't believe the general audience  would benefit
 from more than "make install" I think they clutter things unduly,
 moving them into ./misc/ for people who wanted them would satisfy
 me - as I could then pretend it didn't exist.

> Well, Moose provides an object model that is becoming standard as well
> as some fancy features like an argument validation system, object
> attribute constructors and class creation helpers.  It reduces the
> KLOCs substantially and IMHO, makes the code much cleaner.

  I'm not seeing a clear benefit there.  Standard perl OO doesn't
 seem too bad, given the small number of classes and loose inheritence
 we'll be having.

> Another benefit is that I expect to write the C binding using the
> Moose object model.  The Moose and glib object models are similar
> enough that it should be easy to write a c -> Moose caller library
> relatively easily.  This would open all classes that inherit from
> Moose to being called from C.  Python, Perl, C++, C# and basically
> everything else can call C, which means that they would be able to
> call Moose object methods without the overhead of process context
> creation.  Rolling our own object model (or worse, doing it ad hoc)
> would make it much more difficult to write xen-tools apps in different
> languages than Perl.

  I guess that is a valid point, but in practise is it a huge problem?
  With things like swig I think that the problem shouldn't be difficult
 either way.

   I was picturing a much simpler system with standard constructors
 something like this:

=begin doc

  Create a new instance of this object.

=end doc

=cut

sub new
{
    my ( $proto, %supplied ) = (@_);
    my $class = ref($proto) || $proto;

    my $self  = {};

    #
    #  Allow user supplied values to override our defaults
    #
    foreach my $key ( keys %supplied )
    {
    $self->{ lc $key } = $supplied{ $key };
    }

    bless ($self, $class);
    return $self;

}

   I'm assuming that we'll have test cases for all the new classes
 we're putting in, so we'd easily be able to catch bugs, or problems.

  I've commited everything you've supplied so far *except* the build
 stuff.  Tonight I'll add a 'Xen::Tools::Configuration' class, or
 similar to centralise the use of the configuration file parsing,
 and I'll do that in the standard way so you can compare and contrast.
 If you think you could live with the "old" way I'd be much pleased :)

Steve
--