This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
On page 14, at the top, there is an example of a class Tea in package exam.stuff trying to extend another class Beverage in package cert.
Later there is a paragraph:
Tea won't compile because its superclass, Beverage, has default access and is in a different package. Apart from using fully qualified class names, which we'll cover in Chapter 10, you can do one of two things to make this work.
Now I come to the point. The phrase "Apart from using fully qualified class names, which we'll cover in Chapter 10," seems to imply that using fully qualified class names will solve this access problem. It won't: only putting both classes in the same package or making class Beverage public will solve the problem. Using a fully qualified class name cert.Beverage is just an alternative to importing the Beverage class.
Is there anybody who has the book who agrees with my point of view? [ July 22, 2006: Message edited by: Barry Gaunt ]
The phrase "Apart from using fully qualified class names, which we'll cover in Chapter 10," looks like Author is trying to say that there is some third way of compiling the Tea class even if Beverage is in a different package from the subclass Tea besides these two ways:
Putting both class in the same package.
Declaring Beverage class public.
But there is no third way. You have to put both class in same package or declare Beverage public.