Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Forum Moderator
Junilu Lacar currently moderates these forums:
Columbus OH
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Junilu Lacar

NOTE TO STUDENTS CONCERNED: It has come to our attention that we have a number of new student members here at the Ranch who have been tasked by their instructor to post at least 5 answers in forums like this. We think this is a great challenge and an awesome learning opportunity. However, to minimize duplication and a lot of "Me, too!" replies, here are some threads that we suggest you check out and try to add meaningful discussion to.

NOTE TO MODERATORS: Please feel free to add to this list of threads. Try to choose topics that may be somewhat challenging and involves having to employ some critical thinking and a defense of opinions as much as displaying accurate understanding of technical issues.

Suggested threads for students being challenged to post answers here:

* Discussion of an implementation of the Tic-Tac-Toe game:


* Discussion about an implementation of Stack:


* Debugging messy code


12 hours ago
The line to focus on is line 6 in the gen() method, where a call to gen() is made as part of the expression on that line. The expression must be completely evaluated before return can be done.  It will keep doing that until the if statement on line 5 evaluates to false and execution falls down to the else part to execute the return on line 8. At that point, the recursion is ended and the whole stack unwinds.
14 hours ago
So again, I can't reconcile my experience with Ryan's claim that he has seen cases where it's actually preferable to use preincrement over post increment.

Maybe we're reasoning with different definitions of "preferable". Maybe he meant to say "suitable" or "appropriate" instead. If that's what he meant, then I can agree with it for reasons I have already gone over ad nauseum.
15 hours ago
Nah, even if it was used on the left hand side of an assignment, there is still no real preference available since the two forms can't be functionally equivalent.
15 hours ago
Of course I did reason that you would hardly prefer doing something that is considered poor form or practice when I responded to Liutauras earlier, so I could have eliminated The Assignment form of a ForUpdate immediately. You never prefer to use a preincrement or post increment expression as part of an assignment unless maybe it's the only term on the right hand side. But then again in that case it wouldn't really be a preference because only one form can be correct in any given context.

What if the pre/post increment expression was used in the left hand side of an Assignment ForUpdate... ? Hmmm... Have to think about that for a second.
15 hours ago

Campbell Ritchie wrote:

Junilu Lacar wrote:. . . Let's say we define a for-loop like this:. . .

There are all sorts of things you can do. ...
Yes, you can define a loop like that, but as other people have said, what horrible code.

I was trying to reason about using a pre- or post-increment expression as part of an assignment as a valid scenario where one might prefer one form over another. The merits of using pre or post increment in an assignment, or lack thereof, was not part of that reasoning.

That reply you quoted was part of the long series of replies in response to Ryan's one assertion. I was just trying to find a way to reconcile his claim that in his experience, a pre-increment expression can be preferable to a post increment expression in some cases. That is not something that meshes with my own experience so I was trying to eliminate possibilities. You might want to go back a few replies more to get more context.
15 hours ago
I did some searches on terms and found that the official documentation uses "property" for what I've been referring to as "attribute" so read all my previous statements as though I had written "property" instead of "attribute".

According to https://docs.oracle.com/javase/tutorial/information/glossary.html a property is a characteristic of an object that users can set. This still applies to a Hippo's name and an Animal's name because their constructors provide a way to set it, even though there's no setter method that would allow users to make subsequent changes after the object is created.

By contrast, a field is defined as a data member of a class.
19 hours ago
From a Java programmer's perspective, here are the things I think you should concern yourself more about:

1. Does a Hippo have a name?  Yes!  You create a Hippo object with new Hippo(name) and you can ask a Hippo what its name is by calling Hippo.getName()

2. Does a Hippo have a name field? No, the name field is in its superclass Animal, which declares it as private, so the name field is not inherited by Hippo.

3. Can a Hippo access its name?  Yes, but only through its inherited getName() accessor.

4. Can a Hippo change its name? No, not unless it can access a setName(String name) method in its superclass. It doesn't appear that Animal has such a method though. The only time a Hippo can set its name is when it is being constructed. It will then pass the name value up to its superclass, which manages the value of name.

That's it. Everything else you asked about having or not having whatever is largely irrelevant to any program code you write.
21 hours ago
You have to remember that those drawings are conceptual. They are a means of modeling the relationships without necessarily depicting their actual organization in memory. It's not useful to think in terms of "physical existence" because programming at this level is not about physical organization, it's more about abstractions. Even the organization of elements of the class structure in source code is a reflection of the conceptual organization, not so much the physical representation and organization in memory. Thinking about abstractions from a "physical" perspective is flawed from the start and you're only confusing yourself more by doing so.

I think it is more accurate to say that Hippo has private members from its superclass,but has no direct access to them

No, that doesn't sound right either. 

Private members of a superclass are NOT inherited by any of its subclasses so there is no way you can correctly reason that "Hippo has private members of Animal" -- that just isn't so because the words you are using, "private members" don't jive with that idea. 

