The Big Programming Thread - Page 767

On September 24 2016 19:55 Prillan wrote:

One reason why I like the explicit self in python.

def method(self, bar):
   ... code here ...

On September 24 2016 18:22 Acrofales wrote:

Yeah, ok. That's pretty bad. Anybody using shadowing like that is asking for it, though

I mean, I'm not a fan of shadowing in general and never use it, except in the constructor to initialize fields. And that goes at the bottom of the constructor, so any operations you do before just setting the field aren't affected b the potential bugs you describe.

On September 24 2016 20:21 Acrofales wrote:


I don't see how that solves anything. And you have the global scope as well.

def method(self):
  foo = 1

On September 24 2016 20:37 spinesheath wrote:

Even if someone is aware of this possibility there still might be a time where he accidentally runs into that issue. Especially if the code for that class is modified well after it was first created.

Treat shadowing as a warning/error, use naming conventions that let you avoid all shadowing and you will have one less potential problem to worry about.

Though it certainly should be possible to create a more sophisticated shadowing warning rule that reports all shadowing except for simple initialization from the constructor.

On September 24 2016 23:36 RoomOfMush wrote:

Eclipse already has a build in warning for local variables shadowing fields with optional warnings for within constructors & setters. Furthermore there is a warning for fields shadowing inherited fields of super classes. The different syntax highlighting for fields and local variables is enabled by default too so unless you explicitly change it you should always see the difference when working with a local variable compared to a field.

But I dont like naming parameters the same as fields either. I usually give parameters long and descriptive names while fields get abbreviated forms. Doesnt always work though.

On September 24 2016 23:55 Manit0u wrote:


You should always assume that someone might be looking at your code through vim or something and won't get all the IDE syntax sugar. As was stated previously, relying on smart IDE features to help with unclear code is a bad idea. It's pretty close to code obfuscation.

On September 26 2016 00:11 travis wrote:
im not sure if this is a java specific question or not

but when do you want to use try/catch blocks instead of if(condition) { throw exception() } ?

is it only for checked instead of unchecked exceptions or is it more complicated than that?

On September 26 2016 00:11 travis wrote:
im not sure if this is a java specific question or not

but when do you want to use try/catch blocks instead of if(condition) { throw exception() } ?

is it only for checked instead of unchecked exceptions or is it more complicated than that?

On September 26 2016 00:36 RoomOfMush wrote:

The simple answer: You use a try / catch block when you need it.

The better answer: You should build your software in a way that you never need a try / catch block unless when interfacing with third party systems or using native resources.

A try / catch block indicates that the programmer knows the code within the try block might throw an exception. In general this should only happen (a) when you use a method improperly, (b) when you dont know what the code will actually do (because you load it dynamically) or (c) when you use system components that might randomly fail (reading files from the OS when you dont have access, networking, etc).

Obviously you should always use third party libraries (or even your own code) correctly so the first of the above 3 "reasons" isnt a good reason at all. The other 2 reasons are unavoidable.

Examples:
B) You allow the user to customize your software with a plugin system. Users may write their own plugins, load them into the application and have them perform tasks. As the developer of your application it is impossible for you to know what exactly those plugins do and they might throw exceptions if they are nor properly written. For this reason you wrap all calls to the plugin system in try / catch blocks to make sure your application doesnt crash randomly because of faulty plugins.

C) You connect to a server to request certain data to be used by your application. The network might always randomly fail and a connection may be lost at any point in time. To make sure your application doesnt crash in these situations you wrap the networking code into try / catch blocks. When an exception is caught you display error dialogs to the user to let him know the connection was lost and he has to try again.


Edit:
By the way, even though it is possible you should NEVARR use exception to control the flow of your application. At least not in java. The performance of exceptions is horrendous compare to if/then/else statements. Every time an exception is generated the entire stack has to be traversed backwards to build the stacktrace. It also has to read all kinds of debug information from the .class files to generate a proper error message.

It seems they cast their object to the type relatable, which is their interface. Their interface requires that a class have the method isLargerThan(); . But in an interface, isLargerThan(); is empty, to be defined in the implementing class, right? So wtf does casting a random object to the interface type actually do? It doesn't have the isLargerThan(); method. So.. I don't get it.

On September 27 2016 08:29 travis wrote:
edit: another question

why do constructors use the "this" keyword to set instance variables, but I keep seeing examples of copy constructors that *don't* use the "this" keyword when copying the variables?

public class Animal {
    
    public String name;
    public Object lazyExample;
    public int id;

    public Animal(String name, Object lazyExample, int id) {
        this.name = name;
        this.lazyExample = lazyExample;
        this.id = id;
    }

    public Animal(Animal other) {
        name = other.name;
        lazyExample = new Object(other.lazyExample);
        id = other.id;
    }
}

public Animal(Animal other) {
        this.name = other.name;
        this.lazyExample = new Object(other.getLazyExample);
        this.id = other.id;
}

On September 27 2016 08:29 travis wrote:
"An interface can be used to create a 'polymorphic collection'"

-I have no idea. I've never heard of a polymorphic collection. I tried doing a google search. Not much information. I saw something about Collection<? extends A> . Don't know what this would have to do with interfaces.

list<Shape*> shapeList;
shapeList.append(new Circle);
shapeList.append(new Rectangle);

On September 27 2016 09:49 Birdie wrote:

Only classes which implement a particular interface can be cast to that interface. So it isn't a "random" object, it is an object which already implements all the methods in that interface.

It says that in that document: "If you define a reference variable whose type is an interface, any object you assign to it must be an instance of a class that implements the interface."

In the example given, the Object class must be implementing the Relatable interface (and therefore has a method implementation of isLargerThan).

Think of an interface as a contract which the implementing class agrees to follow. The "implement" keyword is the class signing the contract, and the interface's methods are the terms of the contract. The class must follow the contract by creating methods which are the same as the interface's methods. Any class which signs the interface contract can then have the interface's methods called on it, because it guarantees by signing it (with the "implement" keyword) that it will have a version of all the methods in an interface.

On September 27 2016 11:26 travis wrote:


So then if the Object class is implementing the Relatable interface and therefore has a method implementation of isLargerThan , then what is the point of casting it to that interface type? It already has the method, so what new thing does casting it to the interface type do?

RelatableObject* relatable;
relatable = new Integer(3);
relatable->isLargerThan(PI);
relateble = new Real(3.5);
relateable->isLargerThan(PI);