Does the Scala Option type incur an overhead of two objects per primitive type value? In other words, is the Option type specialized for primitives, or does it always double-box them (I'm counting Some(...) as a box)?
I need a map-like mutable data structure in Scala that is covariant in it's value type parameter. This is impossible to implement in Scala because mutable data structures are invariant in their type parameters. I understand the rationale for that decision, however, since that data structure will not be publicly exposed I need some "unsafe" variant of this data structure. How would you implement an alternative for this in Scala?
As i read through UML specification that:
class has a set of attributes/operations
and data type has a set of attributes/operations
1)with regards to attributes/operations of data type
what this means?
because i don't know how such a data type has attributes and operations?
2)What’s the main difference between a class and a datatype?
according to UML 2.4.1 specification
A data type is a special kind of classifier, similar to a class. It
differs from a class in that instances of a data type are identified
only by their value. All copies of an instance of a data type and any
instances of that data type with the same value are considered to be
equal instances. Instances of a data type that have attributes (i.e.,
is a structured data type) are considered to be equal if the structure
is the same and the values of the corresponding attributes are equal.
If a data type has attributes, then instances of that data type will
contain attribute values matching the attributes.
1)Attributes/operations of data type have the same meaning than attributes/operations of classes i.e. attributes represent the structure of your data type and operations represent the method available on your data type.
2)The main difference between a class and a datatype is that it is not possible to have two instances of a datatype with the same values (these instance would be one unique instance).
Hoping it helps,
RB
In the Object Oriented
(OO)
approach
,
systems
,
including software
,
are
made up of numerous
objects
that work
together by exchanging information in
the form of data values and ‘messages’
. An object is a specific instance of a
Class
like your dog (an object) is specific instance of the class of all dogs.
Classes define what an object is like, and
objects are practical instances that can be used and manipulated.
As a definition, a class defines what properties will
be used to describe every object based on this class. Within the object each of these properties will have a value that
contributes to its description. Two objects of the same class will have the same properties, but they will have at least
one property that
has a different value in each of the objects
–
if all the properties have the same values in both of the
two objects then they are the same object.
A data type refers to the attributes of an object and what type of data each attribute is, such as string, boolean, integer etc.
Operations or methods is what an object can do such as for a dog:
growl();
bark();
fetch();
etc.
Have a look at this explanation of a Class Diagram, it will make more sense.
This question has been asked on here a few times, but none of the replies really answered it in the more abstract, theoretical sense that I am looking for.
Most answers are something along the lines of "A class has implementations for methods that its objects can respond to, while a type just specifies which methods can be responded to".
Well, this seems kind of like an odd definition to me. Take ints, floats, and chars in a language like C. It may never be explicitly located in the code, but there are definitely methods built in to the language for responding to the messages ("plus", "minus", etc.) that these types receive.
And as all interfaces must have methods defined somewhere, it seems to me that types are the same thing as classes, except the word "class" carries a mental image of a more substantial programming structure than a "type".
Which leads to me to believe that the drawbacks that apply to any class-based language (the "expression problem" for example) would similarly apply to any language with types (Haskell, etc.)
There is no widely applicable, generally accepted definition of the term "class" that I'm aware of, not even wrt type systems. So your question pretty much depends on the context.
If you are talking about classes in object-oriented languages then the description you quote is relatively accurate. Types are specifications, descriptions (of objects or other values). Classes are implementations, definitions (of object factories).
However, in many OO languages, class definitions also introduce distinct type names, and these type names are often the only means to type objects. That's an unfortunate limitation and conflation of concepts, that also leads to the well-known confusion of subtyping and inheritance. At least some languages separate these concepts properly, e.g. Ocaml.
In any case, the reason why the distinction is seemingly at odds with ints and floats in C is simple: those are not objects. Despite what OO ideology tries to preach, not everything is an object, and certainly not in every language.
Simply put, a class will often have methods that manipulate the data contained within an instance. A type will not; it only is meant to hold and return data.
Although it is true that there may be methods specified somewhere for the type, there will only be one way to change the data contained within an instance of a type - storing a new value in it. The methods are generally along the lines of presenting the data in different ways, instead of actually manipulating the data.
This rule can, of course, be broken; C is full of examples, due to how it is structured (or, rather, not structured). Generally speaking, though, you don't want to have a type with a function that does fancy logic internally.
"Class" and "type" mean different things in different languages and environments; I will try to show here a synthesis that helps me think about the issue.
Classes have objects, and types have values. I think it is easier to understand the difference between objects and values, than between classes and types. An object has 2 independent properties: its identity, and its state/behaviour. So, you can have two different objects with the same class and state. This is not true for values: you cannot have 2 different values of a type that have the exact same state (or form, shape) and behaviour: you cannot have 2 "twoes". A value of a type does not have an identity independent of its state and behaviour.
Mixing both concepts together, you might say that a value of a given type does not necessarily have a class, but an object of a given class necessarily has a type, (e.g. object), and its value is given both by its state/beheviour and by its identity.
Haskell has types, and definable ones if I am correct. It is from Haskell that I am taking the "type" concept I am using. Python has classes and types mixed into the same "type" system, with some primitive types and rich definable classes. The concept of object that I am using is that of the type system of Python, minus its primitive types: int, str, etc.
Another key difference between types and classes would be in their definition. Types are tipically defined by a set of predicates or constraints that "give" all at once all of the values of the type. Therefore, you can use a literal value without first having to "create" it: 23438573. The definition of a class involves a procedure to create objects, and all objects of that class must be created before they are used.
How can I refer to ArrayBuffer and Vector in a more generic way?
For example - one of my functions takes a Vector as an argument, while another returns an ArrayBuffer.
What is a common "iterface" that I can use?
For example, in Java I could use List or Collection interface to pass them around.
See here for an overview of the inheritance relationship between the collections classes.
You'll see that IndexedSeq is a common trait for both ArrayBuffer and Vector.
EDIT: IndexedSeq vs. Seq:
From the doc: Indexed sequences do not add any new methods wrt Seq, but promise efficient implementations of random access patterns. This means that, in this context, you could just as well use Seq, as the implementations will be provided by ArrayBuffer and Vector in any case.
I would use SeqLike or more generic TraversableOnce which would also apply for Maps.