I will assert once again that if you say "A Hippo has a name attribute that it takes from its Animal superclass" you'd be more correct because "attribute" in this context is conceptual, an abstract idea that is backed by the implementation by virtue of calling super(name) from the Hippo constructor and inheriting the Animal.getName() accessor.
21 hours ago

Liutauras Vilda wrote:But probably Java easily could live only with one existing increment.

The creators of the Go Language were likely thinking along the same lines. https://golang.org/doc/faq#inc_dec
21 hours ago
You should read the Java Tutorial on Lambda Expressions, Functional Interfaces, and Method References to get a basic understanding of what the code in that example does.  When you add new FooA() to a map, you're adding a single instance of an object. Getting it back out of the map does not create any new instances.  On the other hand, Foo::new is a method reference that gets turned into an implementation of a Functional Interface.  Explaining these concepts is going to be way too long, so it's best that you go to the tutorials to bone up on those concepts.

Short version: FooA::new is NOT equivalent to new FooA(). There's a whole lot of "magic" that happens when the compiler processes FooA::new and what happens depends a lot on the context in which it is used.

In the case of noArgs.put("A", FooA::new), since noArgs is declared as a Map<String, Supplier<Foo>>, it is compiled into something that is essentially this:

This is why you have noArgs.get(kind).get() as the return value for the factory method FooFactory.get(String kind).

In the case of withArg.put("A", FooA::new), since withArg is declared as a Map<String, Function<String, Foo>>, it is compiled into something that is essentially this:

This is why you have withArg.get(kind).apply(value) as the return value for the factory method FooFactory.get(String kind, String value).
1 day ago

Jim Venolia wrote:Yeah, that's kinda why I need a book with programming assignments at the end.  Otherwise I'm gonna write some nice C code using Java syntax.  I can "do" OO, and maybe make it look like I know what I'm doing.  Only those who know what their doing will know I'm blowing smoke.

I don't think it's the finding problems to work on as much as it is being able to find and compare different solutions that help you get a sense for what's "good OO" and "not-so-good OO".  That's why I like Corey Haines' book so much. He takes so many different angles at the same problem and it gives you a lot of insights as to the different perspectives that you can take when solving a problem.

You can find lots of resources on the internet for good problems to exercise and hone your OOP skills on. Just search for "code kata" or "coding dojo" and you'll find more than you can probably handle in a year of practicing every day. The real trick to learning is studying what you've done and comparing it with what others have done. What makes their solutions better than yours? How could you have arrived at something similar to their solution? Can you do even better? What were you thinking that led you away from the better version? What didn't you know? What did you overlook? How can you use this new knowledge in other situations?

If you want feedback on things you've done, post it up in one of the forums here for review. There are more than a few people here who are willing and able to give you great feedback and advice on how to get better. That's why this community is so great.

Jim Venolia wrote:I've been programming for some 30, eeek! 40 years now, and have only brushed up against OO without actually using it.

In all those 30-40 years of programming, what kind of programming did you do? What language(s) did you use primarily? What's the most recent language/platform you programmed on and how long have you been doing that?

I cut my teeth on Structured Programming (BASIC and Pascal mainly, plus a smidge of FORTRAN and just enough C and Assembly to be dangerous). That was back in the late 80s. My first intro to the concept of objects was with Delphi or as some would call it, Object Pascal. I only sank my teeth into Java in 2000. Around that time, I discovered this community.

You'll often hear/read that OOP is a "paradigm shift" and as nebulous as that phrase is, it actually is just that. OO languages are not just different from structured languages that you may be used to, they are also geared towards a very different way of thinking about problems and how you create the solutions for them. The same radical shift is there when you move from OO or structured to functional style programming. It's enough to literally make your brain hurt, or at least make you feel like it's twisted up into knots.

A couple of books that I've been recommending a lot lately are:

1. Understanding the Four Rules of Simple Design by Corey Haines.  It's not a beginner's book by any stretch but I think the problem it discusses—there's only one—is very relatable: Conway's Game of Life. If you supplement your study of OOP fundamental concepts like polymorphism, encapsulation, inheritance with the practical lessons presented in Haines' book, I think you'll get a lot further than most people do in gaining a deeper understanding of OOP. The book uses examples in Ruby which isn't Java or Kotlin but it's close enough. Also, Ruby is arguably a more object-oriented than Java and there are significant differences in the syntax but not significant enough, IMO, to they make the concepts in the book specific to Ruby; you can apply the same principles/ideas in practically any other OO language, perhaps just not exactly as it's shown in the book.

2. Think Like a Programmer by V. Anton Spraul. This book has some really good discussions about modes of thinking and problem solving approaches that are applicable in any style of programming, whether structured, OO, or functional.

And most of all, practice, practice, practice. But practice mindfully, and always look for examples of how other people solved the same problem. That's why I like Corey Haines' book, because he presents so many ways of solving a problem and clearly explains the thought process involved in making decisions that lead to those various solutions.

Piet Souris wrote:]
I'm curious if OP thinks this is all useful.

I hope he does but it's also likely he's already moved on to other things outside the Ranch.

It was a fun exercise nonetheless and I even learned a thing or two.
1 day ago