Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24653 > unrolled thread

Re: multiple inheritance in Java

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 10:04 -0600
    Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 11:17 -0600
      Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 17:10 -0400
    Re: multiple inheritance in Java Lew <lewbloch@gmail.com> - 2013-07-05 12:26 -0700
      Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 16:22 -0600
      Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:52 -0400
    Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 17:09 -0400
      Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 16:29 -0600
        Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:53 -0400
          Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 22:31 -0600
            Re: multiple inheritance in Java Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 22:48 -0300

#24653 — Re: multiple inheritance in Java

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Supersedes: <multiple-inheritance-20130702021857@ram.dialup.fu-berlin.de>
> [edited first »r = 72« to »setR( 72 )« and so on for the next four lines]
>
>   Assume you needed a class ColorPoint in Java:
>
> class ColorPoint extends Position, Color;
>
>   . Would it be so bad to implement this using public fields
>   instead of classical delegation? Public fields:
>
> { public final Color color;
>   public final Position position; ... }
>
>  , usage:
>
> point.color.setR( 72 );
> point.color.setG( 65 );
> point.color.setB( 41 );
> point.position.setX( 212 );
> point.position.setY( 117 );
>
>   . Classical delegation style:
>
> point.setR( 72 );
> point.setB( 65 );
> point.setC( 41 );
> point.setX( 212 );
> point.setY( 117 );
>
>   . I only ask, because public fields usually are frowned upon
>   in OOP, but what would be the drawback here, especially when
>   those fields are final?

In theory, if this is a simple aggregation of data, with no relationship
between the various parts, then you might as well just make them public.
If there is some meaning beyond simple aggregation, in particular if you
can define one or more invariants for the class, then you need to
encapsulate the fields so that the class can maintain those invariants.

On the other hand, and this is probably more important, the Java
community sets great store on always doing things the usual way, and
this has turned into a strength for the language: you can pull a
third-party library library into a project and expect that it will work
with and follow the same conventions as the rest of the code.  There are
languages that encourage the programmer to express his or her
individuality (Lisp comes to mind).  Java is not one of them.

-- 
Jim Janney

[toc] | [next] | [standalone]

#24656

Jim Janney <jjanney@shell.xmission.com> writes:

> On the other hand, and this is probably more important, the Java
> community sets great store on always doing things the usual way, and
> this has turned into a strength for the language: you can pull a
> third-party library library into a project and expect that it will work
> with and follow the same conventions as the rest of the code.

Recently I've been looking at an interesting exception to this, JSch:

    http://www.jcraft.com/jsch/

If you do a little searching on the web you can find lots of complaints
that the code isn't very Java-ish, and on my own reading of the source I
tend to agree.  It nevertheless continues to be a successful project
with widespread use, and I think there's a reason for that.  SSH has a
well-defined standard and the code is a faithful implementation of
that.  Once you study the standards document, the JSch code starts to
make sense.  It's also a stable protocol that seems unlikely to change,
so there's not a lot of reason to want to extend it yourself.  But most
projects aren't like that.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#24664

On 7/5/2013 1:17 PM, Jim Janney wrote:
> Jim Janney <jjanney@shell.xmission.com> writes:
>> On the other hand, and this is probably more important, the Java
>> community sets great store on always doing things the usual way, and
>> this has turned into a strength for the language: you can pull a
>> third-party library library into a project and expect that it will work
>> with and follow the same conventions as the rest of the code.
>
> Recently I've been looking at an interesting exception to this, JSch:
>
>      http://www.jcraft.com/jsch/
>
> If you do a little searching on the web you can find lots of complaints
> that the code isn't very Java-ish, and on my own reading of the source I
> tend to agree.  It nevertheless continues to be a successful project
> with widespread use, and I think there's a reason for that.  SSH has a
> well-defined standard and the code is a faithful implementation of
> that.  Once you study the standards document, the JSch code starts to
> make sense.  It's also a stable protocol that seems unlikely to change,
> so there's not a lot of reason to want to extend it yourself.  But most
> projects aren't like that.

I am sure there are other exceptions as well.

There must be some code ported from C# or c++ that follow different
idioms and paradigms than standard Java.

But it is exceptions to the rule.

Arne

[toc] | [prev] | [next] | [standalone]

#24662

