which is syntactically correct

 

 if(!getInventory().isFull()){

 

or

 

 

 if(!client.getInventory().isFull()){

Edited November 8, 201411 yr by javant

They're both just references to the instantiation of the Inventory class in MethodProvider. Although there's no reason in doing client.getInventory() (Client isn't even a subclass of MethodProvider so I'm not sure how you'd get this.client.inventory anyways), that'd be like  doing this.bank.getInventory(). 

 

There's no reason to access a subclass of MethodProvider through another subclass.

With Script being a subclass of MethodProvider, you have direct access to all of its reference variables and methods.

 

 

Edited November 8, 201411 yr by Allen

we dont use client.inventory any more use this:

if(!inventory.isFull())
{
   // do this
}

 

we dont use client.inventory any more use this:

if(!inventory.isFull())
{
   // do this
}

 

you should use inventory's getter

getInventory()

why when we had that before and everyone complained about it. so it was shortened to inventory dot do what you want. Whats the point in going the long way round. Use inventory dot. its got all you need within it. Served my needs since osb2 started perfectly.

why when we had that before and everyone complained about it. so it was shortened to inventory dot do what you want. Whats the point in going the long way round. Use inventory dot. its got all you need within it. Served my needs since osb2 started perfectly.

 

Well it's better to practice encapsulation, because (Not my words):

 

Encapsulation can be described as a protective barrier that prevents the code and data being randomly accessed by other code defined outside the class. Access to the data and code is tightly controlled by an interface.

The main benefit of encapsulation is the ability to modify our implemented code without breaking the code of others who use our code. With this feature Encapsulation gives maintainability, flexibility and extensibility to our code.

Benefits of Encapsulation:

• The fields of a class can be made read-only or write-only.

• A class can have total control over what is stored in its fields.

• The users of a class do not know how the class stores its data. A class can change the data type of a field and users of the class do not need to change any of their code.

Hope this helps elaborate a little bit more.

mind bogglingly boring. Never caused problems with my scripts. But a'lass i love your code definition snippets NotoriousPP 

why when we had that before and everyone complained about it. so it was shortened to inventory dot do what you want. Whats the point in going the long way round. Use inventory dot. its got all you need within it. Served my needs since osb2 started perfectly.

 

Inventory is a class variable, getInventory() is a method that retrieves the variable in question.

Both actually refer to the same value.

 

getInventory() might perform some safety checks on the value in question, I don't think it does (but it might in the future).

 

If there's a getter method available for a variable it's common and safe practice to use that method instead of calling the variable directly.

 

Don't use inventory, use getInventory().

Inventory is a class variable, getInventory() is a method that retrieves the variable in question.

Both actually refer to the same value.

getInventory() might perform some safety checks on the value in question, I don't think it does (but it might in the future).

If there's a getter method available for a variable it's common and safe practice to use that method instead of calling the variable directly.

Don't use inventory, use getInventory().

Thats the problem of a non open source api.

Edited November 8, 201411 yr by Soldtodie

In a typical world, only the getter would be public (getInventory()). No idea why it was designed like this, I'd have to look and speculate why.

You should ALWAYS be programming with accessors and mutators.