It's a pretty bad/annoying API that was developed a looooong time ago and has outlived it's usefulness. Will require a deprecation cycle.
Possibly should be dropped from Mapper API as well (though I personally care less about that).
Imported from Assembla: http://www.assembla.com/spaces/liftweb/tickets/887
If we're going to do this, we need to get the deprecation wheels moving in 2.6 and remove it in 3.0.
Wowza, yeah. I'll add a deprecation warning for both.
What's the plan to replace this? It's used quite a bit.
In my mind, it'd be ideal for the client code to do the type check on its end to figure out what the any is. Do you agree or should we kick off a discussion on the ML?
It's used internally a lot. Pretty much every field uses it in their form element. Although, most of those could be replaced with setFromString or whatever's relevant to that Field.
I guess the one place I need a replacement is in BsonRecord.setFieldsFromDBObject since I don't have the type info. We may be able to get that info from the Field, though. I'll look into that as soon as I finish my other pull req.
We definitely shouldn't deprecate unless we have a clear plan for getting rid of it. I noticed it was pretty thoroughly baked in as well. Some research is probably a good idea.
I'll go trough the Record Fields and see if I can rework BsonRecord.setFieldsFromDBObject.
For squeryl-record we should probably have @davewhittaker take a look.
Not sure who should handle Mapper, I'm not that familiar with it.
I'm going to kick this off the M4 milestone since it looks like this may be a bit more substantial work than just adding @deprecated. :/ Should probably be planned for M5 though.
Yeah, when I was assigning these around I wasn't planning milestones, just using M4 to mark things we eventually wanted in 2.6.
Any updated thoughts here as we prep for an RC?
Bupkis. :( No. I forgot about it.
This probably isn't going to make it into 2.6...
Heh. Yeah, RC means we're done with changes like this.