Ruben Soto

Ranch Hand
+ Follow
since Dec 16, 2008
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ruben Soto

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. :-)


Hi Marco,

Sorry for the late reply. I am mostly familiar with Python and Java, and I think that they have very different philosophies. I think that with Java there is more redundancy, which probably means that in most cases it's more difficult to make code less readable. You can do many things in Python which are amazing though, since you basically have full freedom in customizing class creation at runtime. I'm not saying this something every language should have, just that it's one example where you can appreciate the difference in approach of each language.

I am not too familiar with Scala, will have to check it out.
15 years ago
Calculate calls itself recursively, so:
Calculate(5) = Calculate(4) + 5
= Calculate(3) + 4 + 5
= Calculate(2) + 3 + 4 + 5
= Calculate(1) + 2 + 3 + 4 + 5
= 1 + 2 + 3 + 4 + 5
= 15

You are correct. Coupling measures inter-class dependency. Cohesion measures how focused a class is. In other words, a class should do only a few very related things, as opposed to combining functionality that should be split in different classes to promote modularity and code reuse.

sura watthana wrote:thanks so much Ruben

You're welcome, Sura.

Also, note that you can mark an enum which is declared inside a class as private or protected, so you must observe the access restrictions like for any other class member (I was assuming a public enum in my discussion above.)
Hi Sura,

The reason is that enums are always static entities (enums declared inside a class are actually implicitly static.) What this means is that you must be able to access an enum from anywhere in your code, without involving the invocation of any code block (such as a method.)

For example, if an enum is declared at the top level of a file, and this file is in a given package, you can just access the enum directly from the same package (or via an import, if you want to access it from other package.) If an enum is instead defined inside a class, it becomes a static member of the class, and you can access it like any static member of the class such as static member classes of the class, as long as the class is accessible from your code.

If enums were defined inside methods, then they wouldn't be static anymore. You would actually need to invoke the method in order to instantiate the enum.
But if you have a third class in another package and that one extends your subclass, the protected member will still be accessible to that third class.
The exception is reported in, which means the compiler knows that when that method is called, a checked exception might be thrown. That's why, when you call that method anywhere else (as you are doing in Dog2.main(),) you either need to declare the checked exception in Dog2.main(), or put it in a try block. At every single point that a checked exception might be thrown, you either need to declare it in the enclosing method, or put it in a try block.
I am quite familiar with Python and I really like the language (but haven't looked at the backwards-incompatible 3.0 version yet.) What I really like about it is its clean syntax and simple yet powerful OO implementation, and the fact that it is extremely high level and reflexive. I was tempted to look into Ruby, but then somehow I ran into a few comments which liken its syntax to Perl (in the sense that there are many different syntactic ways to do something.) On the other hand, I keep hearing how Ruby is truly a more elegant language than Python (although I haven't found satisfactory explanations as to how that is so.) I was wondering what experiences and insights some of you guys could offer.


15 years ago
Yes, you sure did Sree. I don't know how I missed that...

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.

What I meant is that if you have a method call which may throw a checked exception you must either catch the exception or declare it in the method enclosing the call.
Declarations are processed at compile time and do not depend on the execution flow of your code. Since b is declared within the local scope of the switch block, it is useable anywhere in that block from the point of its declaration.

Please quote your sources. We won't be able to help you until you do so.

What happens when you run the code with a = 2?
There are two parts of a method invocation of type <reference>.<method>:
- Compile time: At this point, the compiler looks at the type of <reference>, and finds the <method> defined in that class. In other words, at compile time you only have the starting point of the override chain (the compiler leaves determining the actual method to the JVM at runtime. The actual method invoked at runtime might be different from the method determined at compile time when the method is overridden by a subclass.)
- Runtime: When the method is called at runtime, the JVM looks at the actual type of the object that <reference> points to. If this class is in an inheritance branch which overrides the method determined at compile time at some point, then that method will be called. In other words, the JVM, starting at the actual type of the object, travels up the inheritance branch towards the type of the reference, and stops when it finds the first overriding definition of <method>.

The problem is that at compile time, the compiler only knows that the <method> is the one defined in the type of <reference> or one of its derived types, so it 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.

In simple terms, from the point of view of the compiler, when you call, it thinks that eat() might be the eat() defined in Animal, which throws a checked exception.
I wanted to add that if you don't pass any arguments to main, args won't become null. Instead, it will have zero elements.