Jim Janney wrote:
> In theory, if this is a simple aggregation of data, with no relationship
> between the various parts, then you might as well just make them public.
> If there is some meaning beyond simple aggregation, in particular if you
> can define one or more invariants for the class, then you need to
> encapsulate the fields so that the class can maintain those invariants.

Good points, and indirectly raises to mind that there are many factors that 
influence implementation choices like access level. Harping on "in theory", 
if the theoretical model is solely semantic then public variables are fine.

In practice, that is with a model that includes more analytical dimensions, 
you seal an attribute in a get/set for invariants, yes, but also strictly 
internal ones, and also for thread safety, initialization timing, exception 
handling, and such other matters not directly connected to the primary
semantic model.

Also in practice, as an idiomatic matter, there are engineering advantages 
to using the method approach to attribute implementation.

> On the other hand, and this is probably more important, the Java
> community sets great store on always doing things the usual way, and

Pish-posh. You imagine an overarching cultural inertia to a community 
well known for its fractious insistence on competing worldviews.

What I have observed is that people who speak up on such matters in the Java 
"community" tend to be of the "I'm from Missouri, you'll have to show me" 
variety.

Turns out the get/set as a routine idiom has all upside and virtually no 
downside, so as an engineer one tends to use it, just as in C# you use 
its attribute idioms routinely. But "routinely" doesn't mean "mindlessly" 
or "superstitiously" or "to meet the 'community's' approval".

> this has turned into a strength for the language: you can pull a
> third-party library library into a project and expect that it will work

That had better be a strength of every third-party library in every language 
for every platform, hm?

> with and follow the same conventions as the rest of the code.  There are

Code conventions and a library's utility are weakly correlated, I venture.

Internal consistency within the library, sure, but conformity to yours or 
another third party's conventions, even in Java, are not really guaranteed, 
certainly no more so than in other widely-used languages with good conventions.

> languages that encourage the programmer to express his or her
> individuality (Lisp comes to mind).  Java is not one of them.

Sorry, LISP doesn't have coding conventions?

And what does "express ... individuality" have to do with writing good code?

I mean, perhaps it does, I just don't see its help to code quality. In 
decades of working on other peoples' code, the most "individual" code has 
been the most bug-riddled and difficult to maintain. I really don't think 
there is any evidence of a cultural or political conspiracy toward good 
quality code, which by natural selection tends to the better written.

There certainly is a lot of room for style in Java coding, but if you follow 
good engineering practices rigidly there will tend to be commonalities with 
so-called "conventions". You're going to write complete, thorough, informative 
Javadoc comments as a matter of habit. You're going to use get/set methods.
You're going to use a lot of read-only, final, immutable types. You will tend 
to use generics. You're going to indent consistently, if not conventionally. 
You're going to use version control even for solo projects where you are 
producer, director, cinematographer, stars and extras. Every input will be 
checked for boundary conditions. You probably even will have written various 
sorts of useful tests. And this is true whether you're using Java or the useful 
idioms and practices of some other platform.

It happens because you want to write and use code that works, doesn't break, 
that you can fix, that you know what, when, where, how and why. 

One of the most successful IT businesspeople I ever knew charged a service 
contract subscription but only installed stuff that never broke. He was able 
to compete heavily on up-front costs because service was a profit center. Plus 
he used the service contract as an excuse to stay in close touch with all his
customers. Thus cost of sales was actually borne by the customer, and they 
loved it. I can't recall a single customer complaining to him because their 
stuff just kept on working without trouble.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#24667

Lew <lewbloch@gmail.com> writes:

> Jim Janney wrote:
>> In theory, if this is a simple aggregation of data, with no relationship
>> between the various parts, then you might as well just make them public.
>> If there is some meaning beyond simple aggregation, in particular if you
>> can define one or more invariants for the class, then you need to
>> encapsulate the fields so that the class can maintain those invariants.
>
> Good points, and indirectly raises to mind that there are many factors that 
> influence implementation choices like access level. Harping on "in theory", 
> if the theoretical model is solely semantic then public variables are fine.
>
> In practice, that is with a model that includes more analytical dimensions, 
> you seal an attribute in a get/set for invariants, yes, but also strictly 
> internal ones, and also for thread safety, initialization timing, exception 
> handling, and such other matters not directly connected to the primary
> semantic model.
>
> Also in practice, as an idiomatic matter, there are engineering advantages 
> to using the method approach to attribute implementation.
>
>> On the other hand, and this is probably more important, the Java
>> community sets great store on always doing things the usual way, and
>
> Pish-posh. You imagine an overarching cultural inertia to a community 
> well known for its fractious insistence on competing worldviews.
>
> What I have observed is that people who speak up on such matters in the Java 
> "community" tend to be of the "I'm from Missouri, you'll have to show me" 
> variety.

