Marco Ehrentreich wrote:Hi Ruben,
I must admit I haven't use neither Python nor Ruby for real life projects. But my impression of Ruby (and other dynamic languages) is similar to yours. There are often many ways to achieve a goal. Moreover there is a lot of magic going on behind the scenes with reflection, meta programming and so on. This is really nice to say and may be quite good when you create a prototype or you make an application from scratch.
But I think MOST programmers will definitely misuse all these nice features and you will end up with a completely non-understandble code base if you can't control that everybody works very disciplined. Maintainability and readable code is in my opinion absolutely missing in all those nice examples which try to make the shortes "Hello World" program even shorter. Of course it is arguable if this is a problem of the programming language or the programmer but practice often shows that it's even hard to understand most code written in more straight forward languages.
What I find a really good compromise is the approach in Scala where it's allowed to leave out some redundant information like braces or type definitions where they can be inferred by the compiler. The code is still readable enough for other developers in contrast to some funny tricks in dynamic languages.
This is of course just my opinion. Maybe someone can REALLY convince me of the advantages of Groovy, Ruby, Python etc. :-)
Marco
sura watthana wrote:thanks so much Ruben
Christian Lombardo wrote:When you say "has to enforce the rules so that even in the worst case scenario (when <method> is the one defined in the type of <reference> the restrictions of checked exceptions are observed." The rules as I understand from the K&B book are:
*Overriding method must not throw checked exceptions that are new or broader than those declared by the overridden method.
* Overriding method can throw narrower or fewer exceptions. Just because an overridden method "take risks" does not mean overriding subclass exception takes same risks. Bottom line: an overriding method does not have to declare any exceptions that it will ever throw regardless of what the overridden method declares.
How does these rules in the K&B book coincide with this example and what you are saying? Are there other rules "overriding + check exceptions" I do not know about? If so Could you please explain.