Peter Becker wrote: >>> nces of it are immutable since subclasses might break that >>> assumption. >>> >>> >> and that is the responsibility of the sub-class, not my mother! >> >> >> > My problem is that I am too pessimistic to believe that people will be > happy with me telling them it's all their fault for not reading the FM > (or JavaDoc in that case). Particularly if it is a third party that got > hurt by a subtle bug introduced by someone subclassing String without > obeying the contract. And bugs due to broken immutability assumptions > tend to be subtle and hard to debug since the time between error and > failure can be arbitrarily long. > I happen to teach performance testing and have done so for a number of years now. I kept stats on my observations regarding things that developers tend to be good at some things and not so good at others. Testing is something developers tend not to be good at. I have one exercise where consistently less than 5% of developers complete the assigned task without serious intervention. However, that number jumps to more than 70% in the case of testers. In most cases, the developers were more technically adept than the testers. However, developers have far less training (if any at all) with debugging or testing. A more interesting non-scientific observations of the people I've taught is when I breakdown the numbers for those that use TDD vs those that don't. I find that about 35% of TDD will finish without heavy intervention where as less than 1% of those that don't follow TDD finish without heavy intervention. Problem is, the vast majority of developers do not follow TDD so I only have a small sampling of TDD developers.
> It's the same category as having hashCode() depend on mutable elements: > you put something in a collection, much later you change it, even later > you try to find it in the collection and it is not there anymore, so the > results of your application are wrong (which is IMO the worst type of > error, even worse than data loss). That's why IMO this way should have > never been taken for the hash structures, but it's too late now. If you > trust people to get this right all the time, then it is ok. But I don't > -- I've screwed that one up myself once before and I wouldn't promise to > never do it again. > right but we've slipped into the land of final fields and not final class. I'm not talking about final fields, just final classes. > I guess it really depends on what you want. You seem to have a priority > for flexibility, while I want to know things are done and good and will > never turn an ugly head on me. I want both... My Smalltalk experiences tell me that many of the problems people expect to see when dealing with dynamic languages don't really show up enough to warrant a heavy mothering hand. ;-) Regards, Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