All language communities are fractious, the Java community is far more
united than most.  Truly, you have no idea :-)

>
> Turns out the get/set as a routine idiom has all upside and virtually no 
> downside, so as an engineer one tends to use it, just as in C# you use 
> its attribute idioms routinely. But "routinely" doesn't mean "mindlessly" 
> or "superstitiously" or "to meet the 'community's' approval".
>
>> this has turned into a strength for the language: you can pull a
>> third-party library library into a project and expect that it will work
>
> That had better be a strength of every third-party library in every language 
> for every platform, hm?

One would like to think so, but in many languages mixing code from
different vendors can be a major headache.

>> with and follow the same conventions as the rest of the code.  There are
>
> Code conventions and a library's utility are weakly correlated, I venture.
>
> Internal consistency within the library, sure, but conformity to yours or 
> another third party's conventions, even in Java, are not really guaranteed, 
> certainly no more so than in other widely-used languages with good conventions.
>
>> languages that encourage the programmer to express his or her
>> individuality (Lisp comes to mind).  Java is not one of them.
>
> Sorry, LISP doesn't have coding conventions?

Yes, lots.  Even more than C.

    http://lmgtfy.com/?q=lisp+coding+convention

But none with the official cachet of the Oracle document.

> And what does "express ... individuality" have to do with writing good code?

Perhaps I should have said that Lisp rewards such efforts more than
Java.  Any language that can redefine its own syntax at run time is
necessarily going to be malleable, and in the right hands this can be
extremely powerful.  Paul Graham has written extensively on this
subject.  In Java, as you proceed to point out, this is not so evident.

> I mean, perhaps it does, I just don't see its help to code quality. In 
> decades of working on other peoples' code, the most "individual" code has 
> been the most bug-riddled and difficult to maintain. I really don't think 
> there is any evidence of a cultural or political conspiracy toward good 
> quality code, which by natural selection tends to the better written.
>
> There certainly is a lot of room for style in Java coding, but if you follow 
> good engineering practices rigidly there will tend to be commonalities with 
> so-called "conventions". You're going to write complete, thorough, informative 
> Javadoc comments as a matter of habit. You're going to use get/set methods.
> You're going to use a lot of read-only, final, immutable types. You will tend 
> to use generics. You're going to indent consistently, if not conventionally. 
> You're going to use version control even for solo projects where you are 
> producer, director, cinematographer, stars and extras. Every input will be 
> checked for boundary conditions. You probably even will have written various 
> sorts of useful tests. And this is true whether you're using Java or the useful 
> idioms and practices of some other platform.
>
> It happens because you want to write and use code that works, doesn't break, 
> that you can fix, that you know what, when, where, how and why. 
>
> One of the most successful IT businesspeople I ever knew charged a service 
> contract subscription but only installed stuff that never broke. He was able 
> to compete heavily on up-front costs because service was a profit center. Plus 
> he used the service contract as an excuse to stay in close touch with all his
> customers. Thus cost of sales was actually borne by the customer, and they 
> loved it. I can't recall a single customer complaining to him because their 
> stuff just kept on working without trouble.

I recommend that you spend some time studying Lisp, both the language
(actually a family of dialects, not a language) and its history.  Partly
because ideas from Lisp keep finding their way into new releases of
Java, but mostly for the history.  Note that Guy Steele also wrote the
book on Common Lisp, so he was intimately familiar with both.  Java is
interesting for what it borrowed and also for what it left out.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#24670

On 7/5/2013 3:26 PM, Lew wrote:
> Jim Janney wrote:
>> this has turned into a strength for the language: you can pull a
>> third-party library library into a project and expect that it will work
>
> That had better be a strength of every third-party library in every language
> for every platform, hm?

You just made a reply to first half of the sentence without including
the second half.

