Regardless of whatever the final decision may be, it seems like this could be a 1.1 feature. Let's not lose the momentum of this project and delay a 1.0 release.
-Adam On 3/24/06, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote: > I'd like to point out that, regardless of the language or framework, this > kind of thread can often feel awfully "hot" to people, especially when > you're offering an idea that you think is both simple and important and > you're not getting the kind of hop-to-it enthusiasm you were hoping for. " > While you're excited and enthusiastic, other people will evaluate your > suggestion with less enthusiasm and more "critique" than, as the > contributor, the original suggestor... even if you've done your homework and > tried to validate the idea ahead of time. > > It's assumable that, since someone made the suggestion, they think it's a > good idea and has merit. That's never (or almost never) in question. And I > think that this idea is, unlike many others I've seen suggested to framework > makers in the past, actually relevant and appropriate to the framework at > hand (as opposed to something like "can we add AJAX to Model-Glue?" which > was actually brought up on the MG list!) What's in question is how much work > is involved in making it happen, how much gain it so be had by doing so, and > how many users of the framework will actually benefit from it. The edge > cases (which seems to be what you guys are dealing with) often don't make it > in to the final cut because: 1) they don't benefit a broad enough base to > make it worthwhile and 2) because the audience for the feature is limited, > the result is extraneous feature sets for the mainstay of people who use the > framework. > > This is probably going to be misunderstood, but I'm going to say it > anyway... just don't read any tone or inflection into it. I'm not casting > aspersions or anything of the kind... just read the words: > > You have to keep in mind that if 95% of the people who use Reactor don't > need or wouldn't use the feature you've suggested, then you've just added > complexity, learning curve, likely errors, extra weight to the classes and, > ultimately, extra work for every single one of them. The presented rationale > behind this potential sacrifice on their part is "so we can abide by Java > bean naming conventions" and "then Reactor will be a very easy drop-in ORM > replacement for other things we use/have used/might use." Compared to making > the lives of 95% of users more difficult, making your life easier may or may > not be worth it. Even if it would drastically, dramatically, incredibly > improve things for you, as bad as that sounds, telling the other 95% of > users to get stuffed because it'll help you is not in any way in the best > interests of the tool. > > There are a few questions I have, though... the answers may have already > been scattered thru the thread, but I'd like to see the answers in one place > if you don't mind: > > Why can't you (or won't you) just add a getN() method that wraps the > getNRecord() method yourselves? If you're customizing any of the objects > they you don't have a pristine API to your record objects anyway... why is > this option not acceptable? > > Since you have to tweak your DAOs to make any new ORM framework fit, why not > just tweak for Reactor too? > > I suspect the likely answer is "because the way Reactor works now isn't how > Java works." Bummer. This one annoys me. :) Reactor's API is set up to > differentiate between the Iterator and the Record, so, since getNRecord() > and getNIterator() both exist on the objects in question you're asking to > turn getNRecord() into the default and, IMO, breaks the consistency and the > stability of the framework's API. If you want custom methods, create custom > methods, but I don't see how breaking the API of the framwork (which is > essentially what this would do) is in anyone's best interests. > > I do think this request would make life a LOT easier for you guys, but, as > edge cases everywhere know, that doesn't really matter (unless of course you > were paying for it -- paying/sponsoring is one good way to get your wantages > added real fast) if there's no widespread need for your request. The > alternative is to check reactor into your own repository, alter it > yourselves to do what you want, and go from there. Macromedia ran a slightly > modified version of Mach-II for a long, long time... that may be an option > for you guys as well. > > Anyway, my infamy for writing huge emails is catching up with me and I'll > gonna shut up now. I hope I've brought up good points and that I haven't > pissed anyone off too badly... because I meant them as discussion points and > not as slams or dissing. > > Laterz, > J > > > > > > ------------------------------------------------ > > Jared C. Rypka-Hauer > > Continuum Media Group LLC > > http://www.web-relevant.com > > Member, Team Macromedia - ColdFusion > > > > > "That which does not kill me makes me stranger." - Yonah Schmeidler > > On Mar 24, 2006, at 12:44 AM, Shannon Jackson wrote: > > > True, but if I were to stack the benefits in order of importance > (personally) I would have to say that migration is key at this point. > Reactor is going to go 1.0 in the near future -- it's about building a > community, right? Swapping out (with ease) is a golden concept too; but not > the entire basis for the argument. > > > It is such a simple, little, tweak that could bring in dozens of migrated > applications in our organization alone. > > > Never-the-less, I wish people were not so hostile to a discussion here. We > mean no harm and we come in peace! > > > - Shannon > -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
