Description: Cannot make a static reference to the non-static field Layout_1.enter. Location: Version2CaseStudy/Main/exitGL_Main - Exit - anylogic

I am trying to link the enter exit blocks (exit is in Main & enter is in an agent Layout_1 within Main) but I get the error :
"Description: Cannot make a static reference to the non-static field Layout_1.enter. Location: Version2CaseStudy/Main/exitGL_Main - Exit"

just to explain a bit
A static variable has to be defined as such, and the purpose of it, is to be a variable that is associated to the class, and not the instance of that class.
In AnyLogic from a beginner perspective you have:
A class, or an Agent type, which by convention has a name that starts with a capital letter, such as Layout
An instance of that class, or an agent from the population, which by convention is defined with a lowercase letter such as layout
A list or a population of agents, which is defined with a lower case but it's plural, such as layouts
when a variable is static and you do Layout.variable=x, you are changing the value of that variable for all instances of that class or agent type
When you do do layout.variable=x (not static), you are changing the variable value for the instance of that class, or for an agent of the population.
if you have a variable that is NOT static, and you dare doing Layout.variable you will get this error... because the variable is not defined as static, you cannot access it with Layout (upper case L)
In general you will know that this error occurs when you tried to access a variable using the class or agent type (uppercase first letter) since AnyLogic by default doesn't allow you to create static variables, so it's almost certain that you made this mistake.

Related

Difference between objects, attributes, variables and class instance

I am having trouble understanding my professor's lecture notes because my brain seem to treat objects, attributes, variables and class instance as interchangeable. I really appreciate any help in distinguishing these 4 terms. Thank you!
this would be helpful for u Visit https://www.quora.com/What-is-the-difference-between-instance-variable-and-class-variable
Class variables are declared with keyword static and Instance variables are declared without static keyword.
Class variables are common to all instances of a class. These variables are shared between the objects of a class. Instance variables are not shared between the objects of a class. Each instance will have their own copy of instance variables.
As class variables are common to all objects of a class, changes made to these variables through one object will reflect in another. As each object will have its own copy of instance variables, changes made to these variables through one object will not reflect in another object.
Class variables can be accessed using either class name or object reference. Instance variables can be accessed only through object reference.
https://qph.fs.quoracdn.net/main-qimg-c4b92e80a8500c11fe705c1bafc3ed26
You don't mention the programming language at question.
Usually a class is a model or template that declares
how a certain category of objects look like.
You give a class a name and you mention if it inherits
members from another class or not.
You define also the class members.
These can be variables that hold data (object state)
and methods (class defined functions) that define
the object behaviour.
When you instantiate a class using the declared model
, you get an object, that is a concrete class instance.
This is a concrete entity, think of it as a new variable in memory,
whose data type is the class (instead of for example
integer or string data types), whose value is its state
in a defined moment in time (the state being the
combination of all of its data member variables values
at that moment). This object has to have an identity,
because it exists in memory and it is a different entity
from the other objects you can instantiate from this or
any other class. The data member variables hold specific
values for each instance. These are not shared between
instances.
Now the member methods can be shared between instances
because they have no state, so they are equal for every object.
They are called with some arguments
and they do some action that changes the object state, or
is at least tightly related with the concrete object.
But they are common to every object. The methods usually
know what concrete object they act upon by means of a special
name like 'this' or 'self', that references to 'itself'.
Objects are usually assigned to variables upon creation,
storing a reference to its identity that allows the
remaining code to manipulate them.
You use these variables to refer to the concrete object
outside the code of the classes, and use 'this' or 'self'
to refer to it from inside the classes.
Frequently you access object members qualifying with the
object name. Like in 'player.run()', or 'player.total_score'.
That is if player is a variable to which you assigned a
class Player instance. This can look like player = new Player
or player = Player().
Attributes is just another name given to data members.
Sometimes attributes and also methods can be public or private,
meaning code outside the class can use them, or only
the class code can have access.
Sometimes you see data members or attributes referred as
properties. When you access an attribute, you are accessing
a property. In some languages like Python, property can mean
something a little different but close related anyway...
Now also depending on the language things can be like described
(C++, Java) or you can have everything being treated as objects,
including the class definitions (Python).
You should also search the internet or SO about
inheritance, overriding, class diagrams, and other things class
related.
This is all no more than the ability of defining your own data types
beoynd the language builtin types.
You can think of variables as names for boxes (memory containers in a certain address) holding values. But sometimes you want to manipulate
not the values but the addresses themselves. This time you say you have
references (to addresses). Sometimes variables are just names for those
references. References are also known as pointers. But you could do math with pointers (increment, decrement, add a fixed value to...) that you usually don't do with references.

