I should preface this with saying I come from a Java/Android background which has colored my understanding of the word "member". That said, I'm starting to learn Objective-C and I ran across the isMemberOfClass method and the name confuses me.
I understand that isMemberOfClass returns a Boolean value that indicates whether the receiver is an instance of a given class. However, I don't understand why it is called isMEMBER when it checks if it is an INSTANCE.
Is there something about the language protocol that I don't know that would make sense to name it this? Does member mean something different in Objective-C than it does in Java?
The way I understand the definition of member, it is something a class HAS (method or data), rather than something a class IS (a type).
Can anyone clear this seemingly odd naming convention up for me? Thanks for helping a newbie!
The key note here is that Cocoa (and SmallTalk before it), does not use the word "member" to mean "instance variable" or "function of" or any of the other ways that the word "member" is used in Java or C++. There's a useful paper on SmallTalk from Harry H. Porter III that gives some context:
As mentioned earlier, each object contains zero or more fields. The term "field" is preferable, but other languages use the term "data member" for the same concept. Smalltalk uses the term "instance variable" to mean a field, so we say, "An object contains several instance variables" to mean the same thing as "An object contains several fields" or "An object contains several data members." We will use the terms "field" and "instance variable" interchangeably.
...
In Java or C++, the programmer may add "static data members" and "static member functions" to any class. Smalltalk has a similar ability, although static data members are called "class variables" and static member functions are called "class methods". (Recall that Smalltalk calls normal fields "instance variables" and it calls normal member functions "instance methods".)
In Cocoa, the term "member" is typically used in the context of a collection (see [NSSet member:]). The question being asked by isMemberOfClass: is "is this object a member of the set of all instances of this specific class."
That's not to say isInstanceOfClass: would have been an un-Cocoa-like name. It's just that "member" doesn't have the same meaning here as in some other languages.
The concept of a member as a component of a class (method or data) does not exist in the iOS framework. The framework is also built around verbose and often lengthly method or variable names to promote "added readability" (in quotes because it isn't always necessarily the result).
It easily could be named isInstanceOfClass, but that may have caused some confusion with subclasses. isMemberOfClass just happens to be a simple method name that doesn't collide with any principles of the iOS framework and is quite self explanatory. I don't think the logic extends beyond that.
I believe the term "member" used to denote either an instance variable or a method (sorry, member function) goes back to C++. I personally have never heard it used with Java, but my hearing may not be the best.
Objective-C is pretty much everything C++ is not - and vice versa. Objective-C is historically based on smalltalk and inherits most of that environment's way of doing things. Alan Kay, one of the "inventors" of Smalltalk is quoted as saying "I invented Object-Oriented Programming, and C++ is not what I had in mind", just to illustrate the feelings between the two camps.
So to answer your question: Yes, "member" has a different meaning in Objective-C and C++, and don't be too surprised if you find other words with different meanings as you get deeper into Objective-C.
Related
I am studying C++ from different sources and I find confusing that sometimes I encounter the term "Non-static member" and sometimes the term "Instance Variable".
For me, they can be used interchangeably as they both refer to members of a class that are different for each instance, and can be only accessed through an instance
I would like to know if these two terms are really synonyms or I am missing something.
"Members" are not just fields/properties of your class, but also the methods in your class. See Working Draft, Standard for Programming
Language C++ - 9.2 Class members:
Members of a class are data members, member functions (9.3), nested types, and
enumerators.
"Instance variables", in most cases the term is used, is used to describe the non static "data members" of a class. So, to answer your question: "Instance variables" are a subset of "non-static members".
This might no be particularity a language related question. Since the Swift is the language I'm currently learning so I'm using it here.
I picked up this sentence from the Matt Neuburg's book iOS 10 Programming fundamentals with Swift
In Swift, "everything is an object" and an object
Object is something you can send a message to.
Let's add an example. Suppose there is a customer type called Dog. It has bark() and sit() function. Two instances of the type Dog named fido and rover had been initiated.
In swift, the syntax of message-sending is dot-notating, like
fido.bark()
rover.sit()
rover.printName()
The above code lines means sending message to object fido and rover
Question 1:
Why the description is: Sending message to object fido and rover? To me it looks like the object fido and rover sends out some message to print it out in the console (ex. printName() ) rather we sending message to it. .bark() looks like it will make fido to do something and shoot its reaction to the outer world, because bark() is the function inside its belly, not something we created and inject in to its body. we just inform this function its the time to work. Is this informing object to do a specific thing is the meaning of sending the message to the object?
Question 2:
"In Swift, everything is an object", an object is something you can send message to
If I understand correctly, even the object type itself is also an object. such as String, Int or Double. Because type has type properties which means you could send a message to it
Thanks a lot for your time
There is some debate within the OOP world about "message passing" versus "method calling," both in how we talk about them, and how they're implemented. In the prototypical OOP language (SmallTalk, which ObjC is a descendent of), everything really is a "message." I bundle up a message (which is a real data structure, NSInvocation in its most heavyweight form in Cocoa), and deliver it to the object's inbox, which then processes the message and performs some action.
Most common OOP languages didn't adapt this model (when something does today, we tend to call it "actor" rather than "object"). C++, which heavily inspired most of the current crop of "object-oriented" languages took a "method calling" approach. This is much more closely aligned with function calling, and has to do with jumping to a specific point in memory and executing instructions there. Method calling is more static than message passing. It is much easier at runtime to completely reconfigure how messages are handled, create new message handlers, re-route old message handlers, etc. Method calling is much faster.
In practice, there isn't a huge difference in most programs at most call sites. The vast majority of ObjC "messages" translate precisely 1:1 into a method call, and the system almost always avoids generating a full NSInvocation message (they're insanely expensive).
But we still conceptually mix the two ideas when we teach OOP, and that's what's happening here. (Swift also happens to employ both mechanisms heavily.)
A good way to think of fido.bark() is "send the bark message, with no parameters to fido." It is then up to Fido to decide what to do about that. In practice, messages are usually understood to be "commands" in that the object doesn't "decide" what to do. But in principle it might. For example, Fido might be a pretty smart dog, and decide not to bark because it's so late at night, even though you told him to, or maybe he's asleep and he doesn't like to bark then. The concept of objects is that they encapsulate that knowledge and state.
To your second question, in Swift types are not full objects. They're "metaobjects." You are absolutely right that you can send messages to them, and so they in some ways behave like objects. But Swift doesn't have "first class types," which means that not everything you can do with an object can be done with a type. But yes, you're definitely on the right road that in many cases you can treat a type as if it were an object.
(A major Swift feature request is to make types more first-class by adding a concept called Higher Kinded types. This would make it possible to write methods on Array itself, rather than only on Array<T>, and make some types, like Functor, possible to write at all.)
I was also reading a book < iOS 9 Programming Fundamentals with Swift >, there are some interesting aspects of looking at 'everything is object in swift'.
"In Swift, everything is an object", an object is something you can send message to
In swift, we can add extension for String, Int, Double...etc
for example.
extension Int {
func sayHello() {
print("Hello, I'm \(self)")
}
}
1.sayHello() // outputs: "Hello, I'm 1"
The 1 here is not a class or instance, it is a struct. Swift has three kinds of object type: classes, structs, and enums.
I'm trying to learn/understand Rx, specifically RxJS, and keep seeing references to IObservable, IObserver, etc.
Can anyone tell me what the leading I means and/or where it comes from?
From my searching, it looks like the <T> is for the type. If this is wrong or naive, I'd appreciate some clarification on this as well.
Thanks!
In ye olden days of MFC for C++, Microsoft had Hungarian notation down to a very irritating artform, where all concrete classes were prefixed with C and their COM interfaces with I, this does help avoid the conflict where a COM interface and class might share the same name and so muddy your project.
Part of this notation carried over into .NET, except only interfaces kept the I prefix, but classes and other types dropped their Cs. This does make non-interface-heavy code easier to look at, but can cause ambiguity if you begin a class name with a 2-letter acronym beginning with I (as two-letter acronyms must be completely capitalised according to the the .NET style guidelines), but this is rare.
(I note that generic type name placeholders are prefixed with T too, e.g. TKey and TValue in Dictionary).
An example of why this is necessary is when dealing with collections in .NET, if you're building a reusable library and don't want to expose implementation details (e.g. if you use List<T> or T[] as an underlying collection field type), you can use IList<T> or IReadOnlyList<T> which are interfaces. If the interface was simply called List<T> it would conflict with the actual type List<T>, and ReadOnlyList<T> (an interface) might get confused with ReadOnlyCollection<T> (a class).
You might argue that this wouldn't be a problem if classes and interfaces had a different namespace. C does this: struct types and scalars exist in different namespaces, which unfortunately means that every time a struct type name is used, its usage must be prefixed with struct (e.g. a declaration: struct Foo foo). People workaround this by using typedef with anonymous structs, but I feel the end-result is messy (and the Linux kernel coding guidelines prohibit this too).
In Java, however, interfaces are not prefixed with I but instead have class-like names. Whether this is "correct" or "better" is entirely up for debate. C++ does not have interface types, just pure-abstract classes and multiple-inheritance, so the I prefix isn't typically seen at all outside of COM.
I don't really know if any common terms exist for what I'm asking about, so I apologize for possible stupid misuse of the terms.
I'm interested, if there are any solutions or at least experiments for creating "pure logic" code, abstract of any architectural patterns, and later generation of architecture-specific code based on it.
For example:
"pure logic" is addition of two integers — a and b
it can be dumped as inline "= a + b"
or as a function "function sum(a,b){return a+b}; =sum(a,b)"
or as a class "class Sum(a, b){...}; s = new Sum(a,b); =s.result();
or maybe this class has no constructor arguments but requires applying them after construction
or it accepts a dictionary with dozen possible keys including 2 we need
or maybe we have DI/IoC container and we call lazy-loaded singleton serevice with 2 injected arguments
and so on
So, basically, it's like we have a mix of global functions and variables, and then we apply generation rules and templates to get a specific coder-friendly result.
Basically, you cannot escape having to define some syntax, and giving it semantics. And that gives you a language. In this language you have types (integers) and an operation (you can add them).
So now this business of generating code is basically your compiler for the language, which uses various high level languages as the back end.
Since some of the languages are perhaps not as "pure" as your high level language, or are semantically distant in various ways, the generated code in some of the back-end dialects might end up looking like dog's breakfast in order to precisely implement the semantics.
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.