Support for "partial" classes generation

[itamarro]

Hi all,
is there any way I can make Dingo generate the classes as "partial" w/o modifying Dingo itself?

(In .Net 2.0 & mono, there's support for partial classes - the class definition can be spread across several files. That's very useful for, e.g., having the logic in hand-written files and the xml serialization stuff in other files auto-generated by Dingo.)

Actually all that is needed is adding the 'partial' keyword to the class definition but I haven't seen the possiblity for this using the dingo.builder interfaces. Have I missed anything?

Thanks,
Chas

[Peter Lin]

in theory it should be too hard to add support for it. I may have time tonight to take a look. Can you provide an example? if you give me example, I can take a look tonight.

peter

[Peter Lin]

I looked at partial classes and I'm not sure about the value of partial classes. Although it is nice for VB guys to separate a huge class into separate files, I consider that a bad practice. Even in the case of VS.NET generated code, I feel it is better to for VS.NET to generate an abstract class with virtual methods. This way, the generated code is in an abstract parent class and the user creates a concrete subclass.

I haven't made up my mind, but I can't think of a compelling reason to support Partial classes. Is there a good reason/need for the feature?

[Peter Lin]

I gave the feature more thought and I don't really consider partial classes of any value to be blunt. If you need assistance adding the feature, I'll be happy to provide pointers, but at this point I do not consider it a desirable feature.

[itamarro]

Well, please let me try to convince you:

1. Partial classes allow you to do a lot more than what the "builders" Dingo supports allow you. They give you the ability to write code (or generate using any other method - templates, CodeDOM, etc - not just using the string methods employed by Dingo) that is to be part of the classes auto-generated by Dingo. I think that is a very useful ability

2.  In my application, for example, we have so-called "declarations" in XML (Certain XML elements represent logical declarations). So, we have a bunch of declaration classes. Now, partial classes give you the ability to use the code generator to handle all the mundane xml-serialization stuff for the classes, while having the business logic for each class sitting in separate, hand-written files. That way you don't have to go through the object graph created by the deserialization and apply the logic in some way - the object graph is built with classes already implementing the business logic!

Do you really not see any value in that?

[Peter Lin]

thanks for responding. I read your post a few times, but I don't think I understand the first point. Is the goal here to have a tool generate code (ie XSD, dingo) and have other stuff that is hand written?  Why wouldn't you simply set Dingo to generate an abstract class and have the hand written code extend the base class. Wouldn't that be cleaner and provide better separation.  I've mainly worked on large projects and the preferred approach is to define the interfaces and then the developers go off to code.  That's the reason why Dingo supports jaxb style code generation with interfaces and abstract classes.  wouldn't declaration be similar to interfaces?

I can be convinced and I haven't made up my mind. if you can provide a concrete example, I would be more inclined to support partial classes.  If you really want that feature, I can give you tips on how to implement it. plus, dingo uses apache license, so you can take it and make your own version.

peter

[itamarro]

If I use asbtract classes and implement the functionality in classes inheriting from them, when the XML deserializer creates the object graph, it is created with the plain classes, which do not include the business logic.

Example for what I want to do:

XmlSerializer serializer = new  XmlSerializer(typeof(UserDeclarations));

// ... snipped ... (create a FileStream and an XmlReader named reader)

UserDeclarations userDeclarations;

userDeclarations = (UserDeclarations)serializer.Deserialize(reader);

userDeclarations.Apply();

The "Apply" method, implementing the business logic, is implemented in the types of which objects were directly instantiated by the serializer. There's no need for any additional "glue".

I consider that more object oriented - the same classes contain the data and serialization info (generated by Dingo) and the logic (hand written).

I know it's not hard to implement; right now, we have a one-line script that does the replacement. It's just that I am not so fond of creating a private fork of an open source project...

[Peter Lin]

thanks for replying, I'll have to think about that a bit. It's still not clear to me why one would want to have an apply() after deserialization. It seems like you're trying to have "smart" domain objects versus Data objects.

when i say data objects, I mean objects that contain no business logic and simply contain the structure and values.  When I think of "smart" domain objects, it is an object that knows how to prepare itself to do some work or the actual work itself. Like persistence, register itself with a messaging system or pass itself to a framework as a listener. Perhaps a better explanation will help me understand.  Given that partial classes is a .NET 2.0 feature and 2.0 hasn't even been released, I find it hard to believe a production application is using it.

it's a bit risky when the early preview of 2.0 just came out a few months back. the pricing was just announced 2 months back.

peter

[Peter Lin]

Although I am opposed to supporting an idea I don't believe in the main code, it should be very easy to write a plugin to support it. If I have nothing else to do this weekend, in the copious free time that I don't have, I might attempt writing a plugin to support the feature.

I've yet to see a solid reason for partial classes.

peter