Am 06.11.2011 20:56, schrieb Sean Corfield: > On Sun, Nov 6, 2011 at 11:12 AM, Dennis Haupt <d.haup...@googlemail.com> > wrote: >> let me guess: you had some classes that were used more than they should >> have been because they were the best match and introducing a better one >> would have taken more time - and since they could do so much, they were >> just used at more and more places and in the end, they became god >> classes which infested everything? > > I generally refactored them into submission before they reached "god" > status but they sometimes reached "saint" or "minor deity" status :) > > The other problem I ran into with OO (a lot in the early 90's, less so > as I got more experienced) was identifying what turned out to be an > incorrect set of classes and then finding myself "stuck" when > requirements changed and needing to completely redesign whole sections > of the application. That's the aspect of static type systems that I > don't like: if you make choices that seem reasonable but turn out not > to match a future set of requirements, those types are _everywhere_ - > woven into the very fabric of your application's structure as well as > liberally sprinkled throughout any code that touches objects of those > types. Scala helps with type inference but also expects you to encode > even more of your application's structure and logic into the type > system (which makes the "wrong type" decisions even worse when they > pop up). > > Without a rigid type system, generic functions can operate on any > compatible data structures without needing a typed wrapper (not even a > parameterized type wrapper with inference).
if by compatible you mean "has a specific set of functions and fields", then scala can do that without sacrificing static type safety: http://www.artima.com/scalazine/articles/scalas_type_system.html "Bill Venners: One of the things I have observed about Scala is that there are a lot more things I can express or say about my program in Scala's type system compared to Java's. People fleeing Java to a dynamic language often explain that they were frustrated with the type system and found they have a better experience if they throw out static types. Whereas it seems like Scala's answer is to try and make the type system better, to improve it so it is more useful and more pleasant to use. What kind of things can I say in Scala's type system that I can't in Java's? Martin Odersky: One objection leveled against Java's type system is that it doesn't have what's often called duck typing. Duck typing is explained as, if it walks like a duck and quacks like a duck, it is a duck. Translated, if it has the features that I want, then I can just treat it as if it is the real thing. For instance, I want to get a resource that is closable. I want to say, "It needs to have a close method." I don't care whether it's a File or a Channel or anything else. In Java, for this to work you need a common interface that contains the method, and everybody needs to implement that interface. First, that leads to a lot of interfaces and a lot of boilerplate code to implement all that. And second, it is often impossible to do if you think of this interface after the fact. If you write the classes first and the classes exist already, you can't add a new interface later on without breaking source code unless you control all the clients. So you have all these restrictions that the types force upon you. One of the aspects where Scala is more expressive than Java is that it lets you express these things. In Scala it is possible to have a type that says: anything with a close method that takes no parameter and returns Unit (which is similar to void in Java). You can also combine it with other constraints. You can say: anything inheriting from a particular class that in addition has these particular methods with these signatures. Or you can say: anything inheriting from this class that has an inner class of a particular type. Essentially, you can characterize types structurally by saying what needs to be in the types so that you can work with them. " Yes, there's a trade off > in that you can pass the "wrong" data but if you're test-driving your > code (whether you do it in your head, in the REPL or with physical > tests in code) and building it in small pieces, there's much less risk > of doing so (IMO & IME). > >> with mutable states, i can "hide" that one additional parameter for the >> one special case that would otherwise ruin my design by using a secret >> static threadlocal or whatever else does the job. this is a pact with >> the devil that will backfire when a certain threshold is reached, but it >> *is* faster than doing a small refactoring every time. > > Faster overall, or just faster to the next marker post (and then a > technical debt has accrued which must be repaid at some point)... ime, you have to refactor your oo-stuff sooner or later (requirements can change) so you might as well save the small stuff for the big refactoring that is coming anyway. > >> i'm pretty pragmatic here: sometimes doing it wrong now and doing a big >> refactoring later is the better way. > > Doing it wrong and having a small refactoring later is OK but accruing > a big refactoring isn't something I'd want in my code - but I guess it > depends on what you define as "big" (and how "wrong" the shortcut > feels). > >> can you give an example of truly generic code vs not so generic code? > > Not specifically. I'm not there yet but I feel I'm getting better... > > [PGP] >> done > > Thanx Dennis! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
