Super() constructor must be first. Is it right?
My previous discussion abot the this issue has been removed. I must reconstruct it to be aware of advantages, disadvantages and bypasses over the restriction.
Obvously, the restriction prevents us from writing some perfectly valid code:
class Unsigned7BitOscillatorInputStreamextends OscillatorInputStream{
Unsigned7BitOscillatorInputStream(
PeriodicSignal signal,
float amplitude,
float signalFrequency,
AudioFormat f,
long framesLength)
{
// call super substituting the audio format
super(
signal,
amplitude,
signalFrequency,
new AudioFormat(AudioFormat.Encoding.PCM_UNSIGNED,
f.getSampleRate(),
8, f.getChannels(),
f.getFrameSize(),
f.getFrameRate(),
false
),
framesLength);
}
It is the same if one writes
class Unsigned7BitOscillatorInputStreamextends OscillatorInputStream{
Unsigned7BitOscillatorInputStream(
PeriodicSignal signal,
float amplitude,
float signalFrequency,
AudioFormat f,
long framesLength)
{
// create audio format for super class, overriding bps
AudioFormat format =new AudioFormat(
AudioFormat.Encoding.PCM_UNSIGNED,
f.getSampleRate(),
8,
f.getChannels(),
f.getFrameSize(),
f.getFrameRate(),
false);
super(signal, amplitude, signalFrequency, format, framesLength);
}
Fortunately, the new AudioFormat obect can be created inline with super call. Nevertheless, actually, anyway, the instantiation of the local object preceeds the super call. So what was the reason to prevent java programmers from writing strightforward code, make them decieving themselves and looking for ugly bypasses? What if some comuptation must be done and some fields initialized before super can be called? What if I want to log the arguments passed before calling the super constructor? I wonder how java designers know in which order the fields must be initialized/accessed. IMO, it is exactly constructor's competence.
[2864 byte] By [
valjoka] at [2007-10-2 18:50:05]
The compiler will tell you that the call to super must be first. If you do it any other way you'll get a compilation error.%
> My previous discussion abot the this issue has been
> removed. I must reconstruct it to be aware of
> advantages, disadvantages and bypasses over the
> restriction.
>
> Obvously, the restriction prevents us from writing
> some perfectly valid code:
That isn't really the point though.
The point of a constructor is to put the object into a valid state.
It is not logical to have a child in a valid state if the parent is not in a valid state. Although one can code that way it It is quite possible to make mistakes in constructing a child because one forgets that the parent is not yet in a valid state.
And those sorts of mistakes are most likely to happen in the very place where, like your code example, the parent/child construction is complex.
So java doesn't allow it.
> It is the same if one writes
>
> > class Unsigned7BitOscillatorInputStream extends
> OscillatorInputStream {
>
> Unsigned7BitOscillatorInputStream(
> PeriodicSignal signal,
> float amplitude,
> float signalFrequency,
> AudioFormat f,
> long framesLength)
> {
>
> // create audio format for super class, overriding
> ng bps
> AudioFormat format = new AudioFormat(
> AudioFormat.Encoding.PCM_UNSIGNED,
> f.getSampleRate(),
> 8,
> f.getChannels(),
> f.getFrameSize(),
> f.getFrameRate(),
> false);
>
> super(signal, amplitude, signalFrequency, format,
> t, framesLength);
>
> }
>
>
>
> Fortunately, the new AudioFormat obect can be created
> inline with super call. Nevertheless, actually,
> anyway, the instantiation of the local object
> preceeds the super call. So what was the reason to
> prevent java programmers from writing strightforward
> code, make them decieving themselves and looking for
> ugly bypasses? What if some comuptation must be done
> and some fields initialized before super can be
> called? What if I want to log the arguments passed
> before calling the super constructor? I wonder how
> java designers know in which order the fields must be
> initialized/accessed. IMO, it is exactly
> constructor's competence.
> really?Really.If you haven't tried it already (and your question suggests that you have and didn't like the result you got), do a small test case and see.Joe's explanation is spot on.%
> That isn't really the point though.
>
> The point of a constructor is to put the object into
> a valid state.
>
> It is not logical to have a child in a valid state if
> the parent is not in a valid state. Although one can
> code that way it It is quite possible to make
> mistakes in constructing a child because one forgets
> that the parent is not yet in a valid state.
>
> And those sorts of mistakes are most likely to happen
> in the very place where, like your code example, the
> parent/child construction is complex.
>
> So java doesn't allow it.
The best way not to get a virus from internet is to disconnect from it completely. The best way to prevent making any mistakes is not doing anything. Is this the point? The pitiful attempt to impose this restriction looks as one from this number. However, it differs in that it does not work. I have give one of the examples how to bypass it. The feature does not protect me from anything other than adds a level of complexity into java synthax (hence, compiler and programs). Do you know how the people doing useless and occasionally harmful things are called?
This is a programmer who writes a constructor and the object constructioin order is therefore his choice. I can point you to programming papers telling the 'goto' is evil. Can you give me similar which are telling that deferred super() is a bad practice allowed only in some imperfect languages? It is curious to know the inventor of this feature and how do they argument putting this spoke in the wheel, from the OOP point of view?
Show me why I cannot construct a human without first producing an ape? Or construct a tree without first producing a plant? Think yourself, aren't these requirements sound absurd? The plant appears altogether with a tree. Talking in a scientigic language, being a plant is nothing more than an attribute of a tree (which cannot appear ahead of the object). They appear simultaneously and are indistinguishble as a single whole.
> The best way not to get a virus from internet is to
> disconnect from it completely. The best way to
> prevent making any mistakes is not doing anything. Is
> this the point? The pitiful attempt to impose this
> restriction looks as one from this number. However,
> it differs in that it does not work. I have give one
> of the examples how to bypass it. The feature does
> not protect me from anything other than adds a level
> of complexity into java synthax (hence, compiler and
> programs). Do you know how the people doing useless
> and occasionally harmful things are called?
>
> This is a programmer who writes a constructor and the
> object constructioin order is therefore his choice. I
> can point you to programming papers telling the
> 'goto' is evil. Can you give me similar which are
> telling that deferred super() is a bad practice
> allowed only in some imperfect languages? It is
> curious to know the inventor of this feature and how
> do they argument putting this spoke in the wheel,
> from the OOP point of view?
Maybe you need to take this up with James Gosling or go write in another language. The point is that this is the way Java is designed and has been operating for over ten years. I don't think it's going to change now.
> Show me why I cannot construct a human without first
> producing an ape?
No, but you can't produce a child unless its parents are in a valid state (e.g., fully operational.)
> Or construct a tree without first producing a plant?
Really? You can create a tree without a seedling or a nut? You can create a tree whole? There are some folks who might want to talk to you.
> Think yourself, aren't these
> requirements sound absurd?
No, only your argument is absurd IMO. The analogy between biology and computer science in this case is hardly 1:1.
> The plant appears
> altogether with a tree. Talking in a scientigic
> language, being a plant is nothing more than an
> attribute of a tree (which cannot appear ahead of the
> object).
Scientific language? I don't think that biologists think of being a plant as an attribute of a tree.Is being a child an attribute of an adult? Some psychologists might say so, but it feels more like a state than an attribute.
> They appear simultaneously and are
> indistinguishble as a single whole.
Sounds like you need another language. Javascript or Ruby might be more to your liking.
%
> > Show me why I cannot construct a human without
> first
> > producing an ape?
>
> No, but you can't produce a child unless its parents
> are in a valid state (e.g., fully operational.)
Looks like a demagogic sentence. Let's think of a human as a brain-increased ape without tail. Do you mean the constructor creates an ape first and then he adds some brain and cuts the tail? What does it mean the "parents must be operational"? Constructor does not create any parents, it creates a child. You have the parents. When they decided to create you, did they start by creating your parent (isn't it absurd again?) or proceeded directly?
> > Or construct a tree without first producing a
> plant?
>
> Really? You can create a tree without a seedling or
> a nut? You can create a tree whole? There are some
> folks who might want to talk to you.
No, but I can make a soudspeaker without bringing its "parent" (presumably, a soundsystem) into "a valid state". I can write a java program without bringing some "abstract" program into a valid state.
> No, only your argument is absurd IMO. The analogy
> between biology and computer science in this case is
> hardly 1:1.
OK, which chapter of CS tells that "parents" must be created prior to a "children"? Should Intel start manufacturning their Pentium chips by producing 8088 core first? What do you mean telling "parent in valid state"? In construction, only ONE object is produced, which complies to its ancestor interface. Constructors just aid the process. May be you wanted to tell there is no analogy between OOP and the nature?
> Scientific language? I don't think that biologists
> think of being a plant as an attribute of a tree.
You do not attribute a tree to plants? How many classes of education you have?
> Is being a child an attribute of an adult?
Is being a liquid an attribute of being solid? Seed is not the same as tree. I do not understand this analogy.
> > They appear simultaneously and are
> > indistinguishble as a single whole.
>
> Sounds like you need another language. Javascript or
> Ruby might be more to your liking.
I wonder how people defend the unnatural states of affairs.
> No, but I can make a soudspeaker without bringing its "parent" (presumably, a soundsystem) into "a valid state".
In this case you seem to be confusing your type hierarchy with your component hierarchy.
> So what was the reason to prevent java programmers from writing strightforward code, make them decieving themselves and looking for ugly bypasses?
Can you actually give an example of OO code where you are having a problem with this? If the only difference between Unsigned7BitOscillatorInputStream and OscillatorInputStream is in the restriction of somes parameters of its AudioFormat, then it probably doesn't want to be a subclass anyway, and you're better off with a builder method. I'd also use a builder for cloning the AudioFormat as the whole bag-of-data thing is way ugly.
Pete
> Looks like a demagogic sentence. Let's think of a
> human as a brain-increased ape without tail. Do you
> mean the constructor creates an ape first and then he
> adds some brain and cuts the tail? What does it mean
> the "parents must be operational"? Constructor does
> not create any parents, it creates a child. You have
> the parents. When they decided to create you, did
> they start by creating your parent (isn't it absurd
> again?) or proceeded directly?
The statement that I made has to do with software only. I consider it to be an object-oriented best practice. I don't want to have to worry about whether or not the internal state of the object that I'm using is fully functional.
The part that I disagree with your argument is extending statements about software into biology. I don't think the analogy fits, no matter how you torture and twist it around. I'm talking about software when I say that.
> No, but I can make a soudspeaker without bringing its
> "parent" (presumably, a soundsystem) into "a valid
> state". I can write a java program without bringing
> some "abstract" program into a valid state.
There's no parent relationship like that between a speaker and sound system that I know of. Of course they're independent. That's where your argument doesn't apply. It's certainly possible to create speakers on their own. The object-oriented software model that requires the parent first works for Java, but it's not intended to apply to the entire world. Models are like that - they only include the features of interest.
> OK, which chapter of CS tells that "parents" must be
> created prior to a "children"? Should Intel start
> manufacturning their Pentium chips by producing 8088
> core first? What do you mean telling "parent in valid
> state"? In construction, only ONE object is produced,
> which complies to its ancestor interface.
> Constructors just aid the process. May be you wanted
> to tell there is no analogy between OOP and the
> nature?
It's a model. The real world is non-linear, yet scientists use linear models to describe it all the time, because the simplification is useful. But nobody who does so would say that they are the real world.
The software model that lives in your machine is an approximation to the real world. The analogy is what you make it. The folks who designed Java did not model inheritance on biological systems.
> You do not attribute a tree to plants? How many
> classes of education you have?
I'm pretty confident that I've got more than you do. There aren't many people who have gone to school longer than I have.
> Is being a liquid an attribute of being solid? Seed
> is not the same as tree. I do not understand this
> analogy.
Actually it's possible to turn any solid into a liquid or a gas, under suitable conditions. Would you say that the a solid's potential for liquidity is an attribute of that material? Some material scientists might say it is.
> Sounds like you need another language. Javascript
> or Ruby might be more to your liking.
>
> I wonder how people defend the unnatural states of
> affairs.
Nobody's defending anything. If you don't want to write Java, either go get a language that suits you or invent your own. I could care less whether you ever write Java.
I'm just saying that requiring that the super class constructor being called first has never imposed any constraint on the way I thought about a problem or implemented a solution in Java.
You can always write a protected method that initializes your super class and let a sub class call it in whatever order you like. It's a trivial way to get around this problem if it bothers you so much.
%
> The best way not to get a virus from internet is to
> disconnect from it completely. The best way to
> prevent making any mistakes is not doing anything. Is
> this the point? The pitiful attempt to impose this
> restriction looks as one from this number. However,
> it differs in that it does not work. I have give one
> of the examples how to bypass it. The feature does
> not protect me from anything other than adds a level
> of complexity into java synthax (hence, compiler and
> programs). Do you know how the people doing useless
> and occasionally harmful things are called?
>
If you want to do everything then I would suggest that you use C++ or even assembler.
Java was specifically constructed with limitations in mind based on experience with common problem areas. Notice that I said "specifically".
> This is a programmer who writes a constructor and the
> object constructioin order is therefore his choice. I
> can point you to programming papers telling the
> 'goto' is evil. Can you give me similar which are
> telling that deferred super() is a bad practice
> allowed only in some imperfect languages? It is
> curious to know the inventor of this feature and how
> do they argument putting this spoke in the wheel,
> from the OOP point of view?
>
I think you can find more than a couple of C++ best practices books and articles that will tell you how C++ constructors should be built.
> Show me why I cannot construct a human without first
> producing an ape?
False analogy. I doubt that anyone would ever construct an inheritence hierarchy like that.
> Or construct a tree without first
> producing a plant?
And that would be logically inconsistent. A tree is a plant. If plant does not exist then a tree can not either.
> Think yourself, aren't these
> requirements sound absurd?
Your analogies are a bit absurd. There are other more relevent ones though...
Employee (parent) -> surpervisor (child).
Based on your argument it is stupid to have a supervisor who is an employee. Whereas in the world I live in the vast majority of the time supervisors are employees. And in the cases where they aren't (rare contractual situations) then building a hierarchy that reflects that relationship is a design flaw which has nothing to do with construction.
> The plant appears
> altogether with a tree. Talking in a scientigic
> language, being a plant is nothing more than an
> attribute of a tree (which cannot appear ahead of the
> object). They appear simultaneously and are
> indistinguishble as a single whole.
You said it not me. If you are using attributes and nothing else to construct inheritence then your design is flawed.
> >
> > No, but you can't produce a child unless its parents
> > are in a valid state (e.g., fully operational.)
>
> Looks like a demagogic sentence. Let's think of a
> human as a brain-increased ape without tail. Do you
> mean the constructor creates an ape first and then he
> adds some brain and cuts the tail? What does it mean
> the "parents must be operational"? Constructor does
> not create any parents, it creates a child. You have
> the parents. When they decided to create you, did
> they start by creating your parent (isn't it absurd
> again?) or proceeded directly?
>
Again you are using a very bad example for inheritence.
>
> > > Or construct a tree without first producing a
> > plant?
> >
> > Really? You can create a tree without a seedling or
> > a nut? You can create a tree whole? There are some
> > folks who might want to talk to you.
>
> No, but I can make a soudspeaker without bringing its
> "parent" (presumably, a soundsystem) into "a valid
> state". I can write a java program without bringing
> some "abstract" program into a valid state.
>
Even worse example. A "sound system" is a collection of other objects.
There is no way that a speaker is ever a child or a parent of an amplifier.
>
>
> > No, only your argument is absurd IMO. The analogy
> > between biology and computer science in this case is
> > hardly 1:1.
>
> OK, which chapter of CS tells that "parents" must be
> created prior to a "children"? Should Intel start
> manufacturning their Pentium chips by producing 8088
> core first?
I am beginning to think that you have a substantially different view than most people about what inheritence means.
I find it hard to believe that anyone, in any situation, would ever attempt to create an inheritence tree using 8080 as the parent and a pentium as the child. This is a historical relationship not a child parent one.
> What do you mean telling "parent in valid
> state"? In construction, only ONE object is produced,
> which complies to its ancestor interface.
> Constructors just aid the process. May be you wanted
> to tell there is no analogy between OOP and the
> nature?
A tree is a plant. It is nonsense to suggest that a tree can exist before plant exists.
That has nothing to do with the relationship between an acorn and an oak however. Nor does the fact that an oak produces acorns mean that there is a child parent relationship in terms of OO in there.
> Java was specifically constructed with limitations in
> mind based on experience with common problem areas.
> Notice that I said "specifically".
Does it mean they all the OOP practices are the best? Should I use them as a reference? Which kind of errors does it protect me from? I would like to see a document telling that calling super constructor is evil, really. Peahaps the reasons lie not in best OOP practice but rather some technical/historical sad fact. It would be amusing if you are defending somenes mistake. I'm sure is java did not initially had the real type (float point) for the reason of its support complexity, the java bigots today would prove that the real numbers are evil and the requirement to use this type in your program points to a flaw in your design. The paramount evidence on the best programming practices will, of course, be the JLS bible. Like they prove there must not be a Set.get(key) in the set class/interface. They tell me that there must be none need to request an object of the same class ("class" in math terms) equivalent to that one you have put into the set. They tell me that if I need the method, my design is flawed. However, actually, the lack of the method in java.collections is nothing more than their designer's mistake. The most obvious illustration are relational tables in DB: the keys are parts (fields, members) of records (entities, objects) while tables are nothing more than sets of objects. Using maps in this case is inappropriate and inferes redundancy. But that's another story... Though the superfirst requirement also adds the extra complexity and must be thoroghly justified. Any artifical overcomlication/redundancy must have a solid evidence. IMO, the objected limitation looks like a 5th wheel in a java-telega.
I have programmed with gotos many years ago. My experiance proves the Dykstra's (one of the structural programming fathers) thesis stating the "gotos are evil". The gotos break the flow of control making it hard to follow. Therefore, I readitly accept it. I have never seen the thesis, but I'm sure I can find and refer it to you if you like. At the same time, I'm sure there is nothing similiar in OOP domain telling the "deferred" supercons are evil. Otherwise, you would be more specific in references. Suppose, someone confines you into a prison, argumenting this is a "specific tool/limitation" to prevent "some" problems. Will you agree? You will insist on some more serious criminations? Be happy - they tell you - you are allowed to argument against the confinement appealing to our community (the community are the people believing the authority blindly)! No, it is accepted in justice that any limitation of freedom must be justified, not the contrary! This is called a presumption of innocence. I suffer, I break my mind when I know that the following invocations are the same but the second does not work for some ***** reason:
B() {
super(computePrereq());
}
B() {
r = computePrereq(); // why this is worse than above? Where is the justice?
super(r);
}
> I think you can find more than a couple of C++
> best practices books and articles that will tell
> you how C++ constructors should be built.
Wow, you refer me to C++ as a citadel for OOP best practices! OK. CPP::STL "package" has the get_by_key method in the Set class/template. Will this fact chagne the mind of java bigots? Obviously not, they immediately refuse your arguments just hearing c++. I can, but just please be more specific. I may to carefully explore a ton of books without finding any sign of super second is evil.
My favorite lang on Wintel platform is Delphi. Many thoughtful people consider it as a Wintel native java. However, there is even no recommendation to use superconstructors first. And the broad experience suggests me that there is nothing harmful in deferring the superconstruction. I do not feel any nasty frustration similar to exploiting gotos. The super destructors must be called last indeed, since they ultimately call the root superclass's (TObject) destructor, which deallocs the mem and the object ceases to exist after the call. But constructors do not alloc any mem for the object fields, they just fill the fields. The order of initialization is absolutely free. The initialization of all the fields may even be made in parallel for performance.
Delphi also has a interface-resolution mechanism. Two interfaces conflict when they specify two aliasing methods. Will you tell that it is a bad design if happens that two interfaces conflict? The Divide&Concure disign rule tells the contrary, it is bad design when you must care about other blocks developing one. It is java which has design flaw - you must care about names of methods in other interfaces. This is the experiance collected from wast SW/HW methodologies I can share with java community.
> Show me why I cannot construct a human without
> first
> producing an ape?
>
> False analogy. I doubt that anyone would ever
> construct an inheritence hierarchy like that.
I do not belive in God either ;)
The evolution took itself.
> > Or construct a tree without first
> > producing a plant?
>
> And that would be logically inconsistent. A tree is
> a plant. If plant does not exist then a tree can not
> either.
OK. Which plant should I create before proceeding to construct a tree? Do you understand that the Plant and Tree are the classes while an instance of the Tree just belongs to these classes? The calsses are loaded prior to construction. Now, I'm creating a tree. It is not your matter how the tree is created. You just get a tree and if it is a valid tree; that is, your tree implements all methods of the interface the tree class commits to implement, then it is also a plant. The construction technology is not important. The constructor knows it better when to create a steam and leafs.
> Your analogies are a bit absurd. There are other
> more relevent ones though...
>
> Employee (parent) -> surpervisor (child).
>
> Based on your argument it is stupid to have a
> supervisor who is an employee. Whereas in the world
> I live in the vast majority of the time supervisors
> are employees. And in the cases where they aren't
> (rare contractual situations) then building a
> hierarchy that reflects that relationship is a design
> flaw which has nothing to do with construction.
Where did I argument against this relatioship? Nevertheless, if it bothers you I can tell you my opinion. In the manager-workers pattern, the emploee (also called a manager) is a job, whos duty consists of finding the workers, hand out a job to them and accepting (supervising) the work done. It may also stimulate/motivate the workers, but that is not important. What's more important is that the surpervision is one of manager's duties. Any Manager is a supervisor by definition. Thus, I can explain why Ape and Human are two different classes in the ancestor-descendant relationship, but I cannot explain you manager-supervisor subclassing... I would establish an Employee class implementing its duty interfaces listed. At least, since multiinheritance is not supported in java and you'll have a problem deriving the Emploee from both task initiator and inspector. If you like.
> > The plant appears
> > altogether with a tree. Talking in a scientigic
> > language, being a plant is nothing more than an
> > attribute of a tree (which cannot appear
> ahead of the
> > object). They appear simultaneously and are
> > indistinguishble as a single whole.
>
> You said it not me. If you are using attributes and
> nothing else to construct inheritence then your
> design is flawed.
Excuse me for not understanding/appretiating your humor. The "Tree" objects are attributed to "Plants" class. Don't you agree of what?
To put it bluntly, this is you who seem to use inappropriete terminology. In programming, the parent-children relationship is used for tree structures (has-a). Parent may have (or own) a set of children. However, no parent construction precedes the construction of every "child" object. Otherwise, we would get too many parents. While we need descedants. The descedants have attributes of parents but they are not separate objects. Like keyfields in a DB records. All the fields are equal (if we do not toudch the pragmatic level). The ancestor-descendant terminology is adoped in OOP (the talks about inheritance). In java, super/sub-class notation is accustomed. This sharpens my confusion on which "parents" should I create before initializing any new object specific fields.
> > Looks like a demagogic sentence. Let's think of a
> > human as a brain-increased ape without tail. Do
> > ....
> > again?) or proceeded directly?
> >
>
> Again you are using a very bad example for
> inheritence.
I fail to see why the natural exapmles of inheritance are somehow "bad". OK, not all apes are brain-low, since humen break this rule.
> > No, but I can make a soudspeaker without bringing
> its
> > "parent" (presumably, a soundsystem) into "a valid
> > state". I can write a java program without
> bringing
> > some "abstract" program into a valid state.
> >
>
> Even worse example. A "sound system" is a
> collection of other objects.
> There is no way that a speaker is ever a child or a
> parent of an amplifier.
Thereofore, an abstract soundsystem may not have any concrete descendants? A soundsystem consumes a stream of databits or continous electric signal and produces sound waves. A laudspeaker near to me is full of controls - volume, bass, ets.. What is it if not an incarnation of a sound system?
OK, here is another example. A floppy-disk is a disk. Should one produce a disk before making it floppy? Or microwave owen is an owen. How do you think should I create an owen prior to making it a microwave? Or electric field, how do I create a field prior to adding the electric parameters? Or how do I construct a hammer if you require me to precede its construction by construction of abstract instrument? How do I manufacturers produce "parent" computers before attaching "personal" properties to it? I'm sure there are millions of ways to construct a PC but none of them requires producing some "parent".
> > OK, which chapter of CS tells that "parents" must
> be
> > created prior to a "children"? Should Intel start
> > manufacturning their Pentium chips by producing
> 8088
> > core first?
>
> I am beginning to think that you have a substantially
> different view than most people about what
> inheritence means.
>
> I find it hard to believe that anyone, in any
> situation, would ever attempt to create an
> inheritence tree using 8080 as the parent and a
> pentium as the child. This is a historical
> relationship not a child parent one.
The Pentioum extends functionality of 8088 (both HW and SW). Engeneers started more and more features at the core. Finally they got a huge monster. It still starts as 8088. A program can call for extended capabilities if it knows about them. The old programs work on Pentium using its 8088 inherited interface.
> > What do you mean telling "parent in valid
> > state"? In construction, only ONE object is
> produced,
> > which complies to its ancestor interface.
> > Constructors just aid the process. May be you
> wanted
> > to tell there is no analogy between OOP and the
> > nature?
>
> A tree is a plant. It is nonsense to suggest that a
> tree can exist before plant exists.
As I have told, I have never suggested for such a nonsense. The Plant class exits long before you create an instance of a tree.
> That has nothing to do with the relationship between
> an acorn and an oak however. Nor does the fact that
> an oak produces acorns mean that there is a child
> parent relationship in terms of OO in there.
I have never told that the seeds are plants. Moreover, I do not see any relation here with your proir argument that the creation of instance of an oak must be preceeded by the creation of instantance of some abstract plant (belonging to a Plant class) and the tree instance constructor then must decorate the the basic structure of that plant instance.
Please refer me to a book telling that fields of superclass must be initialized prior to (not after and not concurrently) with the new fields exposed by a subclass.
> > Java was specifically constructed with limitations
> in
> > mind based on experience with common problem
> areas.
> > Notice that I said "specifically".
>
> Does it mean they all the OOP practices are the best?
No. It means the people who created the language made certain decisions for certain reasons. Many of those decisions and their reasons are tradeoffs between power and simplicity. You can whine all you want about whether it's "right," but it's rather pointless to do so. This is how Java is. It will not change. Either work with it (and I have never run across a case of good code where this issue was a problem), or find a different language.
jverda at 2007-7-13 20:12:56 >
> Obvously, the restriction prevents us from writing> some perfectly valid code:No, it is not perfectly valid. By definition, this code is invalid. If you feel you need to write code like that, find a different language.
jverda at 2007-7-13 20:12:56 >
> somenes mistake. I'm sure is java did not initially
> had the real type (float point) for the reason of its
> support complexity, the java bigots today would prove
> that the real numbers are evil and the requirement to
Ah, yes, the oh so predictable part where valjok starts calling everybody who disagrees with him "java bigots," because he can't handle the fact that the world doesn't work the way he wants, and because he can't conceive of the fact that somebody might know more than him.
Go away, valjok. You're a waste of bits.
jverda at 2007-7-20 23:53:15 >
I still want to know something.
Given:AudioFormat f = new AudioFormat(
AudioFormat.Encoding.PCM_UNSIGNED, 44000, 8, 1, 42, 50, false);
OscillatorInputStream object1 = new OscillatorInputStream(signal,
amplitude, signalFrequency, f, framesLength);
OscillatorInputStream object2 = new Unsigned7BitOscillatorInputStream(signal,
amplitude, signalFrequency, f, framesLength);
How is the behaviour of object2 differentiated from object1?
Irrespective of language pissing matches - they each have a balance between safety, efficiency, expressiveness and productivity - in OO software inheritence is the means of differentiating behaviour. So how is the subclass differentiating behaviour here?
Pete
> Nobody's defending anything. If you don't want to
> write Java, either go get a language that suits you
> or invent your own. I could care less whether you
> ever write Java.
Should SUN cease their RFE practice? Quite the contrary, commiting RFEs suggests that the java designers understand their product is not perfect; therefore, they accept enchancements on some aspects of their lang and java is subject of changes. I wonder why some java users afford the "you don't like the java as it is? - Go use another language!" politics toward others. It won't change. Why do you bother?
> The statement that I made has to do with software
> only. I consider it to be an object-oriented best
> practice. I don't want to have to worry about whether
> or not the internal state of the object that I'm
> using is fully functional.
You are missing something. Constructors do not use the objects. They create new ones.
>> ... May be you wanted
>> to tell there is no analogy between OOP and the
>> nature?
> It's a model. The real world is non-linear, yet
> scientists use linear models to describe it all the
> time, because the simplification is useful. But nobody
> who does so would say that they are the real world.
I beleive there is a corrspondence between scientific models and the reality. I beleive the engeneers draw their inspiration from the nature (mostly from biology). I beleive, the OOP inventors are scientists. I beleive, the idea of OOP itself were derived from biological evolution. Though it may differ, you cannot forbid me bringing parallels between the natural evolution and "evolution" of programmable object. Finally, some java bigots attacked me half of that deleted topic bringing increasingly stupid examples of how the super constructors are called first in the nature and suggesting this ravings as a reason we have it in java. Glad to see that that their position is wrong and this is the superconstructor which is unnatural.
> I'm just saying that requiring that the super class
> constructor being called first has never imposed any
> constraint on the way I thought about a problem or
> implemented a solution in Java.
The fact that you had never need to use any group theory, equations of quantum mechanincs or java audio in you daily life does not mean that they point to someone's design flaws and must be forbidden.
> You can always write a protected method that initializes
> your super class and let a sub class call it
Yes, I may always have a way around and I have more options when the superclass is under my control and can be reimplementd. But I want everybody to know that the perfect way is the most direct/strightforward one.
> If you want to do everything then I would suggest that
> you use C++ or even assembler.
I vote for reduced complexity. Any complexity must be thoroghly justified. Any redundant artifical complexity must be eliminated. Not the contrary.
> No, it is not perfectly valid. By definition, this code is
> invalid. If you feel you need to write code like that, find a
> different language.
Who told that? By which definition? Do you refer me to your JLS bible? It is not the final authority discussing the rationality of its rules.
>> Does it mean they all the OOP practices are the best?
> No. It means the people who created the language made certain
> decisions for certain reasons. Many of those decisions and their
> reasons are tradeoffs between power and simplicity. You can
> whine all you want about whether it's "right," but it's rather
> pointless to do so. This is how Java is. It will not change.
> Either work with it (and I have never run across a case of good
> code where this issue was a problem), or find a different language.
The same people made other decisions for certain reasons. They prohibited covariance of results, overlooked interface method aliasing conflicts, get(key) method in the Set interface. All these are design flaws and/or simplifications. Despite it is was obvious for me when I first encountered the covarianve hindrance that the barrier to return a subtype is a purely unjustified redundancy (complexity, the evil), it took 10 years to repair the covariance flaw. I'm sure the java bigots invented a lot of laughable arguments defending the state of affairs.
I'm at least glad to your for the confession that the reason of superfirst lies not in the ***** requirement to initialize some "parent" prior to the "child" but rather in some "simplicity". IMO, it is obvious that the simpicity is of covariance and interface aliacing trouble kind - it may simplify writing the compiler. Meantime, this simlicity turns into troubles for thoughtful prorgammers who guided by the logic and best engeneering practices will hit into these artificial barriers.
> How is the behaviour of object2 differentiated from object1?
Obviously, it overrides something. One method. I know, I could employ filters working with streams. However, streams filters work processing the entire stream; that is, the source produces some data which is inspected and transformed into a new stream. Meanwhile, the OOP allows to influence the generation process itself allowing for single pass gen. There are two strategies in OOP: whether to override the algotithm-implementing method in a subclass or to pass an Algorithm object to the wrapper class. The both are absolutely legitimate.
However, I appeal to inconsistency in the language. Please take a java tutorial and see how parameters are evaluated. Please make sure that they are evaluated before the function call. And then verify this rule applying it to the statements in a constructor. Note that the basic control flow given is false and something different happends since java constructors violate it - the argument evaluation works in some different way.
Is it what you call a "simplification"? You add some exception to a simple grammar to conflict with other rules and call it a "simplification"? Do you trade off the power for this "simplification"? Why did java community decided to get rid of the covariance "simplification" from the java lang?
> Ah, yes, the oh so predictable part where valjok starts calling
> everybody who disagrees with him "java bigots," because he can'
> t handle the fact that the world doesn't work the way he wants,
> and because he can't conceive of the fact that somebody might
> know more than him.
Only those shallow persons who bring empty arguments (like their bible) when asked why it is as it is. In the topic on using file extensions in java aplications, some one have noticed that my position is sensible, despite of the disgusting presentation/delivery. I'm sure that thoughtful people will agree with my point. I don't invite you at this topic. If you have nothing to tell regarding the substance - please, don't do.
> You are missing something. Constructors do not use the objects. They create new ones.That's not correct. Constructors are called as part of the instance creation process; they don't create them, per se - that's done by the new instruction.~
> > No, it is not perfectly valid. By definition, this
> code is
> > invalid. If you feel you need to write code like
> that, find a
> > different language.
>
> Who told that? By which definition? Do you refer me
> to your JLS bible? It is not the final authority
> discussing the rationality of its rules.
The JLS is the final authority on what is and is not valid Java. By definition.
> >> Does it mean they all the OOP practices are the
> best?
>
> > No. It means the people who created the language
> made certain
> > decisions for certain reasons. Many of those
> decisions and their
> > reasons are tradeoffs between power and simplicity.
> You can
> > whine all you want about whether it's "right," but
> it's rather
> > pointless to do so. This is how Java is. It will
> not change.
> > Either work with it (and I have never run across a
> case of good
> > code where this issue was a problem), or find a
> different language.
>
> The same people made other decisions for certain
> reasons. They prohibited covariance of results,
> overlooked interface method aliasing conflicts,
> get(key) method in the Set interface. All these are
> design flaws and/or simplifications. Despite it is
> was obvious for me when I first encountered the
> covarianve hindrance that the barrier to return a
> subtype is a purely unjustified redundancy
> (complexity, the evil), it took 10 years to repair
> the covariance flaw.
FIne, then submit the RFE. But quit your bloody whining.
> I'm sure the java bigots
> invented a lot of laughable arguments defending the
> state of affairs.
You are an idiot. You call everybody bigot who happens to agree with decisions that were made in Java, rather than agreeing with you. Get over yourself, you whiny child.
> Only those shallow persons who bring empty arguments
> (like their bible) when asked why it is as it is. In
> the topic on using file extensions in java
> aplications, some one have noticed that my position
> is sensible, despite of the disgusting
> presentation/delivery. I'm sure that thoughtful
> people will agree with my point. I don't invite you
> at this topic. If you have nothing to tell regarding
> the substance - please, don't do.
Comments like this show beyond any doubt that you are an irrational person and have no wish for reasonable discussion, that all you want is someone to agree with you.
Let me explain it to you simply: It would be techinically possible for Java's rules to be defined differently, so that one could fiddle with the child class before super's constructor has completed. The creators of the language felt that the benefits provided by this would outweigh the downside. You get almost nothing for it. I've never seen a case where it would be better design or better code to do it that way. The downside is that there is a huge potential for invalid state, hard to find bugs, etc.
The language designers saw large risk and low benefit. I happen to agree with them. So do many others. Despite your ridiculous foot-stamping to the contrary, that does not make us bigots. The language is simpler when you know that certain things will happen in a certain order. Predictability has been added, and very little power removed. This is a good thing.
jverda at 2007-7-20 23:53:15 >
> presentation/delivery. I'm sure that thoughtful
> people will agree with my point. I don't invite you
> at this topic. If you have nothing to tell regarding
> the substance - please, don't do.
Translation: "My way is right because I said so and if you disagree with me you're a big mean doody-head by definition."
The only bigot here is you, valjok.
jverda at 2007-7-20 23:53:15 >
> > You are missing something. Constructors do not
> use the objects. They create new ones.
>
> That's not correct. Constructors are called as part
> of the instance creation process; they don't create
> them, per se - that's done by the new
> instruction.
>
> ~
It's also not correct because as part of the initialization process, the constructor may use the object it's initializing and/or other objects.
One must be very careful with the former, of course, and this is where the predictiability of having super completely initialized before running sub's constructor is useful.
jverda at 2007-7-20 23:53:15 >
> Should SUN cease their RFE practice? Quite the
> contrary, commiting RFEs suggests that the java
> designers understand their product is not perfect;
> therefore, they accept enchancements on some aspects
> of their lang and java is subject of changes. I
> wonder why some java users afford the "you don't like
> the java as it is? - Go use another language!"
> politics toward others. It won't change. Why do you
> bother?
Perhaps it's out of frustration, because rational arguments are wasted on you.
> You are missing something. Constructors do not use
> the objects. They create new ones.
No, you're missing something. I'm talking about clients of my class, not the constructor.
> I beleive there is a corrspondence between scientific
> models and the reality.
Certainly there's a correspondence, but it's not always 1:1. Models include the features of interest and exclude those that are judged to be neglectable.
> I beleive the engeneers draw
> their inspiration from the nature (mostly from
> biology).
I disagree with you there. I spent a long time modeling systems as an engineer, and none of my models ever had anything to do with biology. Physics were more pertinent to me. Don't use the word "mostly". It's not correct.
> I beleive, the OOP inventors are
> scientists. I beleive, the idea of OOP itself were
> derived from biological evolution.
I believe you're wrong.
> Though it may
> differ, you cannot forbid me bringing parallels
> between the natural evolution and "evolution" of
> programmable object.
I can't forbid you, but I can disagree about how pertinent and illustrative they are. In this case I don't believe they shed any light on the problem whatsoever.
> Finally, some java bigots
> attacked me half of that deleted topic bringing
> increasingly stupid examples of how the super
> constructors are called first in the nature and
> suggesting this ravings as a reason we have it in
> java. Glad to see that that their position is wrong
> and this is the superconstructor which is unnatural.
I'll look for that super constructor on the Human Genome web site. Based on your views, I should find a sequence that spells out the code for my super constructor.
Personally, I find that use of super constructor to be quite natural.
> The fact that you had never need to use any group
> theory, equations of quantum mechanincs or java audio
> in you daily life does not mean that they point to
> someone's design flaws and must be forbidden.
How do you know whether or not I use group theory or quantum mechanics? (Hint: You don't.) I have no idea whether you know much about either or if you're one of those people who like to cite the names of complex theories to demonstrate their "superior" intelligence and hope to God that no one asks them a detailed question about them.
If you do know about quantum mechanics, please post a derivation of the Hamiltonian for the hydrogen atom. (Extra credit: Post one for helium.)
> Yes, I may always have a way around and I have more
> options when the superclass is under my control and
> can be reimplementd. But I want everybody to know
> that the perfect way is the most
> direct/strightforward one.
"Perfect" - a tall order.
> Who told that? By which definition? Do you refer me
> to your JLS bible? It is not the final authority
> discussing the rationality of its rules.
It is the final authority on what Java is and isn't. You can argue about how "correct" the rules are, but those are the rules.
> The same people made other decisions for certain
> reasons. They prohibited covariance of results,
> overlooked interface method aliasing conflicts,
> get(key) method in the Set interface. All these are
> design flaws and/or simplifications. Despite it is
> was obvious for me when I first encountered the
> covarianve hindrance that the barrier to return a
> subtype is a purely unjustified redundancy
> (complexity, the evil), it took 10 years to repair
> the covariance flaw. I'm sure the java bigots
> invented a lot of laughable arguments defending the
> state of affairs.
>
> I'm at least glad to your for the confession that the
> reason of superfirst lies not in the *****
> requirement to initialize some "parent" prior to the
> "child" but rather in some "simplicity". IMO, it is
> obvious that the simpicity is of covariance and
> interface aliacing trouble kind - it may simplify
> writing the compiler. Meantime, this simlicity turns
> into troubles for thoughtful prorgammers who guided
> by the logic and best engeneering practices will hit
> into these artificial barriers.
>
>
> > How is the behaviour of object2 differentiated from
> object1?
>
> Obviously, it overrides something. One method. I
> know, I could employ filters working with streams.
> However, streams filters work processing the entire
> stream; that is, the source produces some data which
> is inspected and transformed into a new stream.
> Meanwhile, the OOP allows to influence the generation
> process itself allowing for single pass gen. There
> are two strategies in OOP: whether to override the
> algotithm-implementing method in a subclass or to
> pass an Algorithm object to the wrapper class. The
> both are absolutely legitimate.
>
> However, I appeal to inconsistency in the language.
> Please take a java tutorial and see how parameters
> are evaluated. Please make sure that they are
> evaluated before the function call. And then verify
> this rule applying it to the statements in a
> constructor. Note that the basic control flow given
> is false and something different happends since java
> constructors violate it - the argument evaluation
> works in some different way.
>
> Is it what you call a "simplification"? You add some
> exception to a simple grammar to conflict with other
> rules and call it a "simplification"? Do you trade
> off the power for this "simplification"? Why did java
> community decided to get rid of the covariance
> "simplification" from the java lang?
>
>
>
>
> > Ah, yes, the oh so predictable part where valjok
> starts calling
> > everybody who disagrees with him "java bigots,"
> because he can'
> > t handle the fact that the world doesn't work the
> way he wants,
> > and because he can't conceive of the fact that
> somebody might
> > know more than him.
>
> Only those shallow persons who bring empty arguments
> (like their bible) when asked why it is as it is. In
> the topic on using file extensions in java
> aplications, some one have noticed that my position
> is sensible, despite of the disgusting
> presentation/delivery. I'm sure that thoughtful
> people will agree with my point. I don't invite you
> at this topic. If you have nothing to tell regarding
> the substance - please, don't do.
"Thoughtful people" - they stopped reading your rants days ago.
You don't get to control who comments and who doesn't. If we could do that, would have sent you packing a week ago.
%
>
>
> > The statement that I made has to do with software
> > only. I consider it to be an object-oriented best
> > practice. I don't want to have to worry about whether
> > or not the internal state of the object that I'm
> > using is fully functional.
>
> You are missing something. Constructors do not use
> the objects. They create new ones.
>
A constructor is intended to put an object in a valid state. If it isn't in a valid state then the construction process should not succeed.
By attempting to circumvent the parental construction process you are increasing the possibility that the parent will not be in a valid state.
It is that process, not the use of objects in that process, which matters.
>
> I beleive there is a corrspondence between scientific
> models and the reality. I beleive the engeneers draw
> their inspiration from the nature (mostly from
> biology). I beleive, the OOP inventors are
> scientists. I beleive, the idea of OOP itself were
> derived from biological evolution. Though it may
> differ, you cannot forbid me bringing parallels
> between the natural evolution and "evolution" of
> programmable object. Finally, some java bigots
> attacked me half of that deleted topic bringing
> increasingly stupid examples of how the super
> constructors are called first in the nature and
> suggesting this ravings as a reason we have it in
> java.
Your examples wouldn't reflect any reality in any other OO language either.
> Glad to see that that their position is wrong
> and this is the superconstructor which is unnatural.
You are of course allowed to design your systems any way that you see fit.
I am also free to hope fervently that I will never have to maintain a system where someone decided that a chimp was a parent of a human.
>
> > I'm just saying that requiring that the super class
>
> > constructor being called first has never imposed any
> > constraint on the way I thought about a problem or
>
> > implemented a solution in Java.
>
> The fact that you had never need to use any group
> theory, equations of quantum mechanincs or java audio
> in you daily life does not mean that they point to
> someone's design flaws and must be forbidden.
>
>
None of that has anything to do with inheritance. I have done an exstensive amount of programming in the financial industry but even so I would never claim that credit card should be the child of money nor that it should be the child of plastic.
>
>
> > You can always write a protected method that initializes
> > your super class and let a sub class call it
>
> Yes, I may always have a way around and I have more
> options when the superclass is under my control and
> can be reimplementd. But I want everybody to know
> that the perfect way is the most
> direct/strightforward one.
>
And I want everyone to know that I have never seen any correct design where circumventing the construction process was a good idea.
I have seen flawed designs where that was the case.
I have seen hack solutions where someone circumvent the construction process because they didn't want to refactor.
I haven't seen any solutions but I would suppose that some might exist where the process was circumvented for performance reasons.
>
> > If you want to do everything then I would suggest that
> > you use C++ or even assembler.
>
> I vote for reduced complexity.
Your suggestion would add complexity.
> Any complexity must be
> thoroghly justified. Any redundant artifical
> complexity must be eliminated. Not the contrary.
>
And thus your solution should not be added.
>
> The same people made other decisions for certain
> reasons. They prohibited covariance of results,
> overlooked interface method aliasing conflicts,
> get(key) method in the Set interface. All these are
> design flaws and/or simplifications. Despite it is
> was obvious for me when I first encountered the
> covarianve hindrance that the barrier to return a
> subtype is a purely unjustified redundancy
> (complexity, the evil), it took 10 years to repair
> the covariance flaw. I'm sure the java bigots
> invented a lot of laughable arguments defending the
> state of affairs.
>
I am not aware of any one doing that.
I am aware of people who suggest that an overloaded method should be allowed to return any type. And people discount that as there are situations of that which make runtime processing impossible.
Not to mention that C++ added that rather late and java was based on that. So it is quite possible that the idea did not exist for the initial java developers.
> I'm at least glad to your for the confession that the
> reason of superfirst lies not in the *****
> requirement to initialize some "parent" prior to the
> "child" but rather in some "simplicity". IMO, it is
> obvious that the simpicity is of covariance and
> interface aliacing trouble kind - it may simplify
> writing the compiler. Meantime, this simlicity turns
> into troubles for thoughtful prorgammers who guided
> by the logic and best engeneering practices will hit
> into these artificial barriers.
>
As I said, numerous books and articles in C++ suggest that construction of the parent should be complete before the child starts. That would be a best practice then.
>
> Only those shallow persons who bring empty arguments
> (like their bible) when asked why it is as it is. In
> the topic on using file extensions in java
> aplications, some one have noticed that my position
> is sensible, despite of the disgusting
> presentation/delivery. I'm sure that thoughtful
> people will agree with my point. I don't invite you
> at this topic. If you have nothing to tell regarding
> the substance - please, don't do.
"Java bigot" is a term intended solely to denigrate and it provides no substance to the discussion. And thus your post would be the first post that strayed from the discussion.
> Translation: "My way is right because I said
> so and if you disagree with me you're a big >
> mean doody-head by definition."
> The only bigot here is you, valjok.
>The JLS is the final authority on what is and is
> not valid Java. By definition.
Translation: Discussing some legislation, we must consider it absolutely flawless.
Bigot: Everyting is created by God.
Sceptic: Prove that.
Bigot: The Bible tells.
I recommend "Kissing Hank's ***" dialogue http://www.jhuger.com/kisshank.php
Please draw a parallel with jver's statement. Another parallel is assigning a fox to guard a hen-house.
> You are an idiot. You call everybody bigot who
> happens to agree with decisions that were made
> in Java, rather than agreeing with you. Get over
> yourself, you whiny child.
It is important to get a feedback to make sure you is not an idiot. This is especially important when the croud tells the sky is red pointed to blue.
> The creators of the language felt that the benefits
> provided by this would outweigh the downside. You
> get almost nothing for it. I've never seen a case
> where it would be better design or better code to do
> it that way.
Have you seen any ever examples of non-existent feature, like using covariancy before is was introduced?
> The language designers saw large risk and low benefit.
> I happen to agree with them. So do many others.
OK, then tell that you merely like having the super constructor first. I just feel anger when people are guided by the rules:
1. The commander is always right.
2. If the commander is not right, look at the rule 1.
This prevents you from expressing any reasonable opinion.
> Perhaps it's out of frustration, because rational arguments
> are wasted on you.
Show me at least one rational argument. May be I have missed something.
> No, you're missing something. I'm talking about clients of
> my class, not the constructor.
Yet you are missing something. This is a topic on constructors and, particularily, the super() usage in it. Clients of my objects never call the super(). Don't try to confuse anyone.
> I disagree with you there. I spent a long time modeling systems
> as an engineer, and none of my models ever had anything to do
> with biology. Physics were more pertinent to me. Don't use the
> word "mostly". It's not correct.
I have googled for 'borrowing ideas from nature for engineering' and most examples are biological. Sorry.
>> Glad to see that that their position is wrong
>> and this is the superconstructor which is unnatural.
> I'll look for that super constructor on the Human Genome web
> site. Based on your views, I should find a sequence that
> spells out the code for my super constructor.
You don't have to. The membership to a "Homo Sapiens" class is an attribute defined by your structure (two legs and arms, 10 fingers, etc.), rather than by the order of construction of the organs. An instance of Circle class (has a radius) is always a Figure (has color and line width) regardless of the fields initialization order.
> Personally, I find that use of super constructor to be quite natural.
If you cannot find it in the genome, you may bring the embryonology photoevidence of how human passes the formation stages mimicing the fish, rat, ... Please give much simpler example of superconstruction in the floppy disc - disc or hammer - instrument relationship.
> I have no idea whether you know much about either or if you're
> one of those people who like to cite the names of complex theories
> to demonstrate their "superior" intelligence and hope to God that
> no one asks them a detailed question about them.
> If you do know about quantum mechanics, please post a derivation
> of the Hamiltonian for the hydrogen atom. (Extra credit: Post one
> for helium.)
And who of us, after that, self-actualizes demonstrating his superiority?. Do you, as a better expert in QM, forbid me to use this word-combination at the public? Can I still name other topics? Keep in mind then that there are always better specialists than you. Should we all refrean from expressing our opinions for this reason?
> It is the final authority on what Java is and isn't. You can
> argue about how "correct" the rules are, but those are the rules.
And what I'm doing is figuring out thir correctness. Thank you for allowing me to. Please, read "Kissing Hank's ***" and do not refer anymore the JLS as an evidence of why it is correct.
> A constructor is intended to put an object in a valid state.
> If it isn't in a valid state then the construction process
> should not succeed.
Exactly. The one important thing to understand that only one object is constructed rather than a parent+child.
> By attempting to circumvent the parental construction process
> you are increasing the possibility that the parent will not be
> in a valid state.
Under the "parent" you mean the derived fields. Since only one objcet is constructed, there are no two states. The state of any object is formally described by a set or vector of variables. In programming they are called fields of object, in general math and physics they are elements of state vector. Any object has only one state. All the fields of the state are EQIVALENT. It is nonsense to say that the derived elements are suerior to the newly exposed and, therefore, must be initialized first. Like with the classic Figure - Circle OOP example, you insist that the color must be initialized prior to radius, since it is inherited and Circle must first become a Figure, while I'm telling the color and radius are equivalent and the vector elements are alowed to be filled simultaneously. Bringing the system into initial state by a single assignment is perfectly valid.
Even more trivial example than the Fugure-Circle relationship would be the extention of a 2D-point to Point3D, since no new functionality is added besides extrafield in the state vector. None conscious engeneer will init the point by preceding z-assignment with <x,y> assignment. Extending a datapath of a processor from 8 to 16 bit does not mean we must first put the inherited nibble into "a valid state". The assignment is done in parallel, if possible. My supervisor some day told me that the SW people are narrow-minded, I could not just imagine to which extent.
> Your examples wouldn't reflect any reality in any other OO language either.
If SW is not a simulation of reality, then I don't know what is needed for. In contrast, your examples of supervisor interface extending a manager or an oak being a descendant of a acorn are very instructive. Please read some papers on OOP history and advantages if you do not beleive me that it relies in the simplicity of mapping the real-world into SW model. In fact, the first OOP methodology appeared in Stimula, which was desgned to simulate the evolution of ships.
> I am also free to hope fervently that I will never have to maintain a
> system where someone decided that a chimp was a parent of a human.
Please, do not distort my words. I have never told the chips are "parents" of some human. I have just told that our common ancestor had a tail and his intellectual caps were closer to the chipm. In fact, me with a friend used the Animal who produced an abstract voice -> Cow + Dog inheritance as an illustration to test the object pascal features many years ago. I wonder why this example should have some maintanence troubles in java.
Once again, I do not understand why do you keep using the "parent"-"children" terminology while ancestor/descendant or super/sub-class is used in OOP and java for inheritance relatioship notification.
> None of that has anything to do with inheritance. I have done an
> exstensive amount of programming in the financial industry but
> even so I would never claim that credit card should be the child
> of money nor that it should be the child of plastic.
I have never told that a piece of plastic is-a money. Though, why not if it IS-A tool of payment?
> Your suggestion would add complexity.
>> Any complexity must be
>> thoroghly justified. Any redundant artifical
>> complexity must be eliminated. Not the contrary.
> And thus your solution should not be added.
Removing an artificial barrier, simplifying the java synthax would add a complexity? Peahaps, we have different definitions of complexity?
The task is to draw a line from a to b. I tell just (1) draw a direct line. You tell: (1) draw a direct line; and (2) in the range [0..1] the line must be a sine. I have no ideas how two rules, whereby the second contradicts to the way you usually behave only under special condition is simpler (for the user reading and adhering the spec) than only one rule: do not use uninitialized fields. This is the only rule all the engeneers must honor.
Please, explain why do you call an extra barrier at a usual way "a simplification"? Answer the appilation I have provoced in the last post:
"However, I appeal to inconsistency in the language. Please take a java tutorial and see how parameters are evaluated. Please make sure that they are evaluated before the function call. And then verify this rule applying it to the statements in a constructor. Note that the basic control flow given is false and something different happends since java constructors violate it - the argument evaluation works in some different way.
Is it what you call a "simplification"? You add some exception to a simple grammar to conflict with other rules and call it a "simplification"? Do you trade off the power for this "simplification"? Why did java community decid to get rid of the covariance "simplification" from the java lang?
It is hard to talk to people who topsy-turn the conventional notions.
> I am not aware of any one doing that. I am aware of people
> who suggest that an overloaded method should be allowed to
> return any type. And people discount that as there are situations
> of that which make runtime processing impossible.
Prohibiting to return a subtype defeats a poymorphysm. When I first encountered the problem (in java 1.4), it was clear that the bug is in a specification rather than in my design. A subtype is a type. A supertype obviously not a subtype.
In programming, the terms 'overriding' and 'overloading' are diffirintiated. The overloading means introducing a new method (distinguished by a new parameter list). Thus, it is allowed to return any type. It also has nothing to do with OOP.
> Not to mention that C++ added that rather late and java was
> based on that. So it is quite possible that the idea did not
> exist for the initial java developers.
Which problem did not exist? The problem of bypassing the covariance flaw in the java design by the endless casting? Becouse those who do not agree with JLS don't program in Java? Or you are saying that the covariance intoduced under c++ pressure has created a problem java developers? Obviously, the mind of those, who readily accept today the lack of Set.get(key), the lack of interface conflict resolution and the superfirst redundacy, should be affected.
> As I said, numerous books and articles in C++ suggest
> that construction of the parent should be complete before
> the child starts. That would be a best practice then.
Name at least one, if you have read. C++ is the most popular lang, you know, the number of books dedicated to it is innumerable. I suppose the recommendation is of step-by-step programming guide: "At first, you must not to forget to initialize the derived fields..." You blame me taking the mapping between OOP and reality too close, meantime read the guies for noobs too literaly.
> > Translation: "My way is right because I said
> > so and if you disagree with me you're a big >
> > mean doody-head by definition."
> > The only bigot here is you, valjok.
>
> >The JLS is the final authority on what is and is
> > not valid Java. By definition.
>
> Translation: Discussing some legislation, we must
> consider it absolutely flawless.
Nope.
You unerstand nothing. You're not interested in an actual discussion. Leave.
jverda at 2007-7-20 23:53:15 >
> > The language designers saw large risk and low
> benefit.
> > I happen to agree with them. So do many others.
>
> OK, then tell that you merely like having the super
> constructor first. I just feel anger when people are
> guided by the rules:
> 1. The commander is always right.
> 2. If the commander is not right, look at the rule
> 1.
You bloody vile puddle of excrement. Nobody here has expressed anything even close to that. It is merely a sign of your irrationality that you take any opinion that doesn't agree with you as falling into that category.
> This prevents you from expressing any reasonable
> opinion.
It would if anybody had that view. But we don't. You, on the other hand, have repeatedly demonstrated an "if you don't agree with me you're automatically a bigot" attitude, and that is preventing you from saying anytyhing reasonable or worth reading.
jverda at 2007-7-20 23:53:15 >
>
>
> > A constructor is intended to put an object in a
> valid state.
> > If it isn't in a valid state then the construction
> process
> > should not succeed.
>
> Exactly. The one important thing to understand that
> only one object is constructed rather than a
> parent+child.
>
I never said otherwise. Nor did anyone else.
However a child can't be valid if the parent isn't.
And the current situation makes that less likely.
>
> > By attempting to circumvent the parental construction process
> > you are increasing the possibility that the parent will not be
> > in a valid state.
>
> Under the "parent" you mean the derived fields.
Derived fields?
> Since
> only one objcet is constructed, there are no two
> states.
Incorrect. A parent can choose to construct items that the child has no access to at all. If those objects do not exist then the parent is invalid.
> The state of any object is formally described
> by a set or vector of variables. In programming they
> are called fields of object, in general math and
> physics they are elements of state vector. Any object
> has only one state.
No one is claiming that the fields do or do not exist. What is under discussion is the values that those fields have.
> All the fields of the state are
> EQIVALENT. It is nonsense to say that the derived
> elements are suerior to the newly exposed and,
> therefore, must be initialized first.
"Nonsense" is meaningless given that is is an attempt to denigrate the idea and it is also incorrect as well.
In OO a parent is considered a logical entity. The parent has a state. That state is independent of the child because that state might include items that the child is totally oblivous of.
And until the parent state is valid that child can't rely on the functionality of the parent. The current usage minimizes the possibility that the parent will be in an invalid state.
> Like with the
> classic Figure - Circle OOP example, you insist that
> the color must be initialized prior to radius, since
> it is inherited and Circle must first become a
> Figure, while I'm telling the color and radius are
> equivalent and the vector elements are alowed to be
> filled simultaneously. Bringing the system into
> initial state by a single assignment is perfectly
> valid.
I never said that one couldn't create a valid program by allowing the initialization of the parent at any time.
What was said was that the current rules minimize the potential for mistakes.
>
> Even more trivial example than the Fugure-Circle
> relationship would be the extention of a 2D-point to
> Point3D, since no new functionality is added besides
> extrafield in the state vector. None conscious
> engeneer will init the point by preceding
> z-assignment with <x,y> assignment. Extending a
> datapath of a processor from 8 to 16 bit does not
> mean we must first put the inherited nibble into "a
> valid state". The assignment is done in parallel, if
> possible. My supervisor some day told me that the SW
> people are narrow-minded, I could not just imagine to
> which extent.
That last point appears, again, to be an attempt to denigrate.
Your particular example in this case is trival and probably represents an Object that is not truly a real OO object because it has no real behavior (versus data.)
Consider this example: AccountRecord with a parent of Database. Database sets up the database connection. If the database connection is not valid then what behavior in AccountRecord is valid?
>
>
>
>
> > Your examples wouldn't reflect any reality in any
> other OO language either.
>
> If SW is not a simulation of reality, then I don't
> know what is needed for. In contrast, your examples
> of supervisor interface extending a manager or an oak
> being a descendant of a acorn are very instructive.
> Please read some papers on OOP history and advantages
> if you do not beleive me that it relies in the
> simplicity of mapping the real-world into SW model.
> In fact, the first OOP methodology appeared in
> Stimula, which was desgned to simulate the evolution
> of ships.
I didn't say acorn was a parent of Oak. I said that your examples reflected that. In my hierarchy acorns would be a collection of Oak only. There is no way that an acorn could ever be the parent.
>
>
>
>
>
> > I am also free to hope fervently that I will never
> have to maintain a
> > system where someone decided that a chimp was a
> parent of a human.
>
> Please, do not distort my words. I have never told
> the chips are "parents" of some human. I have just
> told that our common ancestor had a tail and his
> intellectual caps were closer to the chipm. In fact,
> me with a friend used the Animal who produced an
> abstract voice -> Cow + Dog inheritance as an
> illustration to test the object pascal features many
> years ago. I wonder why this example should have some
> maintanence troubles in java.
Reply #5....
This is a programmer who writes a constructor and the object constructioin order is therefore his choice.
...
Show me why I cannot construct a human without first producing an ape?
Your post suggested that you were drawing an analogy between construction of child parent and human and ape.
Feel free to post what you really meant by that.
>
> Once again, I do not understand why do you keep using
> the "parent"-"children" terminology while
> ancestor/descendant or super/sub-class is used in OOP
> and java for inheritance relatioship notification.
>
Are you having difficulty with the terminology?
>
>
>
> > None of that has anything to do with inheritance. I
> have done an
> > exstensive amount of programming in the financial
> industry but
> > even so I would never claim that credit card should
> be the child
> > of money nor that it should be the child of
> plastic.
>
> I have never told that a piece of plastic is-a money.
> Though, why not if it IS-A tool of payment?
Not sure I understand your question.
However in common usage the payment type is considered an attribute of the transaction.
>
>
>
>
>
> > Your suggestion would add complexity.
>
> >> Any complexity must be
> >> thoroghly justified. Any redundant artifical
> >> complexity must be eliminated. Not the contrary.
>
> > And thus your solution should not be added.
>
>
> Removing an artificial barrier, simplifying the java
> synthax would add a complexity?
In understanding flow and rules.
>
>
> Please, explain why do you call an extra barrier at a
> usual way "a simplification"? Answer the appilation I
> have provoced in the last post:
> "However, I appeal to inconsistency in the
> language. Please take a java tutorial and see how
> parameters are evaluated. Please make sure that they
> are evaluated before the function call. And then
> verify this rule applying it to the statements in a
> constructor. Note that the basic control flow given
> is false and something different happends since java
> constructors violate it - the argument evaluation
> works in some different way.
>
> Is it what you call a "simplification"?
What does that have to do with construction?
> You add some
> exception to a simple grammar to conflict with other
> rules and call it a "simplification"? Do you trade
> off the power for this "simplification"? Why did java
> community decid to get rid of the covariance
> "simplification" from the java lang?
Not sure what you mean.
I believe I already mentioned what I thought was a reasonable explanation for why covariance was not added to java initially.
>
> > I am not aware of any one doing that. I am aware of
> people
> > who suggest that an overloaded method should be
> allowed to
> > return any type. And people discount that as there
> are situations
> > of that which make runtime processing impossible.
>
> Prohibiting to return a subtype defeats a
> poymorphysm. When I first encountered the problem (in
> java 1.4), it was clear that the bug is in a
> specification rather than in my design. A subtype is
> a type. A supertype obviously not a subtype.
>
I didn't say sub type. I said any type. I meant what I said.
> In programming, the terms 'overriding' and
> 'overloading' are diffirintiated. The overloading
> means introducing a new method (distinguished by a
> new parameter list). Thus, it is allowed to return
> any type. It also has nothing to do with OOP.
>
Again I meant what I said. The general argument is that someone wants to provide an overloaded method which returns a different type (not a sub type) given a signature that does not vary in any other way.
I suppose one could make the same argument using overriding but the discussions I have seen were always overloaded.
And there are reasons due to runtime considerations where that is not possible.
>
>
> > Not to mention that C++ added that rather late and
> java was
> > based on that. So it is quite possible that the
> idea did not
> > exist for the initial java developers.
>
> Which problem did not exist? The problem of bypassing
> the covariance flaw in the java design by the endless
> casting? Becouse those who do not agree with JLS
> don't program in Java? Or you are saying that the
> covariance intoduced under c++ pressure has created a
> problem java developers? Obviously, the mind of
> those, who readily accept today the lack of
> Set.get(key), the lack of interface conflict
> resolution and the superfirst redundacy, should be
> affected.
C++ allows covariance of return types when an overridden method returns a super class of the initial return type.
That particular feature was added to C++ very late in the C++ ANSI process.
>
>
>
> > As I said, numerous books and articles in C++
> suggest
> > that construction of the parent should be complete
> before
> > the child starts. That would be a best practice
> then.
>
> Name at least one, if you have read.
I simply don't feel like doing the research. At least not at this time.
> C++ is the most
> popular lang, you know, the number of books dedicated
> to it is innumerable. I suppose the recommendation is
> of step-by-step programming guide: "At first, you
> must not to forget to initialize the derived
> fields..." You blame me taking the mapping
> between OOP and reality too close, meantime read the
> guies for noobs too literaly.
No idea what you are talking about.
valjok dixit
>Show me at least one rational argument. May be I have missed something.
I did ask you a fairly fundemental question about the meaningfulness of the type hierarchy you assumed as the basis of your OP, which you seem not to have answered.
I believe it would be instructive to both of us if you did.
> Should SUN cease their RFE practice?
No. But if you want a new language feature, the correct way to get it is to raise an RFE. To improve your chances of getting it, you should produce a demonstration implementation of it, to prove that it's feasible.
Ranting at knowledgeable developers isn't the way to get it.
Personally I think this is mind-blowingly pointless. Its only effect would be to make your code look slightly tidier, while encouraging a particularly insidious flavour of bug. But if you want it, go raise the RFE. There's no point in complaining about how we don't appreciate your genius.
Oh, and let us know the bug id, because I do look forward to reading the evaluation on it.
D.
> I think you can find more than a couple
> of C++ best practices books and articles
> that will tell you how C++ constructors should be built.
My C++ is pretty rusty, but don't superclasses' constructors have to be called in the initializer list?
Which amounts to exactly the same requirement, presumably for the same reason?
> > I think you can find more than a couple
> > of C++ best practices books and articles
> > that will tell you how C++ constructors should be
> built.
>
> My C++ is pretty rusty, but don't superclasses'
> constructors have to be called in the initializer
> list?
I believe so. I know C# does it that way.
>
> Which amounts to exactly the same requirement,
> presumably for the same reason?
I suspect one of Stroustrup's books might make it explicit.
> > I think you can find more than a couple
> > of C++ best practices books and articles
> > that will tell you how C++ constructors should be
> built.
>
> My C++ is pretty rusty, but don't superclasses'
> constructors have to be called in the initializer
> list?
Rest assured, they do :-) For completeness, if there is a no-arg ctor in the superclass it is called implicitly, but it's called there, before entering the ctor body. And that's a very good thing, IMO, for Java as well.
Lokoa at 2007-7-20 23:53:20 >
> I suspect one of Stroustrup's books might make it> explicit.Can't find anything in The C++ Programming Language (3), or the ARM. Nor in the Meyers books. I'm somewhat surprised though...
> > Translation: "My way is right because I said
> > so and if you disagree with me you're a big >
> > mean doody-head by definition."
> > The only bigot here is you, valjok.
>
> >The JLS is the final authority on what is and is
> > not valid Java. By definition.
>
> Translation: Discussing some legislation, we must
> consider it absolutely flawless.
Nope, but it is the way it is until it's overturned.
> Bigot: Everyting is created by God.
> Sceptic: Prove that.
> Bigot: The Bible tells.
No one is disagreeing that it COULD be different. It's just highly unlikely.
If an egg falls on the floor, there's a chance that it might spontaneously go back together. The 2nd law of thermo says it's highly unlikely.
> I recommend "Kissing Hank's ***" dialogue
> http://www.jhuger.com/kisshank.php
> Please draw a parallel with jver's statement. Another
> parallel is assigning a fox to guard a hen-house.
Probably a waste of time.
> Have you seen any ever examples of non-existent
> feature, like using covariancy before is was
> introduced?
(sigh)
> OK, then tell that you merely like having the super
> constructor first. I just feel anger when people are
> guided by the rules:
> 1. The commander is always right.
> 2. If the commander is not right, look at the rule
> 1.
>
> This prevents you from expressing any reasonable
> opinion.
Not really. The opinion that's been expressed is that the language designers did a good job and I agree with them. Your way of doing it provides no value that I can see. I'm not prohibited from having another opinion, I just don't want to waste time talking about one that's so patently wrong.
> Show me at least one rational argument. May be I have
> missed something.
That's obvious.
> Yet you are missing something. This is a topic on
> constructors and, particularily, the super() usage in
> it. Clients of my objects never call the super().
> Don't try to confuse anyone.
I know what the topic is about. All I said was that clients of my classes can expect that my objects are completely initialized and ready to go when they are created, because I've written the constructor properly.
I've only succeeded in confusing you, but then that's not too difficult.
> I have googled for 'borrowing ideas from nature for
> engineering' and most examples are biological.
> Sorry.
You Googled for five seconds. I made a living as a practicing engineer for sixteen years. Sorry.
Please give me a close biological analog for a gas turbine engine. For extra credit, please cite the biological references used by the inventors of the gas turbine in its design.
> You don't have to. The membership to a "Homo Sapiens"
> class is an attribute defined by your structure (two
> legs and arms, 10 fingers, etc.), rather than by the
> order of construction of the organs. An instance of
> Circle class (has a radius) is always a Figure (has
> color and line width) regardless of the fields
> initialization order.
I can write a Circle class that has no color or line width. It's pure mathematical abstraction that isn't drawn or rendered anywhere. Still a Figure in your hierarchy?
> If you cannot find it in the genome, you may bring
> the embryonology photoevidence of how human passes
> the formation stages mimicing the fish, rat, ...
> Please give much simpler example of superconstruction
> in the floppy disc - disc or hammer - instrument
> relationship.
None of those involve super constructors. It's purely a s/w construct. What are you thinking?
> And who of us, after that, self-actualizes
> demonstrating his superiority?. Do you, as a better
> expert in QM, forbid me to use this word-combination
> at the public?
No, but even without being a physicist it was pretty easy for me to make clear that I know more about both those topics than you do.
> Can I still name other topics? Keep in
> mind then that there are always better specialists
> than you. Should we all refrean from expressing our
> opinions for this reason?
No, but one should refrain from using puffed up words to try to inflate our importance when we really know nothing at all about the topic.
You can always express opinions, but in the world of science facts tend to win out. This is not faith-based computing.
> And what I'm doing is figuring out thir correctness.
> Thank you for allowing me to. Please, read "Kissing
> Hank's ***" and do not refer anymore the JLS as an
> evidence of why it is correct.
I'm not citing JLS as evidence of correctness, although it's my opinion that in this case the decision was a sound one. I'm citing JLS as evidence of the existence of the rule, and the fact that your way of doing things is not possible in Java as it has been implemented.
> Exactly. The one important thing to understand that
> only one object is constructed rather than a
> parent+child.
And that's important how?
> Under the "parent" you mean the derived fields. Since
> only one objcet is constructed, there are no two
> states. The state of any object is formally described
> by a set or vector of variables. In programming they
> are called fields of object, in general math and
> physics they are elements of state vector. Any object
> has only one state. All the fields of the state are
> EQIVALENT. It is nonsense to say that the derived
> elements are suerior to the newly exposed and,
> therefore, must be initialized first. Like with the
> classic Figure - Circle OOP example, you insist that
> the color must be initialized prior to radius, since
> it is inherited and Circle must first become a
> Figure, while I'm telling the color and radius are
> equivalent and the vector elements are alowed to be
> filled simultaneously. Bringing the system into
> initial state by a single assignment is perfectly
> valid.
>
> Even more trivial example than the Fugure-Circle
> relationship would be the extention of a 2D-point to
> Point3D, since no new functionality is added besides
> extrafield in the state vector.
Actually, adding that extra dimension brings a great deal of additional complexity to problems beyond just another attribute. If you'd ever solved any 2D or 3D equations you'd know that.
You talk a lot about things that you seem to know little about. It makes me question your alleged knowledge of software, too.
> None conscious
> engeneer will init the point by preceding
> z-assignment with <x,y> assignment.
We've established that you're no physicist. Shall we see if you're an engineer, too?
Did you mean "conscientious" or "conscious"? Is English your first language?
> Extending a
> datapath of a processor from 8 to 16 bit does not
> mean we must first put the inherited nibble into "a
> valid state". The assignment is done in parallel, if
> possible.
It's not the same thing, and no one is suggesting it is but you.No one who designed a 16-bit chip did in with Java inheritance in mind.
> My supervisor some day told me that the SW
> people are narrow-minded, I could not just imagine to
> which extent.
Maybe you should leave the field and find some people more to your way of thinking - like the Taliban.
> If SW is not a simulation of reality, then I don't
> know what is needed for. In contrast, your examples
> of supervisor interface extending a manager or an oak
> being a descendant of a acorn are very instructive.
> Please read some papers on OOP history and advantages
> if you do not beleive me that it relies in the
> simplicity of mapping the real-world into SW model.
> In fact, the first OOP methodology appeared in
> Stimula, which was desgned to simulate the evolution
> of ships.
That's Simula.
Are those ships inspired by biology? Evolution like the "Beagle"? Was that the mother of all ships?
I'll have to look into the origins of Simula. After everything else you've said, I don't believe that the language was inspired by the ship building industry, but I'll find out.
> Please, do not distort my words. I have never told
> the chips are "parents" of some human. I have just
> told that our common ancestor had a tail and his
> intellectual caps were closer to the chipm. In fact,
> me with a friend used the Animal who produced an
> abstract voice -> Cow + Dog inheritance as an
> illustration to test the object pascal features many
> years ago. I wonder why this example should have some
> maintanence troubles in java.
>
> Once again, I do not understand why do you keep using
> the "parent"-"children" terminology while
> ancestor/descendant or super/sub-class is used in OOP
> and java for inheritance relatioship notification.
>
>
>
>
> > None of that has anything to do with inheritance. I
> have done an
> > exstensive amount of programming in the financial
> industry but
I hope not at my bank.
> > even so I would never claim that credit card should
> be the child
> > of money nor that it should be the child of
> plastic.
But it is the root of all evil. Does that make it analogus to java.lang.Object?
> I have never told that a piece of plastic is-a money.
> Though, why not if it IS-A tool of payment?
> Removing an artificial barrier, simplifying the java
> synthax would add a complexity?
No one agrees that it's a simplification.
>Peahaps, we have
> different definitions of complexity?
> The task is to draw a line from a to b. I tell just
> (1) draw a direct line. You tell: (1) draw a direct
> line; and (2) in the range [0..1] the line must be a
> sine.
Depends on the coordinate system, of course.
>I have no ideas how two rules, whereby the
> second contradicts to the way you usually behave only
> under special condition is simpler (for the user
> reading and adhering the spec) than only one rule: do
> not use uninitialized fields. This is the only rule
> all the engeneers must honor.
>
>
> Please, explain why do you call an extra barrier at a
> usual way "a simplification"? Answer the appilation I
> have provoced in the last post:
> "However, I appeal to inconsistency in the
> language. Please take a java tutorial and see how
> parameters are evaluated. Please make sure that they
> are evaluated before the function call. And then
> verify this rule applying it to the statements in a
> constructor. Note that the basic control flow given
> is false and something different happends since java
> constructors violate it - the argument evaluation
> works in some different way.
>
> Is it what you call a "simplification"? You add some
> exception to a simple grammar to conflict with other
> rules and call it a "simplification"? Do you trade
> off the power for this "simplification"? Why did java
> community decid to get rid of the covariance
> "simplification" from the java lang?
>
> It is hard to talk to people who topsy-turn the
> conventional notions.
It's even harder to talk to crazy people who have forgotten their meds.
> Prohibiting to return a subtype defeats a
> poymorphysm. When I first encountered the problem (in
> java 1.4), it was clear that the bug is in a
> specification rather than in my design. A subtype is
> a type. A supertype obviously not a subtype.
>
> In programming, the terms 'overriding' and
> 'overloading' are diffirintiated. The overloading
> means introducing a new method (distinguished by a
> new parameter list). Thus, it is allowed to return
> any type. It also has nothing to do with OOP.
>
>
>
> > Not to mention that C++ added that rather late and
> java was
> > based on that. So it is quite possible that the
> idea did not
> > exist for the initial java developers.
>
> Which problem did not exist? The problem of bypassing
> the covariance flaw in the java design by the endless
> casting? Becouse those who do not agree with JLS
> don't program in Java? Or you are saying that the
> covariance intoduced under c++ pressure has created a
> problem java developers? Obviously, the mind of
> those, who readily accept today the lack of
> Set.get(key), the lack of interface conflict
> resolution and the superfirst redundacy, should be
> affected.
>
>
>
> > As I said, numerous books and articles in C++
> suggest
> > that construction of the parent should be complete
> before
> > the child starts. That would be a best practice
> then.
>
> Name at least one, if you have read.
You're treading on thin ice here. Joe's read and written a lot of C++. Probably more than you have quantum mechanics, that's for sure.
> C++ is the most
> popular lang, you know, the number of books dedicated
> to it is innumerable.
Not in the Borders I visit. A search of Amazon.com would be interesting.
Besides, I don't think that's the best measure of "popular". Number of production systems? Most job ads at Dice.com? COBOL might be most popular by other measures; so might C.
> I suppose the recommendation is
> of step-by-step programming guide: "At first, you
> must not to forget to initialize the derived
> fields..." You blame me taking the mapping
> between OOP and reality too close, meantime read the
> guies for noobs too literaly.
My suggestion would be for you to invent your own language. Write the grammar, the parser, the code generator for whatever OS/chipset you choose, and get your language out there on SourceForge. We'll see just how compelling your ideas are. If your language sweeps the world, we'll all admit that we were wrong in this thread and start using it.
I'm tired after reading all this nonsense. Bedtime!
%
> Please give me a close biological analog for a gas
> turbine engine.
Hmmm.... suck, squeeze, bang, blow sounds pretty biological to me.
And the notion of craming as much in one end and forcing into a smaller volume than it should really fit into sounds like Thanksgiving dinner.
jverda at 2007-7-20 23:53:20 >
> > Please give me a close biological analog for a gas> > turbine engine. Angostura.Whittle was pretty bitter about the way we gave the design away to you yanks :-)D.