Whoever told you that half sentences in English would make sense
was wrong.

>> with and follow the same conventions as the rest of the code.  There are
>
> Code conventions and a library's utility are weakly correlated, I venture.

There are certainly more important factors.

But following convention do make the library easier to use.

> I mean, perhaps it does, I just don't see its help to code quality. In
> decades of working on other peoples' code, the most "individual" code has
> been the most bug-riddled and difficult to maintain.

That is the flip side of his point.

> There certainly is a lot of room for style in Java coding, but if you follow
> good engineering practices rigidly there will tend to be commonalities with
> so-called "conventions". You're going to write complete, thorough, informative
> Javadoc comments as a matter of habit. You're going to use get/set methods.
> You're going to use a lot of read-only, final, immutable types. You will tend
> to use generics. You're going to indent consistently, if not conventionally.
> You're going to use version control even for solo projects where you are
> producer, director, cinematographer, stars and extras. Every input will be
> checked for boundary conditions. You probably even will have written various
> sorts of useful tests. And this is true whether you're using Java or the useful
> idioms and practices of some other platform.

Some conventions are good in some objective sense.

But other conventions are only good because everybody else
uses them.

Arne

[toc] | [prev] | [next] | [standalone]

#24663

On 7/5/2013 12:04 PM, Jim Janney wrote:
> On the other hand, and this is probably more important, the Java
> community sets great store on always doing things the usual way, and
> this has turned into a strength for the language: you can pull a
> third-party library library into a project and expect that it will work
> with and follow the same conventions as the rest of the code.  There are
> languages that encourage the programmer to express his or her
> individuality (Lisp comes to mind).  Java is not one of them.

That is somewhat true.

Java is primarily used in business programming. You need millions
of Java programmers and that means that you will get some very good,
a lot of acceptable and some complete hopeless. And the type
of applications are often semi-important (no one will die if the
application does not work but some one may lose money if the
application does not work). In that context it is important that
Java code written by mediocre programmers actually work. So the
Java language is kept reasonable simple, framework are often
pretty strict and there is a lot of emphasis on following
all the conventions. Maybe a bit boring. Bit usually it works.

Arne

[toc] | [prev] | [next] | [standalone]

#24668

Arne Vajhøj <arne@vajhoej.dk> writes:

> On 7/5/2013 12:04 PM, Jim Janney wrote:
>> On the other hand, and this is probably more important, the Java
>> community sets great store on always doing things the usual way, and
>> this has turned into a strength for the language: you can pull a
>> third-party library library into a project and expect that it will work
>> with and follow the same conventions as the rest of the code.  There are
>> languages that encourage the programmer to express his or her
>> individuality (Lisp comes to mind).  Java is not one of them.
>
> That is somewhat true.
>
> Java is primarily used in business programming. You need millions
> of Java programmers and that means that you will get some very good,
> a lot of acceptable and some complete hopeless. And the type
> of applications are often semi-important (no one will die if the
> application does not work but some one may lose money if the
> application does not work). In that context it is important that
> Java code written by mediocre programmers actually work. So the
> Java language is kept reasonable simple, framework are often
> pretty strict and there is a lot of emphasis on following
> all the conventions. Maybe a bit boring. Bit usually it works.

I was simplifying, of course, but yes: those are the very qualities that
have led to the success of Java in business programming.  Not a niche
that I think anyone expected it to find, but in hindsight it makes
sense.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#24671

On 7/5/2013 6:29 PM, Jim Janney wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>
>> On 7/5/2013 12:04 PM, Jim Janney wrote:
>>> On the other hand, and this is probably more important, the Java
>>> community sets great store on always doing things the usual way, and
>>> this has turned into a strength for the language: you can pull a
>>> third-party library library into a project and expect that it will work
>>> with and follow the same conventions as the rest of the code.  There are
>>> languages that encourage the programmer to express his or her
>>> individuality (Lisp comes to mind).  Java is not one of them.
>>
>> That is somewhat true.
>>
>> Java is primarily used in business programming. You need millions
>> of Java programmers and that means that you will get some very good,
>> a lot of acceptable and some complete hopeless. And the type
>> of applications are often semi-important (no one will die if the
>> application does not work but some one may lose money if the
>> application does not work). In that context it is important that
>> Java code written by mediocre programmers actually work. So the
>> Java language is kept reasonable simple, framework are often
>> pretty strict and there is a lot of emphasis on following
>> all the conventions. Maybe a bit boring. Bit usually it works.
>
> I was simplifying, of course, but yes: those are the very qualities that
> have led to the success of Java in business programming.  Not a niche
> that I think anyone expected it to find, but in hindsight it makes
> sense.

