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

Groups > comp.lang.java.programmer > #24667

Re: multiple inheritance in Java

Show key headers only | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web