Support Scala's getters and setters

[GoogleCodeExporter]

It would make SnakeYAML more convenient for Scala users if it could check for 
the Scala convention for setters and geaters.

That is, currently to use SnakeYAML with Scala, Scala users must put 
@BeanProperty in front of each field they want to be able to read into from a 
YAML file. The presence of this annotation causes Scala to turn a field named 
"foo" into a pair of getters and setters "getFoo" and "setFoo", which SnakeYAML 
then recognizes as a getter/setter pair.

Scala already creates a getter-setter pair, however, just with different names. 
The names are "foo" and "foo_$eq". How much trouble would it be for SnakeYAML 
to check for this additional convention for getter-setter pairs?

Original issue reported on code.google.com by lexsp...@gmail.com on 5 Sep 2012 at 9:37

[GoogleCodeExporter]

The current SnakeYAML API must be refactored to separate 3 API layers
1) low level API -> to produce  a representation graph 
(http://yaml.org/spec/1.1/#id860452). This is to support tools (JRuby, 
http://code.google.com/p/yedit/) or those who wish speed and efficiency
2) standard types (String, Integer, List, Map etc) -> for those who want a 
custom way to create a busyness object
3) hierarchy of stateful objects (type inference, a lot of artificial 
intelligence) -> when users expect magic to happen

Scala API may share a lot (if not everything) with the first two levels, but 
not the last. It may cause too much misunderstanding.
When Scala 2.10 is out we may have a look at the reflection API.
We are open to consider any proposals to improve the current Scala support.

Original comment by py4fun@gmail.com on 6 Sep 2012 at 7:47

• Changed state: Accepted

[GoogleCodeExporter]

Okay, instead of explaining further how about I show what I mean with a patch! 
Attached is a patch that implements the feature I requested. If it can be 
included, it would make Scala development go more smoothly. I have verified 
that it does the right thing on my project.

Original comment by lexsp...@gmail.com on 6 Sep 2012 at 10:28

Attachments:

• scalaField.diff

[GoogleCodeExporter]

thx for the patch. I would not include it as it is. My reason - it belongs to 
kind of "extension" not "core".
But it's only my opinion.

Maybe something like this would be better (see attachment)?
It will not be automatic, but ...

{code}
val constructor = new Consturtor()
constructor.getPropertyUtils().addPropertiesProvider(new 
ScalaPropertiesProvider())
val yaml = new Yaml(constructor)
{code}

what do you think?

Original comment by alexande...@gmail.com on 7 Sep 2012 at 7:40

Attachments:

• propertiesProvider.patch

[GoogleCodeExporter]

In my opinion, *basic* Scala support is worth including in the core product. 
It's easy to do, and it won't harm the pure Java users.

More broadly, extension points are not a good thing. They imply work for the 
user to get the tool configured for their needs.

Original comment by lexsp...@gmail.com on 7 Sep 2012 at 3:39

[GoogleCodeExporter]

Our challenge is that users try to create different data structures out of the 
same YAML documents. By default SnakeYAML cannot satisfy all the expectations. 
It is more flexible to force users to configure the tool to their needs because 
they know the context. 

Original comment by py4fun@gmail.com on 27 Sep 2012 at 8:15

[GoogleCodeExporter]

Andrey, I agree with your take on extensions to snakeyaml to support alternate 
integrations e.g. scala, thrift, protobuf, etc.

The patch I posted yesterday takes that approach-- It includes a completely 
separate module (in source path snakeyaml/extensions/thrift with self-contained 
pom.xml) which depends on snakeyaml along with integration deps (in this case 
thrift). This may be a useful pattern moving forward with more integration 
targets.

http://code.google.com/p/snakeyaml/issues/detail?id=161

Original comment by andrew.s...@gmail.com on 15 Nov 2012 at 6:45