to extends or implements a superclass, which one is better?
Actually, to extends or implements a superclass, which one is better? and what is the benefit of implements an interface instead of extends it? for example
public interface TableModel{
}
public class DefaultTableModel implements TableModel{
}
public class HelloWorld{
TableModel model = new DefaultTableModel();
}
Actually, what is the benefits of doing like this? If there are methods in DefaultTableModel which the TableModel does not have, we cannot use the model instance to access it! Can explain? Why we did not just change the TableModel into class or rather abstract class and extended from DefaultTableModel?
[673 byte] By [
kl001480] at [2007-9-30 18:17:17]
> Actually, to extends or implements a superclass, which
> one is better?
A compact car or a half-ton pickup, which one is better?
A screwdriver or a hammer, which one is better?
A bagel or a bandaid, which one is better?
Answer in all cases, including your question: It depends what you want to do.
An interface is good for simply spelling out a contract.
For the implementor of the interface: "If you want to call yourself a List, then you must have an add method, an interator method, a clear method, etc. If you provide all these things, then you can call yourself a List, and any code that expects a List can use you."
For the user of the interface: "If you have a List, you can do the following: add(), iterator(), clear(), etc. You needn't know or care about how it does it."
A class can implement many interfaces--it can be a List, a Comparable, a Serializable, etc.
But an interface can't provide any implementation. If you want to implement List, you have to do one or a combination of the following:
* Write the methods yourself.
* Delegate to another object that implements the methods.
* Extend a class that already implements List.
An abstract class, on the other hand, ties you into the one and only parent class that you're allowed to have, but it can also provide some infrastructure for the implementation that you can build on.
> Actually, what is the benefits of doing like this?
That's quite common.
You define an interface to lay out the contract--the what this type must do. (Interfaces are types in Java, just as classes are). Anybody can implement it, without having to extend any particular class. The interface does one simple job: Defines what services or operations the named type (TableModel, here) provides.
Now, there may be a lot of different ways to implement this, but there may be some reasonable default or common way of doign it that a lot of implementations might want to use--either by extending the DefaultTableModel or by delegating to it. We've defined the contract, now we provide one or more implementations of it. Somebody can use our implementation or add to it, or create their own. Kind of like how a MS Word says that you can create, edit, save, etc. any document, and then it provides you some common formats (letter, fax cover, proposal) that you can use or build on.
> If
> there are methods in DefaultTableModel which the
> TableModel does not have, we cannot use the model
> instance to access it! Can explain?
I don't do GUI, so I can't say for sure here, but in the general case, you'd do something like this: TableModel model = new DefaultTableModel();
and then you'd only call methods that exist in TableModel.
jverd at 2007-7-6 19:26:16 >
> there are methods in DefaultTableModel which the
> TableModel does not have, we cannot use the model
> instance to access it! Can explain? Why we did not
> just change the TableModel into class or rather
> abstract class and extended from DefaultTableModel?
Thats is correct, you can use those methods if use TableModel as your type. You could however cast back to the DefaultTableModel but then why not just use DefaultTableModel as your type.
The reason (as best as I can explain) TableModel is an interaface, is not only for the reasons stated above by the other poster, because each different model doesn't really share anything in common, besides of course the predefined function names. This means that if you want a brand new super-special table model you can start with a blank slate, and aren't tied down anyone elses implementation.
Of course, this being said there is nothing stopping you from using DefaultTableModel and 'extend'*** that either. Its all up to you.
to extend is better than to implement an interface. an tetended super class can provide all the benefits an interface can, (it can actually serve as an interface) and in addition it can provide commom functiionality and attributes the the sub classes. the debate is usually between an abstract class and an interface; in java, however, you can only extend one super class but you can implenet many interfaces, that's the trade off.
> to extend is better than to implement an interface.
Sometimes yes, sometimes no. As I said in my earlier post.
> an
> tetended super class can provide all the benefits an
> interface can, (it can actually serve as an interface)
> and in addition it can provide commom functiionality
You don't need to extend a class to get code reuse. Extending just to reuse code is wrong.
jverd at 2007-7-6 19:26:16 >
> A bagel or a bandaid, which one is better?bagel!bandaid!aaaaaaargh! I can't decide!
> > A bagel or a bandaid, which one is better?
>
> bagel!
>
> bandaid!
>
> aaaaaaargh! I can't decide!
*sigh*
Wimp, you know a bagel beats the bandaid everyday of the week, even when you're hurt and/or wounded.
Tssssssk, dubwai, i'm disappointed....
> A bagel or a bandaid, which one is better?
An old joke:
A small alien spaceship crash-lands near a city.
One of its landing gear wheels, all of 4 inches in diameter,
is completely buckled, so the alien goes looking for
a replacement and by-and-by walks into town where he
spies some bagels in the window of a deli. The alien enters:
"I would like one of your wheels."
"That's not a wheel, it's a bagel, here try one", and the
man behind the counter hands a bagel to the little alien,
who bites into it.
"Hmmm, this is good, but it would taste
better with a schmear of cream cheese!"
> *sigh*> Wimp, you know a bagel beats the bandaid everyday of> the week, even when you're hurt and/or wounded.> Tssssssk, dubwai, i'm disappointed....You haven't tasted the right bandaids.
public abstract interface ProjectManager {
public abstract void manage();
}
Now hundreds of classes are written to use a ProjectManager. They all have variables of ProjectManager type and all of them are clients that call the manage method.
public final class DisciplinedProjectManagerImpl implements ProjectManager {
public void manage() {
// disciplined code to manage things goes here
}
}
Some clients will get a DisciplinedProjectManagerImpl for one month.
public final class ShakyProjectMangerImpl implements ProjectManager {
public void manage() {
// shaky code to manage things goes here
}
}
After one month, half of clients that get DisciplinedProjectManagerImpl will get ShakyProjectManagerImpl.
public final class BadProjectMangerImpl implements ProjectManager {
public void manage() {
// bad code to manage things goes here
}
}
After two months, all clients will start to get BadProjectManagerImpl. None of these changes will require recompilation of client classes and none of them have to know the actual class name of the implementation classes.
In Java you cannot implement a superclass.
> > to extend is better than to implement an interface.
>
> Sometimes yes, sometimes no. As I said in my earlier
> post.
IMHO, the more I think about this, the more I dislike abstract classes. The problem with an abstract class is that it has two responsibilities - one being defining the contract, the other being providing some implementation that is just possibly common among its subclasses. Well these two responsibilities don't mix. From a pure DbC point of view, an interface isn't supposed to say anything more than the contract, while an implementation must be completely isolated from the interface(s) it implements.
> IMHO, the more I think about this, the more I dislike
> abstract classes. The problem with an abstract class
> is that it has two responsibilities - one being
> defining the contract, the other being providing some
> implementation that is just possibly common
> among its subclasses. Well these two responsibilities
> don't mix. From a pure DbC point of view, an
> interface isn't supposed to say anything more than the
> contract, while an implementation must be completely
> isolated from the interface(s) it implements.
There are a few things you can do with abstract classes which cannot be done with interfaces from an 'interface' level. For example, there is no way to specify a public interface without allowing anyone and everyone to implement it. You can specify an interface and then provide a factory for it without openeing the door for anyone to create a hacked up implementation of it. This is problematic when implementing an AbstractFactory pattern.
> There are a few things you can do with abstract
> classes which cannot be done with interfaces from an
> 'interface' level.
What things are you speaking of?
>For example, there is no way to specify a public interface without allowing anyone and everyone to implement it.
There is no way to specify an abstract class without allowing anyone and everyone to extend it.
You can create a factory for classes that implement an abstract interface or extend an abstract class.
> > There are a few things you can do with abstract
> > classes which cannot be done with interfaces from an
> > 'interface' level.
>
> What things are you speaking of?
Well, you see I followed it with a "For example" which means it's an example of what I am referring to.
> There is no way to specify an abstract class without
> allowing anyone and everyone to extend it.
No...
public abstract class Example
{
/* only inner classes can implement this 'interface' */
private Example() {}
}
public abstract class Example2
{
/* only classes in this package can extend this class */
Example2() {}
}
> You can create a factory for classes that implement an
> abstract interface or extend an abstract class.
But you can't create an interface and control who can implement it.
> public abstract interface ProjectManager {
> public abstract void manage();
> }
>
> Now hundreds of classes are written to use a
> ProjectManager. They all have variables of
> ProjectManager type and all of them are clients that
> call the manage method.
>
> [snip]
>
> After two months, all clients will start to get
> BadProjectManagerImpl. None of these changes will
> require recompilation of client classes and none of
> them have to know the actual class name of the
> implementation classes.
>
> In Java you cannot implement a superclass.
True, but you can extend it, and you can write all its clients to use variables of that superclass type.
So for this example, ProjectManager could just as well have been an abstract class. Note that I still think an interface is a better design choice here. I'm just pointing out that there's nothing here that you couldn't do if ProjectManager were a class instead of an interface. You'd just change all the "implements" to "extends" and everything else would be the same.
jverd at 2007-7-6 19:26:16 >
> IMHO, the more I think about this, the more I dislike
> abstract classes. The problem with an abstract class
> is that it has two responsibilities - one being
> defining the contract, the other being providing some
> implementation that is just possibly common
> among its subclasses.
One of the more common uses of abstract classes isn't instead of interfaces, but in addtion to them. Look at the Collections Framework in java.util. Collection, List, AbstractList, ArrayList, etc.
The interface spells out the contract, and then you have an abstract class that implements that interface with some reasonable default or common functionality that you expect some other implementations to find useful. Any implementation that finds the default/common stuff useful can extend the abstract class and fill in its own implementations for whatever methods the abstract class wasn't in a position to provide a default for.
On the other hand, you can choose to provide an impelementation from scratch that totally ignores the abstract class.
In the collections example, you'd usually do this: List list = new ArrayList();
but you could also do this: AbstractList list = new ArrayList();
The reason you usually do the first is, as you surmised, you code to the contract. The abstract class here isn't a replacement for the interface, it's just a headstart on implementing some parts of it for those that choose to use it.
> Well these two responsibilities
> don't mix. From a pure DbC point of view,
DbC?
> an
> interface isn't supposed to say anything more than the
> contract, while an implementation must be completely
> isolated from the interface(s) it implements.
What do you mean "an impelmentation must be completely isolated form the interface(s) it impelemnts"?
jverda at 2007-7-19 23:00:14 >
> The interface spells out the contract, and then you
> have an abstract class that implements that interface
> with some reasonable default or common functionality
> that you expect some other implementations to find
> useful. Any implementation that finds the
> default/common stuff useful can extend the abstract
> class and fill in its own implementations for whatever
> methods the abstract class wasn't in a position to
> provide a default for.
>
an interface spells out the contract means all classes that implent it need to have certains things in common. This can be achieved by using an abstract class. in this sense, an abstract class can provide the same thing as an interface can.
secondly, what an interface can not provide is implmentations, an abstract class can. this is an advantage only an abstract class has, over an interface.
in case an implementation provided by an abstract class in not suited for an sub class, it can certainly overridden by the sub class. do not you forget about this when comparing the two. :)
jverda at 2007-7-19 23:00:14 >
the only baaad thing in java is that you can not extend more than one class, abstract class included, while you can implent many interfaces. besides this, an abstract calass is better than an interface.
jverda at 2007-7-19 23:00:14 >
There really is only minor difference between abstract interface and abstract class. The abstract class can contain actual code in non-abstract methods, and this code becomes part of classes that extend the abstract class
So, if you have some common code that you think can be used by subclasses, then you would write abstract class and extend.
If you have no common logic, then you would write abstract interface and implement.
Best practice shows that abstract classes should implement interfaces anyway. So they are not competing strategies, but are working together. Abstract interface and Abstract class are friends.
Aside, an abstract interface is a class as well.
> There are a few things you can do with abstract
> classes which cannot be done with interfaces from an
> 'interface' level. For example, there is no way to
> specify a public interface without allowing anyone and
> everyone to implement it. You can specify an
> interface and then provide a factory for it without
> openeing the door for anyone to create a hacked up
> implementation of it. This is problematic when
> implementing an AbstractFactory pattern.
I not sure I understand where the problem might be.
> No...
> > public abstract class Example
> {
> /* only inner classes can implement this 'interface'
> */
> private Example() {}
> }
>
> > public abstract class Example2
> {
> /* only classes in this package can extend this class
> */
> Example2() {}
> }
>
> > You can create a factory for classes that implement
> an
> > abstract interface or extend an abstract class.
>
> But you can't create an interface and control who can
> implement it.
OK, I see, never mind my last reply. You mean you cannot selectively control who can implement which part of your interface. Well that's not the problem of the interface, but exactly that of the abstract class - it mixes up two different contracts. In your example, there are public methods that make up the public contract - the contract between this interface and its callers, and the implemention contract - the one between this base class and its subclasses. They are completely different things and should never have been put in the same thing to begin with.
> One of the more common uses of abstract classes isn't
> instead of interfaces, but in addtion to
> them. Look at the Collections Framework in java.util.
> Collection, List, AbstractList, ArrayList, etc.
[snipped]
I don't have problem with using an abstract class this way. It's merely a convenient base class. But then if you look at it from this angle, the original question becomes moot - an interface and an abstract class is an apple and an orange - one is for the external contract, the other for the internal implementation.
> > Well these two responsibilities
> > don't mix. From a pure DbC point of view,
>
> DbC?
I meant Design by Contract.
> > an
> > interface isn't supposed to say anything more than the
> > contract, while an implementation must be completely
> > isolated from the interface(s) it implements.
>
> What do you mean "an impelmentation must be completely
> isolated form the interface(s) it impelemnts"?
Perhaps "isolate" isn't the right word here...
What I meant it when a caller gets a reference to an object that implements a certain interface, all this caller can do is to invoke the methods defined on the interface, and nothing else.
> OK, I see, never mind my last reply. You mean you
> cannot selectively control who can implement
> which part of your interface.
I don't understand what you mean. If you create an interface and make it public, anyone can create an implementation of it. If the 'interface' is specified in an abstract class, you can make it 'read-only' i.e. it;s public for any class to use but not to implement. This cannot be done with interfaces.
> Well that's not
> the problem of the interface, but exactly that of the
> abstract class - it mixes up two different
> contracts. In your example, there are public methods
> that make up the public contract - the contract
> between this interface and its callers, and the
> implemention contract - the one between this base
> class and its subclasses. They are completely
> different things and should never have been put in the
> same thing to begin with.
Where is that in my example? Any time you make a method public in a class, you are creating part of an interface. How is a public abstract method not a contract between the callers and the class?
I think people make too big a deal about the differences between abstract classes and interfaces. interfaces are just a special type of abstract class which Java allows mulitple classes to extend. Don't get confused by the implements keyword. It's not fundamentally different from extends.
If Java allowed classes to extend multiple classes, interfaces would be basically unecessary. Don't get me wrong, I like interfaces and the whole paradigm of inheritance of implementation and inheritance of specification. But interfaces did not create this paradigm. There just a feature built upon that paradigm.
Another problem with interface is you can't implement a package-protected interface without making the implemented methods public.
Distinctions between principles of Object technology and Sun'simplementation of these principles in Java are realized when making the determination to extend or implement and should be per se recognised.
> > One of the more common uses of abstract classes
> isn't
> > instead of interfaces, but in addtion
> to
> > them. Look at the Collections Framework in
> java.util.
> > Collection, List, AbstractList, ArrayList, etc.
> [snipped]
>
> I don't have problem with using an abstract class this
> way. It's merely a convenient base class. But then
> if you look at it from this angle, the original
> question becomes moot - an interface and an abstract
> class is an apple and an orange - one is for the
> external contract, the other for the internal
> implementation.
Then we agree. See reply #1: tool for the job.
If I got off of that, it's because I thought I was responding to somebody else who already was.
jverda at 2007-7-19 23:00:14 >
jverd:
>>So for this example, ProjectManager could just as well have been an abstract class. Note that I still think an interface is a better design choice here. I'm just pointing out that there's nothing here that you couldn't do if ProjectManager were a class instead of an interface. You'd just change all the "implements" to "extends" and everything else would be the same.
Look out: You cannot change "implements" to "extends" without doing recompilation: ProjectManager should have accesible protected constructors, might have other protected methods which might crash with other subclases' own methods... And all of this might produce 100000000000 compilation errors when you do.
I agree an interface solution is always better to keep the user class unaware about class definition and possible version changes.
> Look out: You cannot change "implements" to "extends"
> without doing recompilation: ProjectManager should
> have accesible protected constructors, might have
> other protected methods which might crash with other
> subclases' own methods... And all of this might
> produce 100000000000 compilation errors when you do.
How would you have any errors? If all you do is turn an interface were turned into an abstract class, there cannot be anything but abstract methods. The only difference between implementing an interface and an extending and equivalent abstract class is that you can't extend anything else in the abstract class case.
>>How would you have any errors? If all you do is turn an interface were turned into an abstract class, there cannot be anything but abstract methods. The only difference between implementing an interface and an extending and equivalent abstract class is that you can't extend anything else in the abstract class case.
That's right - just in the case that you do not explicitly add protected code (variables or methods) to your abstract class. And If you don't... it's nonsense to have it as an abstract class - you'd better let it as an interface.
> That's right - just in the case that you do not
> explicitly add protected code (variables or methods)
> to your abstract class. And If you don't... it's
> nonsense to have it as an abstract class -
> you'd better let it as an interface.
But what if you only want classes in your package to be able to 'implement' your interface. What do you do then?
> jverd:
>
> >>So for this example, ProjectManager could just as
> well have been an abstract class. Note that I still
> think an interface is a better design choice here. I'm
> just pointing out that there's nothing here that you
> couldn't do if ProjectManager were a class instead of
> an interface. You'd just change all the "implements"
> to "extends" and everything else would be the same.
>
> Look out: You cannot change "implements" to "extends"
> without doing recompilation: ProjectManager should
> have accesible protected constructors, might have
> other protected methods which might crash with other
> subclases' own methods... And all of this might
> produce 100000000000 compilation errors when you do.
What's your point? Reply 9 seemed to be trying to make the point that for the code presented there, you can't use an abstract class. I was merely pointing out that for that example provided, in reply 9, that you could do the same thing with an abstract class instead of an interface.
I'm not saying the two are interchangeable. I was simply pointing out that that example did not demonstrate what the poster seemed to think it did.
jverda at 2007-7-19 23:00:19 >
>Reply 9 seemed to be trying to make the point that for the code presented there, you can't use an
abstract class.
No. I never stated that an abstract class would not work for the code presented in the post. The example demonstrates a case where implementing an abstract interface is a better choice that extending an abstract class.
In this example, there is no common logic or functionality to share or be inherited by subclasses. There is only a single method (manage) and the code in each of the implementations would be very different (disciplined, shaky, bad, etc.)
The benefit of interface inheritance, in this example, is that the implementing subclasses have the liberty of being able to extend a class if needed, now or in the future. If the implementation classes extended an abstract class, they could not extend a second class. If there is no common logic, there is no reason not to use abstract interface.
> No. I never stated that an abstract class would not
> work for the code presented in the post. The example
> demonstrates a case where implementing an abstract
> interface is a better choice that extending an
> abstract class.
The example demostrates no such thing. Where does it show how an interface is preferrable. As jverd has said, an abstract class could have been used in the example you gave with no significant changes. Given that's the case, how does your example show the benefits of interfaces?
> The benefit of interface inheritance, in this example,
> is that the implementing subclasses have the liberty
> of being able to extend a class if needed, now or in
> the future. If the implementation classes extended an
> abstract class, they could not extend a second class.
> If there is no common logic, there is no reason not to
> use abstract interface.
Actually I've pointed out a reason to use an abstract class when there is no commone functionality. You just choose to ignore it.
Also, 'absatract interface' is redundant. All interfaces are abstract. The JLs even says that you shouldn't declare interfaces as abstract.
> The example demostrates no such thing. Where does it
> show how an interface is preferrable.
Too bad you don't see it yet. Say next year we add some time tracker requirements to the ProjectManager and, no time or resources for development so we purchase a third-party component with class called TimeTracker that will do the job if we make ProjectManagers into TimeTrackers as well.
So we need,
public final class TTProjectManagerImpl extends TimeTracker implements ProjectManager {
public void manage() {
// Code here to do project things and also do time tracker things as well
}
}
If you used extends and abstract class, how would you integrate TimeTracker so that you can use TimeTracker logic in manage method and be able to pass instance of ProjectManager to TimeTracker classes expecting a TimeTracker and not a ProjectManager?
> Also, 'absatract interface' is redundant. All interfaces are abstract.
Using 'abstract' keyword in interface declaration is not redundant if it serves a purpose. To me it does server purpose because I like the way it looks and enjoy typing the word and having it in the declaration. Do you know what the JVM does when it sees an interface declaration without the 'abstract' keyword?
>The JLs even says that you shouldn't declare interfaces as abstract.
Don't know what a JL is and don't care what they say cause they are wrong. Either the compiler puts 'abstract' or developer puts 'abstract', no difference.
> Too bad you don't see it yet. Say next year we add
> some time tracker requirements to the ProjectManager
> and, no time or resources for development so we
> purchase a third-party component with class called
> TimeTracker that will do the job if we make
> ProjectManagers into TimeTrackers as well.
And where was this in your example? I never said I don't understand interfaces. I said your exmaple didn't show the value.
> If you used extends and abstract class, how would you
> integrate TimeTracker so that you can use TimeTracker
> logic in manage method and be able to pass instance of
> ProjectManager to TimeTracker classes expecting a
> TimeTracker and not a ProjectManager?
You can't. There are other solutions, such as aggregation.
> Using 'abstract' keyword in interface declaration is
> not redundant if it serves a purpose.
Do you understand the meaining of the word redundant?
> To me it does
> server purpose because I like the way it looks and
> enjoy typing the word and having it in the
> declaration.
Are you for real?
> Do you know what the JVM does when it
> sees an interface declaration without the 'abstract'
> keyword?
The JVM doesn't see keywords. It uses class files and the class file generated from an interface with the abstract keyword is no different from one without it.
> >The JLs even says that you shouldn't declare
> interfaces as abstract.
>
> Don't know what a JL is and don't care what they say
> cause they are wrong.
JLS: Java Language Specification. You should care and it's not wrong. How can you go around telling people how to program in Java and not know about the JLS?
> Either the compiler puts
> 'abstract' or developer puts 'abstract', no
> difference.
The compiler doesn't 'put abstract' it ignores the keyword when applied to interfaces. It's meaningless.
http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#238680
9.1.1.1 abstract Interfaces
Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs.
> >Reply 9 seemed to be trying to make the point that
> for the code presented there, you can't use an
> abstract class.
>
> No. I never stated that an abstract class would not
> work for the code presented in the post. The example
> demonstrates a case where implementing an abstract
> interface is a better choice that extending an
> abstract class.
Okay. Then I misunderstood the point you were trying to make with that post.
(Side note: All interfaces are abstract.)
> In this example, there is no common logic or
> functionality to share or be inherited by subclasses.
> There is only a single method (manage) and the code in
> each of the implementations would be very different
> (disciplined, shaky, bad, etc.)
Yep. Like I said, I think using an interface is better design there. I just thought you were trying to say you couldn't do the same thing with an abstract class.
jverda at 2007-7-19 23:00:19 >
> And where was this in your example? I never said I
> don't understand interfaces. I said your exmaple
> didn't show the value.
The value was there, you did not see it or were distracted by other unspeakable things.
> You can't. There are other solutions, such as
> aggregation.
You are right when you say "You can't", but wrong on aggregation. Aggregation will not solve the issue of passing an instance of ProjectManager as a TimeTracker to other classes in the TimeTracker component. The only way to reference a ProjectManager implementation class as a ProjectManager and a TimeTracker is to implement and extend. If you had extended an abstract class, you would be stuck on meeting the new time tracking requirements and most likely be removed from the premises.
> Do you understand the meaining of the word redundant?
Sure do, that is how I know you are using it incorrectly :o)
> The JVM doesn't see keywords. It uses class files and
> the class file generated from an interface with the
> abstract keyword is no different from one without it.
Ok big shot, so I meant the compiler. Big deal. The compiler looks for the keyword and adds it if it is not there. And this is why the class files are not different. If the compiler adds it or the developer includes, no difference.
> The compiler doesn't 'put abstract' it ignores the
> keyword when applied to interfaces. It's meaningless.
When it is not in the declaration, the compiler puts one in for you. When it is there, the compiler sees it and does not put it there.
> Every interface is implicitly abstract. This modifier is obsolete and should not be used in new programs.
Well, the authors don't not explain what they mean when they say the abstract modifier is obselete. They are really telling you that this is built into compiler and don't worry about it. It is so small an issue that they don't spend time explaining that the compiler sometimes adds syntax to the source files prior to compilation.
public abstract class ProjectManager {
public abstract void manage();
}
Now hundreds of classes are written to use a ProjectManager. They all have variables of ProjectManager type and all of them are clients that call the manage method.
public final class DisciplinedProjectManagerImpl extends ProjectManager {
public void manage() {
// disciplined code to manage things goes here
}
}
Some clients will get a DisciplinedProjectManagerImpl for one month.
public final class ShakyProjectMangerImpl extends ProjectManager {
public void manage() {
// shaky code to manage things goes here
}
}
After one month, half of clients that get DisciplinedProjectManagerImpl will get ShakyProjectManagerImpl.
public final class BadProjectMangerImpl extends ProjectManager {
public void manage() {
// bad code to manage things goes here
}
}
After two months, all clients will start to get BadProjectManagerImpl. None of these changes will require recompilation of client classes and none of them have to know the actual class name of the implementation classes.
-
Since you claim your example shows the value of interfaces, then you must believe that this example shows how abstract classes are just as good.
> The value was there, you did not see it or were
> distracted by other unspeakable things.
So you can't back up your claim.
> > You can't. There are other solutions, such as
> > aggregation.
>
> You are right when you say "You can't", but wrong on
> aggregation. Aggregation will not solve the issue of
> passing an instance of ProjectManager as a TimeTracker
> to other classes in the TimeTracker component.
You are basing this on the false assumption that you must always do things that way.
> The
> only way to reference a ProjectManager implementation
> class as a ProjectManager and a TimeTracker is to
> implement and extend. If you had extended an abstract
> class, you would be stuck on meeting the new time
> tracking requirements and most likely be removed from
> the premises.
That you can't imagine other solutions is your problem. People who can see many solutions are more valuable to an organization than those whoe see only one.
> Sure do, that is how I know you are using it
> incorrectly :o)
Clearly you don't know what it means.
redundant: Exceeding what is necessary or natural; superfluous.
> Ok big shot, so I meant the compiler. Big deal. The
> compiler looks for the keyword and adds it if it is
> not there.
No it doesn't. It ignores if it is there.
> When it is not in the declaration, the compiler puts
> one in for you. When it is there, the compiler sees it
> and does not put it there.
Why would the compiler add a redundant term? And where does it add it? It doesn't change the source file.
> Well, the authors don't not explain what they mean
> when they say the abstract modifier is obselete. They
> are really telling you that this is built into
> compiler and don't worry about it. It is so small an
> issue that they don't spend time explaining that the
> compiler sometimes adds syntax to the source files
> prior to compilation.
No the author says: "should not be used in new programs." There's no ambuguity there. And the meaning of obsolete doesn't need to be explained. If you don't know what it means you can look it up. I'll save you at trip to the dictionary.
obsolete: no longer in use or no longer useful
> > And where was this in your example? I never said I
> > don't understand interfaces. I said your exmaple
> > didn't show the value.
>
> The value was there, you did not see it or were
> distracted by other unspeakable things.
No. That example you gave does not demonstrate any reason to use an interface over an abstract class. Nor does your comment "you can't implement a superclass." It is true that an interface is probably better in that situation, but nothing in that post of yours shows why.
> > Do you understand the meaining of the word
> redundant?
>
> Sure do, that is how I know you are using it
> incorrectly :o)
No. He used it correctly, in the sense that it adds no information, merely repeats information that's already there. The keyword "interface" already implicitly contains the information that it's abstract, so adding the word "abstract" is redundant.
> When it is not in the declaration, the compiler puts
> one in for you. When it is there, the compiler sees it
> and does not put it there.
Where does the compiler put it? It doesn't end up in the class file. Are you saying the compiler creates a temp file or a stream that mimics your source but adds the word "abstract"?
> > Every interface is implicitly abstract. This
> modifier is obsolete and should not be used in new
> programs.
>
> Well, the authors don't not explain what they mean
> when they say the abstract modifier is obselete.
What's to explain? All interfaces are abstract so there's no reason to add the word to your code. Seems pretty straightforward.
> They
> are really telling you that this is built into
> compiler and don't worry about it. It is so small an
> issue that they don't spend time explaining that the
> compiler sometimes adds syntax to the source files
> prior to compilation.
>
What do you mean "adds syntax"? What exactly do you think happens?
jverda at 2007-7-19 23:00:19 >
> No. That example you gave does not demonstrate any
> reason to use an interface over an abstract class. Nor
> does your comment "you can't implement a superclass."
> It is true that an interface is probably better in
> that situation, but nothing in that post of yours
> shows why.
Yes it does. You can see that the other guys implementation classes that extend abstract ProjectManager will not be able to extend TimeTracker to meet the new time tracking requirements. In my example, it is evident that the ability to freely extend a class is enjoyed by the implementation classes that implement the ProjectManager interface rather than extend a ProjectManager abstract class.
> No. He used it correctly, in the sense that it adds no
> information, merely repeats information that's already
> there. The keyword "interface" already implicitly
> contains the information that it's abstract, so adding
> the word "abstract" is redundant.
No it is definately not redundant because I like to see it in my source code. So it has a purpose!
'Redundant' is an adjective meaning something exceeding what is necessary or superfluous. The term is needed to really convey the abstractedness of these objects!
> Where does the compiler put it? It doesn't end up in
> the class file. Are you saying the compiler creates a
> temp file or a stream that mimics your source but adds
> the word "abstract"?
Yes that is what I am saying. The compiler will add things to make little shortcuts for the developer. The addition of the 'abstract' keyword is only one of many such niceties. The insertion of fully qualified class names is another, hint, hint... The resolution of increment/decrement operators is another.
In source code you put:
count++;
When compiler reads this, it writes
count=count+1;
And then compiles a class file.
So the programmer saves 6 keystrokes, but the compiler still needs to see "count=count+1;" so he adds a bit here and there and poof!! a class file is born.
> Yes it does. You can see that the other guys
> implementation classes that extend abstract
> ProjectManager will not be able to extend TimeTracker
> to meet the new time tracking requirements. In my
> example, it is evident that the ability to freely
> extend a class is enjoyed by the implementation
> classes that implement the ProjectManager interface
> rather than extend a ProjectManager abstract class.
There is no reference to any TimeTracker class in your example. A person would alread have to know the value of using interfaces work in order to 'see' this in your exmaple. Your example doesn't teach anyone anything.
> No it is definately not redundant because I like to
> see it in my source code. So it has a purpose!
> 'Redundant' is an adjective meaning something
> exceeding what is necessary or superfluous. The term
> is needed to really convey the abstractedness of these
> objects!
That is the silliest thing I've seen in these forums in a while. How does your 'liking' to type extra words make it less uneccesary?
> Yes that is what I am saying. The compiler will add
> things to make little shortcuts for the developer. The
> addition of the 'abstract' keyword is only one of many
> such niceties. The insertion of fully qualified class
> names is another, hint, hint... The resolution of
> increment/decrement operators is another.
>
> In source code you put:
>
> count++;
>
> When compiler reads this, it writes
>
> count=count+1;
That's complete nonsense. Show me one piece of evidence that this is what the compiler does. You never answered the "where" question either. You seem to have a complete misunderstanding of what the compiler does. Do you think Java is a scripting language? maybe you should look at the JLS. You might learn few things.
> No it is definately not redundant because I like to
> see it in my source code. So it has a purpose!
The definition of redundant is not "doesn't have a purpose." Something can be redundant and still have a purpose. Even a purpose as silly as yours.
> 'Redundant' is an adjective meaning something
> exceeding what is necessary or superfluous.
Yes and liking something does not make it necessary. I like choclate. That doesn't make it necessary.
> The term
> is needed to really convey the abstractedness of these
> objects!
Abstractedness is not a word. Even if it was, this probably doesn't make sense.
> > No. That example you gave does not demonstrate any
> > reason to use an interface over an abstract class.
> Nor
> > does your comment "you can't implement a
> superclass."
> > It is true that an interface is probably better in
> > that situation, but nothing in that post of yours
> > shows why.
>
> Yes it does. You can see that the other guys
> implementation classes that extend abstract
> ProjectManager will not be able to extend TimeTracker
> to meet the new time tracking requirements.
Your original ProjectManager example neither mentioned nor implied anything about TimeTracker. Given that your whole point is supposedly that Java doesn't support MI of implementation (doesn't allow you to extend more than one class), one might expect you to have mentioned something to that effect. You post only talked about coding to the interface (which works just as well with a base class, abstract or concrete) and swapping implementations without changing client code (which also works just as well with a base class, concrete or abstract).
> In my
> example, it is evident that the ability to freely
> extend a class is enjoyed by the implementation
> classes that implement the ProjectManager interface
> rather than extend a ProjectManager abstract class.
No, your example doesn't convey that information, nor is it indicated that that was any part of the point you were making. It is evident to anyone who understands interfaces and abstrct classes that interface implementations can extend any class they choose, but neither that fact nor its value is indicated in your example.
> No it is definately not redundant because I like to
> see it in my source code. So it has a purpose!
Whether you like to see it or not doesn't alter the fact that it carries no information, and is therefore redundant.
> 'Redundant' is an adjective meaning something
> exceeding what is necessary or superfluous. The term
> is needed to really convey the abstractedness of these
> objects!
No. They are abstract. That sentence, or its equivalent in the JLS, or a tutorial, is all that's needed to convey their abstractness.
>
> > Where does the compiler put it? It doesn't end up in
> > the class file. Are you saying the compiler creates
> a
> > temp file or a stream that mimics your source but
> adds
> > the word "abstract"?
>
> Yes that is what I am saying. The compiler will add
> things to make little shortcuts for the developer. The
> addition of the 'abstract' keyword is only one of many
> such niceties.
Where? It doesn't change my source code. There's no reason for it to insert it at intermediate step since it also doesn't show up in the class file and the compiler doesn't need it for anything, since it knows interfaces are always abstract.
> In source code you put:
>
> count++;
>
> When compiler reads this, it writes
>
> count=count+1;
Where does it write that? Why?
> And then compiles a class file.
>
> So the programmer saves 6 keystrokes, but the compiler
> still needs to see "count=count+1;"
Nonsense. The JLS defines what count++ means. The compiler turns that into the corresponding bytecode. There's abolutely no reason for it to go through the intermediate step, nor is count=count+1 any more "natural" or "fundamental".
jverda at 2007-7-19 23:00:19 >
>Where? It doesn't change my source code. There's no reason for it to insert it at intermediate step since it >also doesn't show up in the class file and the compiler doesn't need it for anything, since it knows >interfaces are always abstract.
No one cares about changing your source code. Of course the instruction is in the class file. Of course the compiler knows that interfaces are abstract, it knows this and makes the appropriate changes to what you put in the source code.
It understands that they must be no ambiguity when asking the CPU to execute instructions. It also understands that to carry out the processing for something like 'count=count+1;', it must generate something like
'0110001101101111011101010110111001110100001111010110001101101111011101010110111001110100001010110011000100111011'.
So when it reads binary for 'count++;' '0110001101101111011101010110111001110100001010110010101100111011'
in your source code, it adds the extra data to create the proper instructions for all things related to 'count=count+1;' or the binary number from the previous paragraph.
The CPU is not smart enough to understand that 'count++;' and 'count=count+1;' mean the same thing to humans. This ambiguit y is for humans only and the Java language lets us get away with it in our source code so we can think better. The compiler steps in and helps us out by filling in the 'blanks'.
Early programmers did not have these luxuries and this made programming with these languages a bit more difficult. Programming languages have evolved over time but the CPU still only understands one.
Create some programs in Assembly and we can then really talk about "abstractedness" .
Here is a link http://asmjournal.freeservers.com/. Good luck!
> >Where? It doesn't change my source code. There's no
> reason for it to insert it at intermediate step since
> it >also doesn't show up in the class file and the
> compiler doesn't need it for anything, since it knows
> >interfaces are always abstract.
>
> No one cares about changing your source code. Of
> course the instruction is in the class file. Of course
> the compiler knows that interfaces are abstract, it
> knows this and makes the appropriate changes to what
> you put in the source code.
Okay, then WHERE? WHERE WHERE WHERE WHERE does the compiler put the word "abstract" in? I've asked you that several times and you haven't answered. And WHY? The VM also knows interfaces are abstract. If a .class file represents an interface, there's no reason for the compiler to add an additional indication that it's abstract.
> It understands that they must be no ambiguity when
> asking the CPU to execute instructions. It also
> understands that to carry out the processing for
> something like 'count=count+1;', it must generate
> something like
> '011000110110111101110101011011100111010000111101011000
> 1011011110111010101101110011101000010101100110001001110
> 1'.
>
> So when it reads binary for 'count++;'
> '01100011011011110111010101101110011101000010101100101
> 1100111011'
> in your source code, it adds the extra data to create
> the proper instructions for all things related to
> 'count=count+1;'
No. You're confused. In both the bytecode and the machine language for the target processor that gets generated from it, there's probably a single instruction to increment a variable. That instruction is NEITHER x=x+1 NOR x++ NOR for that matter x+=1. It is simply the inc instruction. It has no more relation to any of those higher level constructs than to any other. All of them get compiled to that same inc instruction, and they don't have to "go through" x=x+1 first.
> The CPU is not smart enough to understand that
> 'count++;' and 'count=count+1;' mean the same thing to
> humans.
Neither the CPU nor the VM ever sees either of those.
> This ambiguit y is for humans only and the
> Java language lets us get away with it in our source
> code so we can think better. The compiler steps in
> and helps us out by filling in the 'blanks'.
Yes, the compiler turns x++ into something the VM can understand, and the VM turns it into something the CPU can understand. That doesn't mean the compiler has to first turn it into x=x+1.
> Create some programs in Assembly
I have. I understand what's going on. You don't.
jverda at 2007-7-19 23:00:28 >
> I have. I understand what's going on. You don't.Or at the very least, you're trying to say the same thing I am, but not getting your ideas across very clearly.
jverda at 2007-7-19 23:00:28 >
dubwai:
>>But what if you only want classes in your package to be able to 'implement' your interface. What do you do then?
Well, that would change completely the problem's initial setup:
>>Now hundreds of classes are written to use a ProjectManager. (AMPHIGIS_X in reply 9).
I'm only saying that interfacing supports changes much better than inheritance. If you want to get polymorphism on some class, you'd better use implementing. Inheritance serves mainly for code reutilization.
> I'm only saying that interfacing supports changes much
> better than inheritance.
Minor point: Implementng an interface is a form of inheritance.
> If you want to get
> polymorphism on some class, you'd better use
> implementing. Inheritance serves mainly for code
> reutilization.
No. Code reuse is not a good reason to use inheritance.
jverda at 2007-7-19 23:00:28 >
> I'm only saying that interfacing supports changes much
> better than inheritance. If you want to get
> polymorphism on some class, you'd better use
> implementing. Inheritance serves mainly for code
> reutilization.
I understand the value of interfaces. I think that itermediate developers overuse interfaces. I know I did for a while. You don't need a separate interface for every class you create.
Interfaces are no more polymorphic than classes. They are a special type of abstract class. The great thing is that interfaces formalize the concept of separating the 'interface' from the implementation. However, that doesn't mean every class has to have a corresponding interface.
To throw in a little pendanting b-sniffing (sorry, jverd, for treading on your turf):
> It understands that they must be no ambiguity when
> asking the CPU to execute instructions. It also
> understands that to carry out the processing for
> something like 'count=count+1;', it must generate
> something like
[snip]
> So when it reads binary for 'count++;'
[snip
> in your source code, it adds the extra data to create
> the proper instructions for all things related to
> 'count=count+1;' or the binary number from the
> previous paragraph.
Um, no. The Java compiler sees certain things in your source code, and translates them to specific patterns of bytecode. It doesn't translate one source to another before compiling it. All of this is covered in a standard CS curriculum.
However, assuming that you haven't gone through a standard CS curriculum (my degree's in history, btw), you can demonstrate all of this for yourself using the tools provided with Java, and a reference to the JVM opcode spec (http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions.doc.html).
So, for example, we have this code:
public static void main(String[] argv)
throws Exception
{
int a = 0;
int b = 0;
int c = 0;
a++;
b = b + 1;
c += 1;
}
We can run the java compiler, and then javap, and we get the following bytecode listing (which I've commented):
public static void main(java.lang.String[]);
throws java/lang/Exception
Code:
0:iconst_0// a = 0
1:istore_1
2:iconst_0// b = 0
3:istore_2
4:iconst_0// c = 0
5:istore_3
6:iinc1, 1// a++
9:iload_2 // b = b + 1
10: iconst_1
11: iadd
12: istore_2
13: iinc3, 1// c += 1
16: return
> It understands that they must be no ambiguity when
> asking the CPU to execute instructions. It also
> understands that to carry out the processing for
> something like 'count=count+1;', it must generate
> something like
> '011000110110111101110101011011100111010000111101011000
> 1011011110111010101101110011101000010101100110001001110
> 1'.
I've built digitial electronics from transistors and I've written machine code to process assmebly instructions and then written the assmebly. You don't know what you are talking about. The bytecode instruction for incrementing a variable, whether count=count+1 and count++ is not anywhere near that long.
> So when it reads binary for 'count++;'
> '01100011011011110111010101101110011101000010101100101
> 1100111011'
> in your source code, it adds the extra data to create
> the proper instructions for all things related to
> 'count=count+1;' or the binary number from the
> previous paragraph.
The instruction for either of these is:
iinc index 1
As defined here:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions2.doc6.html#iinc
the following code:
public int methodA()
{
int i = 0;
i++;
return i;
}
public int methodB()
{
int i = 0;
i = i + 1;
return i;
}
produces these bytecodes (using javap):
Method int methodA()
0 iconst_0
1 istore_1
2 iinc 1 1
5 iload_1
6 ireturn
Method int methodB()
0 iconst_0
1 istore_1
2 iinc 1 1
5 iload_1
6 ireturn
I'll also point out that the name for the bytecode instruction generated by i=i+1 is 'increment'.
> The CPU is not smart enough to understand that
> 'count++;' and 'count=count+1;' mean the same thing to
> humans.
The CPU never sees anything like the source code. That you think it does demonstrates a groos misunderstanding of the JVM and computer architecture in general.
> This ambiguit y is for humans only and the
> Java language lets us get away with it in our source
> code so we can think better. The compiler steps in
> and helps us out by filling in the 'blanks'.
You are confused.
> Early programmers did not have these luxuries and this
> made programming with these languages a bit more
> difficult. Programming languages have evolved over
> time but the CPU still only understands one.
>
> Create some programs in Assembly and we can then
> really talk about "abstractedness" .
> Here is a link http://asmjournal.freeservers.com/.
> Good luck!
I have a degree in Computer Science but thanks anyway.
> To throw in a little pendanting b-sniffing (sorry,> jverd, for treading on your turf):**** you k! [shakes fist] You beat me to the punch!
> > To throw in a little pendanting b-sniffing (sorry,> > jverd, for treading on your turf):> > **** you k! [shakes fist] You beat me to the> punch!Pfft. You're both slow. (See reply 45.)
jverda at 2007-7-19 23:00:28 >
> Pfft. You're both slow. (See reply 45.)I saw your post and I meant to add to it. I'm annoyed because k clearly preemptively mimicked my response.
I never said that compiler makes changes to source code and creates a new form of source code. I state that the compiler modifies what you put in the source code to eliminate ambiguity and transforms it into the instructions to operate correctly.
count++; and count=count+1; are two different ways for executing the same processing. The ternary operator enables a second way of writing an if statement. The conversion of any language higher than machine language requires resolution of multiple ways of saying the same thing.
So public abstract interface is what is required and public interface is a shorthand for what is required. The Java language allows you to use these shortcuts, BUT that does not mean the resolution to what is required is eliminated. The compiler will add what is required to make it work.
> I never said that compiler makes changes to source
> code and creates a new form of source code. I state
> that the compiler modifies what you put in the source
> code to eliminate ambiguity and transforms it into the
> instructions to operate correctly.
It doesn't modify anything. It produces byte codes based on the source code. What is modified?
> count++; and count=count+1; are two different ways for
> executing the same processing. The ternary operator
> enables a second way of writing an if statement. The
> conversion of any language higher than machine
> language requires resolution of multiple ways of
> saying the same thing.
That's a natural outcome of compilation. You are pointing out the most trivial aspects of complilation and interpretation in an imprecise (to say the least) way.
> So public abstract interface is what is required and
> public interface is a shorthand for what is required.
> The Java language allows you to use these shortcuts,
> BUT that does not mean the resolution to what is
> required is eliminated. The compiler will add what is
> required to make it work.
The compiler will do the same thing with an interface whether it is explictly abstract or not. THis idea that the compiler "adds" abstract to the interface makes no sense. Are you claiming that the compiler can't figure out that interfaces are abstract without telling itself that they are? As if the compiler wouldn't know what to do with the interface if it didn't have that modifier that it added. If you think that the writers of the compiler must go through a stupid hack like that in order to make it work properly, I would hate to see your code.
> I never said that compiler makes changes to source
> code and creates a new form of source code. I state
> that the compiler modifies what you put in the source
> code to eliminate ambiguity and transforms it into the
> instructions to operate correctly.
If my code reads x=x+1, what does the compiler do?
If my code reads x++, what does the compiler do differently?
You stated that it changes x++ to x=x+1. You haven't answered where or why that change is made.
There is no ambiguity in x++. The JLS defines what it means, the compiler turns is into the corresponding bytecodes. The exact same thing happens with x=x+1. The compiler does NOT, contrary to what you said, turn x++ into x=x+1.
>
> count++; and count=count+1; are two different ways for
> executing the same processing. The ternary operator
> enables a second way of writing an if statement. The
> conversion of any language higher than machine
> language requires resolution of multiple ways of
> saying the same thing.
Yeah, but the compiler converts the source code into machine code. It doesn't convert it into another form of source code on the way. Neither the VM nor the CPU understands x=x+1. Neither one ever sees x=x+1. If I put x++, the compiler turns that into the exact same bytecode (probably) as if I put x=x+1. If I start with x++ x=x+1 does not come into play anywhere.
> So public abstract interface is what is required and
> public interface is a shorthand for what is required.
> The Java language allows you to use these shortcuts,
> BUT that does not mean the resolution to what is
> required is eliminated.
No. All interfaces are by definition abstract. I haven't looked at the bytecode, but I'd be willing to bet that there's an indicator that says that a given .class file is for an interface, but there is no additional indication to say it's abstract.
> The compiler will add what is
> required to make it work.
Again, WHERE? If the comiler is "adding" something--according to you, the word "abstract"--then it must be putting it somewhere. Where is it putting it? In the source file? No. In the .class file? No. Then where?
I don't keep asking this because I don't understand the process and am hoping you'll enlighten me. I keep asking because I'm hoping that when you can't answer it you'll see where you're confused.
jverda at 2007-7-19 23:00:28 >
And stop limiting your view to the ASCII characters you see in a text editor. ASCII characters are only for human consumption and computer does not understand what these characters mean. Compiler does not add ASCII characters "a b s t r a c t" to source code. Compiler translates what is in source code, resolves the ambiguities of the language, and creates byte code that will be read by JVM and then translated to machine code and then machine code is processed by CPU.
Now what does "resolve ambiguities mean"? The fact that the Java language lets you leave out the word "abstract" from an interface declaration does not, in no way, mean that the "meaning" of this keyword is not required. The compiler will add the "meaning" of this keyword to the bytecode and when the JVM reads the bytecode it will not have to resolve the ambiguity of multiple ways of saying the same thing.
interface is not an ambiguity, it's a language concept.
> interface is not an ambiguity, it's a language> concept.No comments from peanut gallery!!
> And stop limiting your view to the ASCII characters
> you see in a text editor. ASCII characters are only
> for human consumption and computer does not understand
> what these characters mean. Compiler does not add
> ASCII characters "a b s t r a c t" to source code.
> Compiler translates what is in source code, resolves
> the ambiguities of the language, and creates byte code
> that will be read by JVM and then translated to
> machine code and then machine code is processed by
> CPU.
You were the one impying that the CPU reads ascii. No one else thinks that needs to be clarified. Why do you think this is an important point? It's obvious. Do you think this is some complex concept? We are way ahead of you. If you'd stop harping on these trivial concepts you might uinderstand what we are telling you.
> Now what does "resolve ambiguities mean"? The fact
> that the Java language lets you leave out the word
> "abstract" from an interface declaration does not, in
> no way, mean that the "meaning" of this keyword is not
> required. The compiler will add the "meaning" of this
> keyword to the bytecode and when the JVM reads the
> bytecode it will not have to resolve the ambiguity of
> multiple ways of saying the same thing.
What ambiguity? There is no such thing as a concrete interface. Interface implies abstract.
In any event you have steered way off the point that there's no point in adding abstract to your interface declaration. The compiler doesn't need it and won't do anything different with it. The writers of the Java language spec say not to do it. I think it's clear you just didn't know that and that you are trying to rationalize your ignorance.
> And stop limiting your view to the ASCII characters
> you see in a text editor. ASCII characters are only
> for human consumption and computer does not understand
> what these characters mean.
Yes, I know that. When you say things like "compiler adds 'abstract'" and "compiler turns x++ into x=x+1" it sounds like you don't get that concept, however.
> Compiler does not add
> ASCII characters "a b s t r a c t" to source code.
Then what precisely do you mean when you say it adds "abstract"? Are you saying there's a flag in a class file that indicates whether that class is abstract, and another flag that indicates that it's an interface, and that BOTH of these are present in interfaces, and that it would be possible to manually construct a class file for an interface that was marked as non-abstract?
I'm not really familiar with the details of .class file format, but I'd bet the above is NOT the case.
You're really not explaining yourself very well.
What exactly is the process by which the compiler "adds abstract"?
> Compiler translates what is in source code, resolves
> the ambiguities of the language,
Neither interface declaration (with or without the redundant abstract keyword) nor x++ is ambiguous.
> Now what does "resolve ambiguities mean"? The fact
> that the Java language lets you leave out the word
> "abstract" from an interface declaration does not, in
> no way, mean that the "meaning" of this keyword is not
> required.
The fact that you can (and should) leave it out because it's ambiguous means that source code with the word means exactly the same as source code without the word.
> The compiler will add the "meaning" of this
> keyword to the bytecode and when the JVM reads the
> bytecode it will not have to resolve the ambiguity of
> multiple ways of saying the same thing.
So you ARE saying that there's a specific indication of abstract that's present in a .class file for an interface. Okay, then one can edit that file, change the value of that flag, and have a .class file for a non-abstract interface.
Where in the spec is this described? What's the position and value? What will the VM do when I change the value to non-abstract?
jverda at 2007-7-19 23:00:33 >
> Neither interface declaration (with or without the
> redundant abstract keyword) nor x++ is ambiguous.
x++; a part of this expression means to increment the value of x by 1
x=x+1; a part of this expression means to increment the value of x by 1
These are two ways of saying the same thing. Maybe 'ambiguous' is the wrong term, but my point is that the computer only has one instruction that will increment the value of x by 1. The Java language provides more than one way of saying the same thing. The role of the compiler is to read and interpret these commands and translate them to the one instruction that the computer will understand.
The Java import statement allows you to introduce the fully-qualified name of a class with one statement.
This enables you to leave out the full name and use only the short name in your source code, following the import statement of course. This is a shortcut provided by the language. This does not mean that the full, qualified class name is not required wherever the class name is specified. The compiler adds the full class name for you. The same way the compiler adds the calls to super() prior to instantiating subclasses. Does the programmer always have to type "super()" in the source code. No. And why, because the compiler is adding this for you.
import com.model.Ship;
public class Yard {
public Yard(Ship s) {
}
}
or
public class Yard {
public Yard(com.model.Ship s) {
}
}
> > Neither interface declaration (with or without the
> > redundant abstract keyword) nor x++ is ambiguous.
>
> x++; a part of this expression means to increment the
> value of x by 1
>
> x=x+1; a part of this expression means to increment
> the value of x by 1
>
> These are two ways of saying the same thing. Maybe
> 'ambiguous' is the wrong term, but my point is that
> the computer only has one instruction that will
> increment the value of x by 1. The Java language
> provides more than one way of saying the same thing.
> The role of the compiler is to read and interpret
> these commands and translate them to the one
> instruction that the computer will understand.
Yes, I know that. (Although it's certainly possible that, say, x++ would get translated into sth. like INC X and x=x+1 would become sth. like ADD X 1, but presumably the compiler is smarter than that.)
However, you said:
In source code you put:
count++;
When compiler reads this, it writes
count=count+1;
And then compiles a class file.
So either you misstated what you were trying to say, or I misunderstood what you said, or else you're saying that the string "x++" becomes the string "x=x+1" and then that gets turned into the INC instruction. That's silly. Why would the compiler do that? It doesn't need to pre-translate for itself.
So, again, I ask you: What do you mean by "x++ becomes x=+1" or "the compiler adds abstract"? What exactly is happening, and where, and why?
> The Java import statement allows you to introduce the
> fully-qualified name of a class with one statement.
> This enables you to leave out the full name and use
> only the short name in your source code, following the
> import statement of course. This is a shortcut
> provided by the language. This does not mean that the
> full, qualified class name is not required wherever
> the class name is specified.
That is a different situation than x++ vs. x=x+1. x++ always means exactly one thing. It can not be ambiguous. Date can mean multiple things, so you have to make it clear to the compiler which package's Date you want. Therefore this analogy doesn't apply.
In fact, this is the reverse of x++ vs. x=x+1. In that case you have two different language constructs that mean the same thing. No ambiguity. Here you have one token (Date) with mutiple potential meanings, so there is ambiguity, so you must indicate which Date, and likewise the compiler must preserve that indication for the VM.
jverda at 2007-7-19 23:00:33 >
Sorry. Re-posting, w/o runaway italics...
> > Neither interface declaration (with or without the
> > redundant abstract keyword) nor x++ is ambiguous.
>
> x++; a part of this expression means to increment the
> value of x by 1
>
> x=x+1; a part of this expression means to increment
> the value of x by 1
>
> These are two ways of saying the same thing. Maybe
> 'ambiguous' is the wrong term, but my point is that
> the computer only has one instruction that will
> increment the value of x by 1. The Java language
> provides more than one way of saying the same thing.
> The role of the compiler is to read and interpret
> these commands and translate them to the one
> instruction that the computer will understand.
Yes, I know that. (Although it's certainly possible that, say, x++ would get translated into sth. like INC X and x=x+1 would become sth. like ADD X 1, but presumably the compiler is smarter than that.)
However, you said:
In source code you put:
count++;
When compiler reads this, it writes
count=count+1;
And then compiles a class file.
So either you misstated what you were trying to say, or I misunderstood what you said, or else you're saying that the string "x++" becomes the string "x=x+1" and then that gets turned into the INC instruction. That's silly. Why would the compiler do that? It doesn't need to pre-translate for itself.
So, again, I ask you: What do you mean by "x++ becomes x=+1" or "the compiler adds abstract"? What exactly is happening, and where, and why?
> The Java import statement allows you to introduce the
> fully-qualified name of a class with one statement.
> This enables you to leave out the full name and use
> only the short name in your source code, following the
> import statement of course. This is a shortcut
> provided by the language. This does not mean that the
> full, qualified class name is not required wherever
> the class name is specified.
That is a different situation than x++ vs. x=x+1. x++ always means exactly one thing. It can not be ambiguous. Date can mean multiple things, so you have to make it clear to the compiler which package's Date you want. Therefore this analogy doesn't apply.
In fact, this is the reverse of x++ vs. x=x+1. In that case you have two different language constructs that mean the same thing. No ambiguity. Here you have one token (Date) with mutiple potential meanings, so there is ambiguity, so you must indicate which Date, and likewise the compiler must preserve that indication for the VM.
jverda at 2007-7-19 23:00:33 >
> These are two ways of saying the same thing. Maybe
> 'ambiguous' is the wrong term, but my point is that
> the computer only has one instruction that will
> increment the value of x by 1. The Java language
> provides more than one way of saying the same thing.
> The role of the compiler is to read and interpret
> these commands and translate them to the one
> instruction that the computer will understand.
Yes, that's what we've been saying the whole time.
> The Java import statement allows you to introduce the
> fully-qualified name of a class with one statement.
> This enables you to leave out the full name and use
> only the short name in your source code, following the
> import statement of course. This is a shortcut
> provided by the language. This does not mean that the
> full, qualified class name is not required wherever
> the class name is specified. The compiler adds the
> full class name for you. The same way the compiler
> adds the calls to super() prior to instantiating
> subclasses. Does the programmer always have to type
> "super()" in the source code. No. And why, because the
> compiler is adding this for you.
1. What's your point? Are you saying you should explicity do everything that the compiler will do implicity?
2. Just because this is true for other parts of the language doesn't make it true for interfaces. You need to show how it's true for interfaces.
3. The Java Language Sepcification it's pointless and not to do it. What more do you need?
The compiler turns syntactical constructs into bytecode instructions. It has been demonstrated that the syntactical constructs "x = x+1" and "x++" get compiled into the same bytecode (one concept "add-one-to-variable").
In the same way the syntactical constructs "abstract interface" and "interface" get compiled into the same bytecode. However, unless someone shows me otherwise, I'll believe it gets compiled into one concept "interface", not two concepts "abstract" and "interface".
> In the same way the syntactical constructs "abstract
> interface" and "interface" get compiled into the same
> bytecode. However, unless someone shows me otherwise,
> I'll believe it gets compiled into one concept
> "interface", not two concepts "abstract" and
> "interface".
Thank you for stating it much more concisely than I was able to.
It is possible that it gets compiled to two separate concepts, but it's certainly not necessary. The only reasons I can imagine for doing so:
* It might have been easier to spec/implement the compiler, VM, .class file format it the two were kept orthogonal, even though certain combinations have no meaning.
* If the designers deliberately wanted to keep them separate just in case someday the concept of a non-abstract interface were added (whatever the farg that would be).
Neither one seems particularly likely, and, even if it is compiled into two separate concepts (which I'll believe iff I see it), it's certainly not necessary to do that, since the JLS says all interfaces are abstract.
jverda at 2007-7-19 23:00:33 >
No, I brought up the import statement thing to illustrate that the compiler adds syntax to compensate for the short cuts it provides to programmers. This is just another example of what we are speaking of. The exact rationale for the import statement is different that the x++; x=x+1; thing.
The fact that the compiler makes additions to what is in source code is the fundamental point. The actual specifics as to why it does this for this and that for that are not pertinent to our discussion. The compiler does add code that in not source code. The bytes related to space characters are also deleted from source code.
This discussion has been fun. However, I am getting a bit weary and this is a trivial point. So, I think I am going to retire. I will look out for final comments though. Have a nice weekend!!
> The fact that the compiler makes additions to what is
> in source code is the fundamental point. The actual
> specifics as to why it does this for this and that for
> that are not pertinent to our discussion. The compiler
> does add code that in not source code. The bytes
> related to space characters are also deleted from
> source code.
You're on crack. Saying spaces are deleted from source code is meaningless, as that implies that x=x+1 remains. It doesn't. You're mixing up levels of abstraction here.
The compiler DOES NOT add "abstract" and it DOES NOT turn x++ into x=x+1 and you haven't provided one bit of support to your claims that is does.
> This discussion has been fun. However, I am getting a
> bit weary and this is a trivial point.
And your claims are flat-out wrong.
jverda at 2007-7-19 23:00:33 >
> The compiler turns syntactical constructs into
> bytecode instructions. It has been demonstrated that
> the syntactical constructs "x = x+1" and "x++" get
> compiled into the same bytecode (one concept
> "add-one-to-variable").
>
> In the same way the syntactical constructs "abstract
> interface" and "interface" get compiled into the same
> bytecode. However, unless someone shows me otherwise,
> I'll believe it gets compiled into one concept
> "interface", not two concepts "abstract" and
> "interface".
Thank you.
'abstract interface' and 'interface' get compiled into the same bytecode.
It is compiled into the one concept of an 'abstract interface'
It is not compiled into two concepts because there is only one concept - "abstract interface"
When you leave out the abstract keyword, compiler "adds" the meaning and compiles the concept of "abstract interface".
public abstract interface top {}
public interface top {}
These are the same thing.
> The compiler> does add code that in not source code. Not in any way that's pertinent to or lends support to your claims.
jverda at 2007-7-19 23:00:33 >
> Thank you.
> 'abstract interface' and 'interface' get compiled into
> the same bytecode.
> It is compiled into the one concept of an 'abstract
> interface'
Yes, that's what we've been saying.
> It is not compiled into two concepts because there is
> only one concept - "abstract interface"
There is only one concept: It it both "interface" and "abstract inteface" since the two are equivalent.
> When you leave out the abstract keyword, compiler
> "adds" the meaning and compiles the concept of
> "abstract interface".
No, it does not. "abstract interface" maps to a particular thing in the .class file. "interface" maps to the same thing. You could just as easily say the compiler subtracts the concept of "abstract" when it's there, and it would be as valid.
The fact that all interfaces are abstract does not mean that the compiler "adds the concept of abstract." That just doesn't apply at that level. If it adds the concept of abstract, it also adds the concept of "Java" since Java-ness is also part of these interfaces.
> public abstract interface top {}
>
> public interface top {}
>
> These are the same thing.
Yes, we've been saying that all along.
Which brings us back to the original point: Adding the word "abstract" in the source for an interface is redundant.
jverda at 2007-7-19 23:00:33 >
> x++; a part of this expression means to increment the
> value of x by 1
No. The entirety of this expression is to increment a variable by 1.
> x=x+1; a part of this expression means to increment
> the value of x by 1
True. This expression is decomposed into two sub-expressions: the first has a result of adding two values (note that x is not changed). The second sub-expression assigns the result of the first to variable x.
> These are two ways of saying the same thing. Maybe
> 'ambiguous' is the wrong term, but my point is that
> the computer only has one instruction that will
> increment the value of x by 1.
And, as I demonstrated in post #50, the compiler (1.4.2) generates two distinct bytecode sequences for these two expressions.
> The role of the compiler is to read and interpret
> these commands and translate them to the one
> instruction that the computer will understand.
No. The role of the compiler is to recognize patterns in the source text, and generate appropriate bytecode sequences for those patterns.
> The Java import statement allows you to introduce the
> fully-qualified name of a class with one statement.
OK. To properly state this, it makes an entry in the compiler's symbol table.
> The compiler adds the full class name for you.
Actually, no, because it has no need to do that. The compiler translates its symbol table pretty much directly into the constant pool of a .class file. It keeps track of which constants apply to which symbols. When it sees a non-qualified classname in the source file, it goes to the symbol table to determine if there's an entry for that classname, and if there is, it writes the reference to the constant into the bytecode. It does not convert the source code in any way.
I'm sorry but "abstract interface" is a concept you made up. It's not a concept in the JLS, there's only "interface". An interface is inherently abstract (i.e. you cannot instantiate it) so to say "abstract interface" is redundant as has been pointed out to you before. The JLS even explicitly discourages the use of the syntactical construct "abstract interface" to describe the concept "interface". What more do you want?
> The compiler adds the full class name for you.
Adds the name or looks up name in symbol table and then adds name...mmmm sounds like the same thing
> When it sees a non-qualified classname in the source
> file, it goes to the symbol table to determine if
> there's an entry for that classname, and if there is,
> it writes the reference to the constant into
> the bytecode.
Thank you Jesus!!. Can you say "the compiler looks at the symbol table and "writes" the reference to the constant in the bytecode" again?
How many times have I stated that no one cares about changing the source code?
> I'm sorry but "abstract interface" is a concept you
> made up. It's not a concept in the JLS,
If 'abstract interface' is something I made up, how come compiler does not report error when I have it in my source code?
You cannot instantiate an interface because it is abstract.
> > it writes the reference to the constant into
> > the bytecode.
>
> Thank you Jesus!!. Can you say "the compiler looks at
> the symbol table and "writes" the reference to the
> constant in the bytecode" again?
>
> How many times have I stated that no one cares about
> changing the source code?
I dunno. I just see things like this, from post #63:
"This does not mean that the full, qualified class name is not required wherever the class name is specified. The compiler adds the full class name for you. "
So let's see if I get this straight: when you say "adds the full class name," you don't really main "adds", but actually mean "somehow inserts a reference to."
> How many times have I stated that no one cares about
> changing the source code?
Then what did you mean by this: In source code you put:
count++;
When compiler reads this, it writes
count=count+1;
And then compiles a class file.
I've pointed out how statements like that and "the compiler adds 'abstract'" sound like you're talking about the source code and asked for clarification about what you meant if it wasn't that.
You finally sort of answered the abstract part by saying that it puts a single flag in there that means "abstract interface," but that's not really consistent with the following comments that you made that certainly seemed to be talking about source code, in particular when coupled with the bit about changing x++ to x=x+1:
Either the compiler puts 'abstract' or developer puts 'abstract', no difference.
The compiler looks for the keyword and adds it if it is not there
When it is not in the declaration, the compiler puts one in for you. When it is there, the compiler sees it and does not put it there.
The compiler will add things to make little shortcuts for the developer. The addition of the 'abstract' keyword is only one of many such niceties.
jverda at 2007-7-19 23:00:38 >
> If 'abstract interface' is something I made up, how> come compiler does not report error when I have it in> my source code?You didn't make it up but the language designers now consider allowing the abastract modifier on interfaces to be a mistake.
>So let's see if I get this straight: when you say "adds the full class name," you don't really main "adds", but actually mean "somehow inserts a reference to."
To me "somehow inserts" and "adds" mean the same thing. And as you stated in your post, the compiler "adds" "something" to the source code "prior" to creating a class file. Or, during the creation of a class file. Th
