On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett <[email protected]>wrote:
> Guys, > > I just wanted to have a grumpy moan about FactoryMaker. Now, this must > easily be the most complicated / confusing piece of scala code in > Lift. > > Its totally non-trivial implementation and its levels of miss- > direction (and total lack of examples) make it an utter nightmare to > figure out what one needs to do to use it for pre-assigned vals in > LiftRules. > > This brings me neatly onto my next point: LiftRules and its occasional > use of FactoryMaker, partial functions and mutable vars. I appreciate > that this is partially a legacy thing as many different people within > the team add stuff to LiftRules, however I thought FactoryMaker was > brought in to facilitate object mocking / testing right? Shouldn't it > be the first-order choice for configuration? weather or not that is > the case, why oh why are there no explanations in the comments for > LiftRules where factory maker is used as to how to alter those > configuration options? > Okay... once the assembla ticket system is up, open a ticket on this and assign it to me. > > For example: > > LiftRules.stripComments.default.set(() => false) > > FactoryMakers allows you to do a number of things: 1. define functions that calculate a value for a given thing (like should comments be stripped) 2. support aggregation into a Factory which can be used for Java-style dependency injection (you ask the Factory for a thing of type T and it gives it to you) 3. supports session, request, and current-thread over-riding of the calculation function So, why functions vs. values? Because functions are more flexible than values... they allow the calculation of values given the current context. Why not use call-by-name rather than explicit functions? I've found that making things explicit functions remove ambiguity. Additionally, there's an implicit that's supposed to promote a constant (T) to a function... but it doesn't always get invoked. If it's a function, why have session, request, and thread-based functions? Because you have to know at Boot time what you want the function to look like in all cases. Kris had some reasonable examples of over-riding the functions on a test-by-test basis (thread-based). Additionally, it strikes me that you might want to have a snippet that triggers a change in particular behavior (request-based) and rather than having to code that behavior into the function defined in Boot, you change it at the request level (we've got some examples of stuff that does that already, but making the common pattern into something that's built into the Factor/FactoryMaker makes sense). Are the names and call patterns optimal? No. But given that Factory/FactoryMaker is little used outside of LiftRules, I'd be up for breaking changes (as long as they turned into compile-time errors) to make things better. Tim -- you want to volunteer? > This is totally non-obvious - if we are going to use stuff like this, > it really out to be in the comments. Stuff like this can seriously > affect Lift's ease of use, and considering the current lack of > documentation we need to be careful about what we are doing here. > > Sorry for the grump, i just felt this was warranted. > > Cheers, Tim > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
