Comments on: Arbitrary runtime constructor dependencies in Lightwire

By: Thomas

Thomas — Mon, 29 Mar 2010 23:47:18 +0000

@Dave, thanks for the feedback. Doesn’t seem like a ton of people are using Lightwire in the first place based on the amount of feedback. Even the AOP stuff I did got pretty much zero response, and it’s a lot more significant than this. This was just a nice to have. So without more interest, it won’t make it into the main codebase, which isn’t really a big deal. Like you said, having a configure() or populate() method isn’t that huge of a deal, especially since there would probably be limited cases.

By: Dave Merrill

Dave Merrill — Mon, 29 Mar 2010 23:36:48 +0000

Eh, code bits didn’t come through. Just a method to return arguments — pass in name args, get out a struct with the passed values in the passed fields.

By: Dave Merrill

Dave Merrill — Mon, 29 Mar 2010 23:35:31 +0000

Kind of a side issue, but for building a struct concisely pre the native language construct, many folks use something like this:

I’m not such a fan of ordered args, at least more than about two. Named args are self-documenting, worth the typing IMO.

On your main idea, I’m not sure I see a big advantage to having a method in the bean factory to set a bunch of dynamic properties at once, vs having it in the objects themselves. A generic populateFields method in a base class feels more appropriate than moving it out to the bean factory. DI seems more about app structure and object relationships, where injecting dynamic values like more of an object-specific convenience.

OTOH, it doesn’t hurt to have it if it can be done cleanly, so if it floats other folks’ boat, I say go for it.

My $.000002…

By: Thomas

Thomas — Mon, 08 Mar 2010 20:14:08 +0000

Yeah, the downside to a populate argument is that for people not running CF 8 they would have to create a collection first, so that means doing structNew(), assigning a bunch of keys, etc., which would get verbose and kind of defeat the purpose.

By: Garrett Johnson

Garrett Johnson — Mon, 08 Mar 2010 19:20:55 +0000

Could be handy, maybe just have a second “populate” argument to the getBean method where you can pass in your collection?

The populate argument could just simply get iterated over and set whatever property matches the current key for that iteration…

Or are you wanting to be able to pass in N about of arguments for whatever reason?

By: Do you want to see this in LightWire? « Application Generation

Do you want to see this in LightWire? « Application Generation — Mon, 08 Mar 2010 17:05:18 +0000

[...] blogged about supporting “arbitrary runtime constructors” in LightWire. Check out his posting and comment at the bottom as to whether you like or dislike the idea. If it’s popular enough [...]