And hard to call business programming a niche.

I would expect it to be the majority of programming.

Arne

[toc] | [prev] | [next] | [standalone]

#24674

Arne Vajhøj <arne@vajhoej.dk> writes:

> On 7/5/2013 6:29 PM, Jim Janney wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>
>>> On 7/5/2013 12:04 PM, Jim Janney wrote:
>>>> On the other hand, and this is probably more important, the Java
>>>> community sets great store on always doing things the usual way, and
>>>> this has turned into a strength for the language: you can pull a
>>>> third-party library library into a project and expect that it will work
>>>> with and follow the same conventions as the rest of the code.  There are
>>>> languages that encourage the programmer to express his or her
>>>> individuality (Lisp comes to mind).  Java is not one of them.
>>>
>>> That is somewhat true.
>>>
>>> Java is primarily used in business programming. You need millions
>>> of Java programmers and that means that you will get some very good,
>>> a lot of acceptable and some complete hopeless. And the type
>>> of applications are often semi-important (no one will die if the
>>> application does not work but some one may lose money if the
>>> application does not work). In that context it is important that
>>> Java code written by mediocre programmers actually work. So the
>>> Java language is kept reasonable simple, framework are often
>>> pretty strict and there is a lot of emphasis on following
>>> all the conventions. Maybe a bit boring. Bit usually it works.
>>
>> I was simplifying, of course, but yes: those are the very qualities that
>> have led to the success of Java in business programming.  Not a niche
>> that I think anyone expected it to find, but in hindsight it makes
>> sense.
>
> And hard to call business programming a niche.
>
> I would expect it to be the majority of programming.

In terms of lines of code and total programmer-hours expended, that may
well be true.  Call it a large niche :-)

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#24755

On 07/06/2013 01:31 AM, Jim Janney wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>
>> On 7/5/2013 6:29 PM, Jim Janney wrote:
>>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>>
>>>> On 7/5/2013 12:04 PM, Jim Janney wrote:
>>>>> On the other hand, and this is probably more important, the Java
>>>>> community sets great store on always doing things the usual way, and
>>>>> this has turned into a strength for the language: you can pull a
>>>>> third-party library library into a project and expect that it will work
>>>>> with and follow the same conventions as the rest of the code.  There are
>>>>> languages that encourage the programmer to express his or her
>>>>> individuality (Lisp comes to mind).  Java is not one of them.
>>>>
>>>> That is somewhat true.
>>>>
>>>> Java is primarily used in business programming. You need millions
>>>> of Java programmers and that means that you will get some very good,
>>>> a lot of acceptable and some complete hopeless. And the type
>>>> of applications are often semi-important (no one will die if the
>>>> application does not work but some one may lose money if the
>>>> application does not work). In that context it is important that
>>>> Java code written by mediocre programmers actually work. So the
>>>> Java language is kept reasonable simple, framework are often
>>>> pretty strict and there is a lot of emphasis on following
>>>> all the conventions. Maybe a bit boring. Bit usually it works.
>>>
>>> I was simplifying, of course, but yes: those are the very qualities that
>>> have led to the success of Java in business programming.  Not a niche
>>> that I think anyone expected it to find, but in hindsight it makes
>>> sense.
>>
>> And hard to call business programming a niche.
>>
>> I would expect it to be the majority of programming.
>
> In terms of lines of code and total programmer-hours expended, that may
> well be true.  Call it a large niche :-)
>
Call it a huge niche, "business" programming. If you're writing code to 
solve a problem for a business, you're doing business programming. It 
may be anything from doing asset management for an airport, to analyzing 
traffic patterns in a shopping centre, to coding new laws and 
regulations into a program that needs to be aware of those laws and 
regulations. Only a small percentage of business software explicitly 
deals with money, but *all* business software deals with money at least 
indirectly, because the operations of a business (which includes 
governments) are supported.

I'd say 90 percent of programming is business programming.

AHS

-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web