Actually what you are doing is illegal. Remember that RegisterProperty() is a static method, so that default value you create will be used on every single object ever created - providing the same child instance to multiple parents.
It is not legal for an object to have multiple parent objects - this will cause all sorts of problems (wrong Parent value, messed up edit levels, etc).
I'm not saying you didn't find a "bug", but even if we fixed that bug it would simply lead to another bug, and another and another.
Perhaps the real bug is that RegisterProperty() should throw an exception when you try to set a non-valuetype default value. And if this was a common issue I'd do that - but I can't recall anyone actually reporting an issue with this at all, so it isn't worth "fixing".
RockfordLhotka:
Actually what you are doing is illegal. Remember that RegisterProperty() is a static method, so that default value you create will be used on every single object ever created - providing the same child instance to multiple parents.
Perhaps the real bug is that RegisterProperty() should throw an exception when you try to set a non-valuetype default value. And if this was a common issue I'd do that - but I can't recall anyone actually reporting an issue with this at all, so it isn't worth "fixing".
rxelizondo:2) This one kind of troubles me a bit. The so it isn't worth>"fixing" part. To me everything is worth fixing, I mean, why not? Whats the problem? There's probably a bunch of people that are eager to contribute to the development of the CSLA, I know I am one of them... I mean, I would pay money to be able to be more than just a user of the CSLA. It would be really gratifying to see some of my code land on the CSLA...... ok, perhaps I am not worthy at this time but I am sure others are. So rather than not fixing the issue, have you consider doing something to allow people to help you out with the core csla? is this being done at this time (other than the VB effort)? Thanks.
There is a contributor agreement you can sign with Rocky which opens up opportunities to assist in maintaining CSLA. I haven't seen it, so I don't know what's involved.
Having said that, there most certainly are bugs that aren't worth fixing. I've found this blog entry to be pretty good at explaining my perspective on it:
http://www.joelonsoftware.com/articles/fog0000000014.html
In this case, the blog author is dealing with commercial software, which lives in a slightly different world than CSLA. But I think the same principles still apply. Basically, from this perspective, fixing a bug isn't worth it if it takes more time to fix than it saves. Given the situation that Rocky has described - i.e. this is a "bug" that no one has encountered - there's nothing on the "time saved" column to balance out the "time to fix" column. He also mentioned that tackling this issue opens up a whole other set of potential issues, which add even more time to the "time to fix" column...
(Having said that, if you read the article, you'll see that he did end up fixing every bug in his system. "Cost" is sometimes a relative term... ![Smile [:)]](/emoticons/emotion-1.gif)
)
I also know that Rocky has his own hierarchy of how he determines what bugs he fixes, which has been laid out in posts before. It doesn't follow the article I linked to, but I see elements of the article in his hierarchy.
I'm not trying to speak for Rocky here - just offering my opinion.
HTH
- Scott
Triage of bugs is basic software engineering. Any sizable software effort ends up with decisions made about what to fix and not to fix based on a variety of factors.
Not meaning offense, but it is naive to think that everything can be fixed - there are many costs to changing software (real cost, time, impact on existing users, opportunity cost, etc). Regardless of whether the change is a bug or a new feature, these costs exist.
It is true that I accept some help in maintaining CSLA. Generally the help is limited, though there are a small number of people I've been working with (sometimes off and on) for years, where I have a high level of trust that they share my view on software development and their impact has sometimes been quite high. Developing that level of trust takes a long time, but I really appreciate the contributions of the people who've stuck with me.
My view on CSLA contributions is not unlike Torvald's view on Linux - this is a "benevolent dictatorship" :)
What's ironic is that, as you might expect, CSLA was much cleaner and tighter when
The first point is a big one, because you must have amazingly clean code if you are going to use it as a tutorial in a book. But if I restricted the size of the framework to what I could completely discuss in the book the framework would have become irrelevant to most people several years ago.
The second point is just as important. Two developers never share exactly the same sensibilities, and there are parts of the framework now that I didn't implement - and so they are somewhat in the same style, but aren't completely in the same style. The more developers that become involved, the less consistency (and thus in a sense the less clean) the code becomes.
In my observation over the years, that's just the way software works. Barring some sort of Vulcan mind meld, everyone has a different take on things and that impacts (negatively) consistency and so forth.
Which is not a negative reflection on any contributors - there's some excellent code in the framework from some very smart people - but it isn't always quite the way I'd have done it :)
In any case, I fully appreciate that CSLA impacts a lot of people and organizations in some very deep ways. That's quite humbling.
And because of that reality, the need to prioritize changes and fixes based on broad impact is all the more important. Fixing things that no one has ever encountered in the wild falls at the absolute bottom of the priority list in most cases.
rxelizondo:
On a more selfish note, users of the CSLA have a vested interest in seeing the CSLA get adopted by more and more developers. It would be a pity if the CSLA lost the framework fight and we saw it go bye-bye in favor of some other framework. So the “no bugs” / “clean code” statements are big sellers to someone deciding between frameworks. The more CSLA adopters the better, the CSLA is a marketable skill if it’s well known.
I'm curious.. what frameworks do you feel compete with Csla? To my knowledge, there are none, Csla fills a niche seemingly ignored by everyone else. DTO mapping is well covered, UI is well covered.... but business rules? The only things close are external rules engines, or something like WF. But these don't seem to be aimed at building a library to address particular use cases as much as they are a way to let "normal" people build "applications."
I'm curious.. what frameworks do you feel compete with Csla? To my knowledge, there are none, Csla fills a niche seemingly ignored by everyone else. DTO mapping is well covered, UI is well covered.... but business rules? The only things close are external rules engines, or something like WF. But these don't seem to be aimed at building a library to address particular use cases as much as they are a way to let "normal" people build "applications."
Any framework out there is a competitor of the CSLA framework no matter how big/small or famous/unknown the other frameworks are, each framework has their pros and cons, that is why they exist.
That's a fair enough statement, but like I said, I'm not really sure there ARE other frameworks out there that tackle business objects. I've looked, and have yet to find one that fits the same niche.
I was just approaching this form the “marketable skill” point of view. The more famous/successful the CSLA is the more marketable you are. Especially since frameworks are critical to the development of any serious applications.
I agree; of course, I've also had interviewers ask "what's Csla," and I give them an executive summary and explain why it's useful. So even if potential employers don't know what it is, it still helps you be marketable.
Copyright (c) Marimer LLC