Static/Shared SetParseCulture method... why?

Sep 1, 2008 at 3:15 PM

I have a question about Ciloci.Flee.ExpressionFactory.SetParseCulture.

This method is static, and I'm starting to wonder if there is any reason for it. I'm facing now that two different parts of my application will use Flee, and it could happen (well, it won't happen in this software, but it could) that those parts need different cultures for Flee.

Calling this method can lead to problems, because the code will be running in different threads, and it is not guaranteed that the other thread won't change the culture from my call to SetParseCulture to my call to CreateDynamic.

Two questions arise:

1. Is Flee thread safe? I mean, can I call "CreateDynamic" in different threads without locking anything?
2. Is there any reason for SetParseCulture to exist? From my point of view, it would be easier to include the culture as a parameter for CreateDynamic, and delete this method. Ok, maybe not delete it (it would break the existing API), but the parameter would override any previous call to that function.

Thanks in advance,

Oct 21, 2008 at 10:29 AM
I am considering to implement Flee in our web application. My first impression is really positive, it seems like a well thought over product and seems to work really good (and fast)! (after some quick tests). Compliments for making and sharing this nice library!

But I was asking myself exactly the same question as fernandonajera.  Our web application has to support multiple cultures at the same time, so this is a critical issue. Wouldn't it be better to use Thread.CurrentThread.CurrentCulture as default? That would eliminate the need for a specific option altogether.
Nov 9, 2008 at 10:36 PM
In the release, each expression context now has its own parser.  The parse culture has been moved to the expression options on the context.  Creating expressions from a context is thread-safe.

I initially did this because I thought that creating a parser was slow so I tried to only do it once.  After some testing, it looks like creating the first parser is slower than normal, but all further new parsers are created without much of a speed hit.
Nov 10, 2008 at 8:13 AM
Thank you very much!