When I first started here, our project manager commented to me that when she programs in C#, she can just "click a box on a page" to make the sort of XML changes we often find laborious. Last night, my soon to be erstwhile housemate also commented that when he does C#, he just needs to specify a set of mappings in a config file. Schemas, XML, JSON and anything else he wants just happens. It's magic!
Now I know a lot of people sneer at this "magic" attitude, but those people would be wrong and my project manager and housemate are right. This is such a common problem that it deserves its own abstraction layer. If you're generating XML by hand, you're doing it wrong. If you're using libraries like XML::LibXML, there's still a good chance you're doing it wrong. As an analogy, if you're developing on an MVC codebase, you know your database handles don't belong in your controller or view. They belong in your model. In MVC, XML generators probably don't belong in your controller or model, they belong in your view and you shouldn't have to write them.
Why is it that other languages have had Bermuda-like functionality built-in to their toolsets for years and we don't? Perl doesn't earn many bragging rights here.
Practically the only time I have to touch XML in Perl is when interfacing with somebody else system.
Re:XML is for non-scripting
Ovid on 2008-01-25T13:00:34
Practically the only time I have to touch XML in Perl is when interfacing with somebody else system.True. That's the situation I routinely find myself in. We work with many outside groups and XML is the de facto data interchange format.
With Bermuda, I would have found this much easier to handle if we had proper introspection. I could write a quick "stub" of a Bermuda island file like this pseudo Perl 6 code:
print YAML <<"END";
class: $class
name: $class.key
for: iPlayer # allow different uses for the same class
elements:
END
for $class.HOW.properties('public') -> {
next unless my $accessor = $property.accessor;
my $property_name = $property.name;
my $accessor_name = $accessor.name;
my $type = $property.type// 'string';
if !$accesor.signature.returns('SCALAR') {
$property_name.= '*';
}
print YAML <<" END";
- $property_name
- type: $type
method: $attribute_name
END
}And then the programmer could go in an convert elements to attributes, add arbitrary attributes, or customize it to their heart's content. Or just take the default and run with it. Right now we have to do it the hard way
:/ Re:XML is for non-scripting
Stevan on 2008-01-25T15:33:15
Perhaps while you are waiting for Perl 6, you should look at MooseX::Storage, it doesn't have an XML backend, but thats mostly cause we haven't had the need for it (if you can choose a schema it would be trivial).
- Stevan
Re:XML is for non-scripting
Ovid on 2008-01-25T16:52:22
That does look very interesting. I had also thought that in later stages of Bermuda, I'd want to have optional Moose hooks. They shouldn't be too hard to add
:) Re:XML is for non-scripting
Stevan on 2008-01-25T18:10:30
Actually it seems that Bermuda is somewhat redundant with MooseX::Storage (ignoring the fact MX::Storage only works with Moose classes for the moment). I wonder if pooling our efforts might not make sense? Interested?
- Stevan
Re:XML is for non-scripting
Ovid on 2008-01-26T10:23:12
Not just yet. For one thing, I refuse to release this until I feel much more comfortable with the design. I've screwed up with this in the past and I'm not anxious to code myself into a corner. I also am being strongly driven to solve an immediate need at the BBC, so I do need to stay focused on that right now.
Re:C# Boasts
Ovid on 2008-01-25T13:45:04
I think a lot of it is in the language. Perl has grown up and unfortunately it's still in the clothes it wore as a teenager and they don't fit well. Many of the things the C# and Java communities can do work because the languages have a regular syntax and introspection.
Re:C# Boasts
Stevan on 2008-01-25T15:37:20
Many of the things the C# and Java communities can do work because the languages have a regular syntax and introspectionHonestly, this is where TIMTOWTDI failed us, it is a double edged sword of flexibility and inconsistency.
- Stevan
Re:C# Boasts
chromatic on 2008-01-25T19:20:49
Many of the things the C# and Java communities can do work because the languages have a regular syntax and introspection.Similarly, many of the things the C# and Java communities have to do (in particular, dependency injection governed by voluminous XML configuration files) is because the languages have other inflexibilities.
Re:C# Boasts
Ovid on 2008-01-26T10:03:31
Oh, I certainly agree with that. Doesn't mean I don't want to steal the shiny bits
:) Re:C# Boasts
Aristotle on 2008-01-27T08:44:28
I think the obvious moral equivalent to static introspection in static languages is dynamic programming (open classes, closures,
eval) in dynamic languages. Instead of clicking buttons in an IDE that generates code for you, you write code against an API that abstracts away a bunch of metaprogramming. The difference is that you are not limited by your tools in how far and fast you can go because you can always abstract out further from the basis you start with.Of course, the flipside is that it’s expedient for 100 projects to write only the 1/15th of the abstraction functionality that for their own needs require, so in the end there’s a lot of partial duplication of work spread around and no one has a single rock-solid tool available to bootstrap future work. To a smaller extent, it is the problem Lisp faces.
Re:Why corporate-backed language have great XML
cbrandtbuffalo on 2008-01-25T17:03:13
Looks like someone is working on a fresher implementation:
http://use.perl.org/article.pl?sid=07/11/29/1432250
