Code change in DotLiquid?

[Stephen Hardie]

First off I've been very impressed with DotLiquid and I'm in the
process of using it in a code generation api for our company. I
recently ran into a small design issue that I'd like to see
implemented in the source here instead of in our own api... so I was
wondering how hard it is to contribute to the DotLiquid project here
and if there is a process for adding a code change into DotLiquid?

The change I'd like to introduce is a second abstract Drop class
called CSharpDrop or CSDrop. The reason behind this is because the
moment my objects (which inherit from Drop) are created I can no
longer change the naming convention to CSharp because the properties
and methods have already been cached using the Ruby naming
convention.


Thanks,
Stephen

[Tim Jones]

Hi Stephen,

Thanks for your comments.

I have (just) created a DotLiquid-Contrib project for user contributions:

https://github.com/formosatek/dotliquid-contrib

The "process" is simply to fork this project and then send me a pull request.

However, I'm not sure I understand the purpose of a CSharpDrop class. Couldn't you set the naming convention in an initialization method, before any of your Drop-derived objects are created?

Thanks,

Tim

[Stephen Hardie]

My drop-derived objects are created before I'm ever able to set the naming convention. Due to the nature of our abstraction, doing so before is not possible.

[Tim Jones]

Right, I see.

This still sounds (to me) like an issue that's quite specific to your implementation though, so I'm not sure if a CSharpDrop class would be helpful to other users. What do others on this list think?

Tim

[Stephen Hardie]

Alternatively... What about modifying the way liquid works so that if the naming convention is changed after the derived objects have already been created then it would reset the cache so it would start using the new naming convention?

Also, not sure how specific this really is? By requiring this before initialization I'm adding an additional dependency on liquid in our architecture. Part of our architecture is designed to abstract liquid away in case we ever change our template engine. If it helps any... we are using liquid for a code generation process.

[Tim Jones]

That's a good idea - we could have a NamingConventionChanged event which the TypeResolution class subscribes to.

Tim

[Stephen Hardie]

NamingConventionChanged sounds great. Works for me.

[Tim Jones]

So, I tried to implement this, but hit a snag.

• I added a NamingConventionChanged event.
  
• I need to have TypeResolution objects subscribe to this event, and reset their cached methods and properties.
• To prevent memory leaks, I need to have TypeResolution objects unsubscribe from the event, and there's no proper place to do this. I could make TypeResolution implement IDisposable, but that's is not really deterministic enough.

I can't see a nice solution for this - if you have any ideas [or pull requests ;)], I'd be happy to hear / see them.

Tim

[Stephen Hardie]

Your idea seems like the best answer, to implement IDisposable. I'm open to other ideas too, but I'd really like to see this feature in DotLiquid as well.