Understanding OO class definition

This is an extract from IB Computer Science Higher Level Paper 2 November 2010, Q1b
I am trying to understand what are the “roles” of: “Node” and “item” in the following class definition
<< from question >>
class Node (1)
{
public int item; (2)
public Node next: (3)
public Node(int d) (4)
{
item = d; (5)
next = null; (5)
}
public void displaynode()
{
output(Item + “ “);
}
<< end of question extract >>
The numbers in parentheses after certain lines in the class definition are my references used in the questions below.
Is the following correct?
(1) Node is the name of the class which is used when I want to create a new, single Node by issuing
Node x = new Node(5)
which results in a new Node containing the value 5, stored in (4,5).
(2,3) These are data items with the labels item and next, of type integer (2) and Node (3) respectively (I don’t understand what it means to have type Node) ????
Being public can I access and alter the contents by using following references x.item, x.Node ???
(4) This is the method Node which accepts a single, integer parameter named d.
(5) The input parameter “d “ gets put in the object variable “item”, and “next” is set to the value Null when a new Node is created.
(1) Node is the name of the class which is used when I want to create a new, single Node by issuing Node x = new Node(5) which results in a new Node containing the value 5, stored in (4,5).
This is a reasonable explanation.
(2,3) These are data items with the labels item and next, of type integer (2) and Node (3) respectively (I don’t understand what it means to have type Node) ???? Being public can I access and alter the contents by using following references x.item, x.Node ???
Please call them variables rather than "data items". item and next are instance variables, and since next is of type Node, we can say that class Node is recursively defined. This an implementation of a linked list in which each element contains an integer value and a reference to the next element.
You're correct about the meaning of public.
(4) This is the method Node which accepts a single, integer parameter named d.
It's important that you recognize that this is a constructor method which is automatically called to initialize the state of a Node when it's instantiated.
(5) The input parameter “d “ gets put in the object variable “item”, and “next” is set to the value Null when a new Node is created.
I'd rather say the value of input parameter d gets assigned to the variable item. I wouldn't call it an object variable - in some languages, ints are considered objects, in others not. In some perspectives, variables themselves are seen as primitive objects, distinct from their values. Regardless, I think it detracts from the clarity to say "object variable".
For further study, look into the following distinctions:
Variable vs value: A variable is an element that holds a value. Variables allow us to write code that operate over different values. Values can be anything - numbers, text, arrays, records, objects, functions, and more, depending on the language.
Class vs object: A class is a blueprint for a state machine, while an object is a specific instance of one. Objects have state and methods which operate on that state.
Class vs type: A class declares what goes on inside a state machine. A type declares (what is known for) a set of values. Value types are associated with the operators that can be called on those types of values. Object types declare the methods that can be called on those types of objects (but not what those methods do).
In many OOP languages and discussions, class and type are conflated. Even variable and value are commonly conflated. As a computer scientist, you should know and understand the differences.

Hierarchy in Python 3.4 [duplicate]

I know, there are no 'real' private/protected methods in Python. This approach isn't meant to hide anything; I just want to understand what Python does.
class Parent(object):
def _protected(self):
pass
def __private(self):
pass
class Child(Parent):
def foo(self):
self._protected() # This works
def bar(self):
self.__private() # This doesn't work, I get a AttributeError:
# 'Child' object has no attribute '_Child__private'
So, does this behaviour mean, that 'protected' methods will be inherited but 'private' won't at all?
Or did I miss anything?
Python has no privacy model, there are no access modifiers like in C++, C# or Java. There are no truly 'protected' or 'private' attributes.
Names with a leading double underscore and no trailing double underscore are mangled to protect them from clashes when inherited. Subclasses can define their own __private() method and these will not interfere with the same name on the parent class. Such names are considered class private; they are still accessible from outside the class but are far less likely to accidentally clash.
Mangling is done by prepending any such name with an extra underscore and the class name (regardless of how the name is used or if it exists), effectively giving them a namespace. In the Parent class, any __private identifier is replaced (at compilation time) by the name _Parent__private, while in the Child class the identifier is replaced by _Child__private, everywhere in the class definition.
The following will work:
class Child(Parent):
def foo(self):
self._protected()
def bar(self):
self._Parent__private()
See Reserved classes of identifiers in the lexical analysis documentation:
__*
Class-private names. Names in this category, when used within the context of a class definition, are re-written to use a mangled form to help avoid name clashes between “private” attributes of base and derived classes.
and the referenced documentation on names:
Private name mangling: When an identifier that textually occurs in a class definition begins with two or more underscore characters and does not end in two or more underscores, it is considered a private name of that class. Private names are transformed to a longer form before code is generated for them. The transformation inserts the class name, with leading underscores removed and a single underscore inserted, in front of the name. For example, the identifier __spam occurring in a class named Ham will be transformed to _Ham__spam. This transformation is independent of the syntactical context in which the identifier is used.
Don't use class-private names unless you specifically want to avoid having to tell developers that want to subclass your class that they can't use certain names or risk breaking your class. Outside of published frameworks and libraries, there is little use for this feature.
The PEP 8 Python Style Guide has this to say about private name mangling:
If your class is intended to be subclassed, and you have attributes
that you do not want subclasses to use, consider naming them with
double leading underscores and no trailing underscores. This invokes
Python's name mangling algorithm, where the name of the class is
mangled into the attribute name. This helps avoid attribute name
collisions should subclasses inadvertently contain attributes with the
same name.
Note 1: Note that only the simple class name is used in the mangled
name, so if a subclass chooses both the same class name and attribute
name, you can still get name collisions.
Note 2: Name mangling can make certain uses, such as debugging and
__getattr__(), less convenient. However the name mangling algorithm
is well documented and easy to perform manually.
Note 3: Not everyone likes name mangling. Try to balance the need to
avoid accidental name clashes with potential use by advanced callers.
The double __ attribute is changed to _ClassName__method_name which makes it more private than the semantic privacy implied by _method_name.
You can technically still get at it if you'd really like to, but presumably no one is going to do that, so for maintenance of code abstraction reasons, the method might as well be private at that point.
class Parent(object):
def _protected(self):
pass
def __private(self):
print("Is it really private?")
class Child(Parent):
def foo(self):
self._protected()
def bar(self):
self.__private()
c = Child()
c._Parent__private()
This has the additional upside (or some would say primary upside) of allowing a method to not collide with child class method names.
By declaring your data member private :
__private()
you simply can't access it from outside the class
Python supports a technique called name mangling.
This feature turns class member prefixed with two underscores into:
_className.memberName
if you want to access it from Child() you can use: self._Parent__private()
Also PEP8 says
Use one leading underscore only for non-public methods and instance
variables.
To avoid name clashes with subclasses, use two leading underscores to
invoke Python's name mangling rules.
Python mangles these names with the class name: if class Foo has an
attribute named __a, it cannot be accessed by Foo.__a. (An insistent
user could still gain access by calling Foo._Foo__a.) Generally,
double leading underscores should be used only to avoid name conflicts
with attributes in classes designed to be subclassed.
You should stay away from _such_methods too, by convention. I mean you should treat them as private
Although this is an old question, I encountered it and found a nice workaround.
In the case you name mangled on the parent class because you wanted to mimic a protected function, but still wanted to access the function in an easy manner on the child class.
parent_class_private_func_list = [func for func in dir(Child) if func.startswith ('_Parent__')]
for parent_private_func in parent_class_private_func_list:
setattr(self, parent_private_func.replace("_Parent__", "_Child"), getattr(self, parent_private_func))
The idea is manually replacing the parents function name into one fitting to the current namespace.
After adding this in the init function of the child class, you can call the function in an easy manner.
self.__private()
AFAIK, in the second case Python perform "name mangling", so the name of the __private method of the parent class is really:
_Parent__private
And you cannot use it in child in this form neither

Should it be possible to call an instance method of a class without creating a new object of that class?

I can do this and I don't have any issues:
class MyClass:
def introduce(self):
print("Hello, I am %s, and my name is " %(self))
MyClass.introduce(0)
MyClass().introduce()
I'm using Visual Studio and Python 3.4.1. I don't understand why this doesn't throw an error since I'm basically setting the value of this. Is this a feature and I just shouldn't be doing this? Should I be checking if self is actually an instance of MyClass?
In Python 3 when you do MyClass.introduce() introduce is not linked to any object. It's considered as a (standalone) function like any other function you would declare by itself. The fact that it is declared within a class is not relevant here. introduce is therefore called like any function: a function with one parameter.
When you do MyClass().introduce() (notice the first set of parentheses) introduce is considered as a method belonging to an object which is an instance of class MyClass hence the regular OO behavior of adding automatically the self parameter.
Note that this is different for python 2. In python 2 there is a check to verify that when called, the effective argument passed for the self parameter is indeed an object of the correct type, i.e. an instance of MyClass. If you try MyClass.introduce(0) in Python 2 you'll get: unbound method introduce() must be called with MyClass instance as first argument (got int instance instead). This check doesn't exist in Python 3 anymore because the notion of unbound method no longer exist.

OWL: Defining attributes and member objects of a class

I am totally new to the domain of semantic web and need to create an ontology.
I did a lot of research, but still didn't find a clear solution to the following problem:
Basically, I want to describe semantically, that a certain class contains certain objects and attributes. But it's not 100%ly clear to me how to do that.
Example: I want to describe the class "device". Now this class contains an object "application", and an attribute "ID".
I got as far as mapping the object "application" to an ObjectProperty "hasApplication", and the attribute mapped to a DatatypeProperty "ID". So far so good, but now how do I bind them to the class?
There were two main ways I found:
Either you include the class name as domain in the definition of a property.
Or you include the properties into the class definition via owl:Restricion/owl:onProperty.
But in my opinion, both ways do not capture accurately my semantic intention, because in the first case, I understand it as, that if ever an object uses the defined property, then this object has to be an instance of the class defined in the domain, BUT that does not necessarily mean that every instance of this class must have this property.
Similarly, in the second case, binding a property to a class via owl:Restriction/owl:onProperty, imposes that I put a restriction on this property, i.e. cardinality or range of values. But that is not my intention, I do not want to describe "This class has this property with this restriction.", but simply "This class has this property."
Hope you guys can clear things up a bit. :S
Going with your example, you have a class Device, and you have a class Application and an ObjectProperty for relating them. In OWL Manchester syntax:
Class: Device
Class: Application
ObjectProperty: hasApplication
It's a bit misleading to think about Applications in terms of 'object contained in the Device class'. Think of them rather as objects related to that class.
Now, you can make the relation between Devices and Applications globally available by setting the domain and range of your property:
ObjectProperty: hasApplication
Domain: Device
Range: Application
However, this may not quite be what you're after, since this only says that if a hasApplication relation occurs anywhere, its subject and and object can be inferred to be of type Device and Application, respectively. It does not say that all instances of Device must have a hasApplication property.
To express that all instances of Device must have a hasApplication property, you can use an OWL cardinality restriction:
Class: Device
SubClassOf: hasApplication min 1
This tells us that any instance of Device must have at least 1 hasApplication property.