Dumb question on my part, so I apologize for not being able to grasp this.
With an NSArrayController, you can send it a remove: message. If I have objects selected and send it remove:nil, those objects are removed. The docs simply describe the message argument remove:sender where sender is "Typically the object that invoked this method."
Could someone explain (or point me to an explanation) on what sender is or should be used for in this context?
Thank you
You probably do not want to use that. Every action method takes an argument sender for general purpose, even in the concrete case it makes no sense. I. e. you might have one action method for different buttons and decide reading the sender reference, what code to execute.
-remove: (NSArrayController) always removes the selected object(s), even you pass an object reference. It simply does not take care of this parameter. If you want to remove a specific object, use -removeObject:.
Related
In smalltalk, everything happens by sending messages to receiver objects. Its syntax usually follows the format receiver message, in which receiver is an object that the message is sent to. Now I cant stop wondering, what is the sender of smalltalk messages? Consider the following smalltalk statement:
aMorph color: Color yellow
I can see aMorph as the receiver of message, but what about the sender? The standard smalltalk message syntax has only receiver and the message(selecter + arguments), I cannot identify what and where the sender is. Or perhaps, a message can actually send itself?
I remember browsing through an article about reflection in pharo smalltalk in which it mentioned sender of a message, but I cant find or understand what is this 'sender'. Can anyone explain this to me about this? Thanks.
The sender is determined and set at runtime whenever a message is sent. From the perspective of the currently executing method, it answers the question 'how did we get here?' In the most common case, the sender would be whatever method sent the message that resulted in the current method being called. (one exception would be a #doesNotUnderstand: handler that redirects a message to some place other than the originally intended destination) In Squeak for example, if you doIt on aMorph color: Color yellow from a workspace, the sender will be UndefinedObject>>DoIt. If you sent the same message from MyObject>>myTestSender, the sender will be MyObject>>myTestSender.
Now let's say you wrapped aMorph in a proxy object myProxy, an instance of MyProxyObject, and its doesNotUnderstand: method forwards everything it receives to the underlying aMorph object. In this case, when you doIt myProxy color: Color yellow, the sender will be MyProxyObject>>doesNotUnderstand:. (unless your doesNotUnderstand: method further manipulates the runtime... which it can do if it needs to) This is actually a good example of when you might need to look at who the sender of #color: is: it's being invoked but you don't understand from where since the proxy adds a level of indirection that may not be obvious to you.
So in order to see who the sender is, you could add the following to the color: method:
Transcript show: thisContext sender asString.
From the perspective of your code, dealing with sender is implicit and handled for you by the Smalltalk runtime during normal code execution. Unless you're troubleshooting some code or otherwise needing to introspect or alter things at runtime, you won't often be looking at the sender.
Now this may raise the question 'what the heck is thisContext?' It's a special variable representing the top of the callstack and is something that many people have a difficult time wrapping their heads around initially. See How does Smalltalk manipulate call stack frames for more information.
Addendum (hopefully this will clear up any confusion between Leandro's answer and mine)
Leandro's answer is looking at sender as a general term and considers the larger historical context, while mine is a more contemporary Squeak/Pharo-centric one and has a very specific meaning. I agree with Leandro's point that the term sender is ambiguous and not standardized across implementations (as our different answers prove.) Just to muddy the waters even further, in the Blue Book references to sender are talking about the sending context... which is neither self nor thisContext sender. However, the links referred to in the comments on the question were explicit in their meaning (i.e. thisContext sender) as is commonly meant when referring to Squeak/Pharo code. So which answer is correct depends on whether you are looking at a specific Smalltalk implementation (in which case, the correct usage is whatever one the implementation you are using has decided on) or as a more general term when talking about no particular Smalltalk implementation (in which case Leandro is correct: it's subject to interpretation as its usage has been overloaded to near-meaninglessness)
You can think of the sender as being self. In other words, when a method is activated (i.e., during its execution), the object represented by self can be interpreted as the sender of all the messages sent in the method's body.
Consider for instance the method #paint:, defined in OurClass as
paint: aMorph
aMorph color: Color yellow
As soon as this method is executed, the (sub)instance of OurClass receiving the paint: message, will become self. Well, during this activation of the method, self could be attributed the role of the sender of color: to aMorph.
Note however, that this is just a matter of interpretation. For instance, you could also consider the process being executed and identify the sender as the process frame that activated #color:.
While both interpretations are valid, the reality is that in Smalltalk the notion of sender is irrelevant because the act of sending a message is primitive, i.e., implemented in the Virtual Machine, not in the Virtual Image.
Of course, for communication purposes it is useful to assign that role to someone and even speak about the sender. But the object implied depends on the context. For instance, when debugging, you would identify the sender with the calling frame. However, since message sends happen "magically", there is no actual need to attach the role of sender to any object.
Even in Bee Smalltalk, where you can reach the internals of the runtime because there is no VM, the notion of sender is also fussy and rather unnecessary. Technically speaking, every send in Bee has a SendSite object that performs all the steps needed to send the message (PIC, lookup, etc.) And since you can inspect these objects and send messages to them, you could speculate that in Bee the sender is the SendSite. But again, this is subject to interpretation. In fact there is no sender ivar in the SendSite class simply because the Smalltalk semantics doesn't need such a thing.
Addendum
When I say that the notion of sender is subject to interpretation what I mean is that such a notion is not used in any implementation of the send mechanism. More precisely, the (primitive) code that performs the send consists of a cached routine that performs the method lookup, which only takes into account the receiver's behavior and the selector, disregarding the "sender".
Note also that the main piece of "data" that the message send gets from the "caller" are the arguments. And if we dig deeper in the machine code realization of all of this, we could argue that the other one is the return address, which is used to link the frames. This is why I mentioned the notion of "sender" as referred to the caller process frame, which is meaningful for its reification in the implementation of the debugger.
My point is that in Smalltalk there is no clear definition of sender and that's why it is so hard to identify it when compared to relevant notions such as receiver, selector, arguments, behavior and method send.
It is true that you can use the pseudo variable thisContext to get the sender of the current activation. If you do this, you will get the object that impersonated self in the calling frame, which is the other interpretation of sender. And even though by having a reference to that object you could make use of it to provide more features, the sender will remain absent from the Message object and the message send machinery.
If you are interested in how Smalltalk works look at #blihp's and #leandro-caniglia's answers. Also Deep Into Pharo (14.5 Contexts: representing method execution) has information on Context (named MethodContext until Pharo 3).
If you want to experiment with it, at least in Pharo, the pseudo-variable thisContext gives access to the current execution point. You can put:
thisContext copy inspect.
in your method to see what information you can get about a specific execution point. This information includes the sender.
But if you were wondering if you should, on a regular basis, access the sender of a message in your methods, the answer is no. If you need to know the object sending a message in a regular method, pass the sender (self) along as an additional parameter.
You have identified aMorph as the receiver of a message.
Now, what does aMorph do?
It sends messages to various things.
When aMorph is responding to the message it reveived,
It is the sender. It was the receiver, it becomes the sender.
When aMorph is done, it stops being sender, and gives an answer to whatever sent it the message it was working on.
Of course everytime aMorph sends a message, the receiver gets to be the sender while it works out an answer.
And so on.
Below in the message anObject bar is explicit that whoever sent the message was SomeClass instance. But within the method that responds to the message you must resort to the services of thisContext.
SomeClass>>foo
| anObject |
anObject := AnotherClass new.
anObject bar
AnotherClass>>bar
| context senderObject receiver |
context := thisContext.
senderObject := context sender receiver.
receiver := self
I am a newbie so the question might sound silly. But how could I know the sender of a method in Objective-C? In some situations like Target/Action, sender is obvious (a UIControl object). But what about viewDidLoad?
While receiver of an method is usually obvious, sender is not so. For example, I have to read the documentation to know that dealloc's sender is runtime and runtime only. Is there a way to know the sender of a method more easily?
If you aren't passed information from caller then it's not important; this stands for all programming languages; a method is provided with the data/object to work on and it doesn't matter what called the method. This makes the method more useful.
You don't say why it's important to know who the sender is; if it's just curiosity then you can set a breakpoint and examine the stacktrace in the debugger.
I've been using addObserver:forKeyPath:options:context: quite a bit in my code, and have always been setting the "context" part of it to nil. I see plenty of examples where people have used the "context", but have a hard time grasping exactly why. Is it helpful if you have more than one object observing the key, and want to figure out which object should respond when the key changes? If so, is that the only reason?
thanks
The biggest reason to have a unique context is to deal with the situation where a subclass (or superclass) is also observing the same keyPath. If you know that this observation is yours, you can return out of the observer. However, if it belongs to somebody else, you should pass it along to the superclass (if there is any), which might be expecting it.
In the event of another object observing the keyPath, you won't receive the observation message for that object. However, in the case of subclassing, you need to pass on the observation to the superclass, which is where this becomes important.
Another place where I've found it useful is when you need to observe a value change in multiple values and have the identical reaction to them (such as setNeedsDisplay: on some view). In this case, you can give them all the same context, and you only have to check the context, instead of each keyPath.
It's the first i post to stackoverflow although i always check the forum.
I am looking for a conveniant way to know who sent a message in ObjC without sending the pointer as an argument in the method.
Can anyone help?
Thanks in advance!
This is not possible in the general case (messages can be set from places where there is no self, such as the runtime or the main function), and it's impractical even where it might be technically possible, because it would require you to walk the stack and analyze the bytes there.
In practice, you shouldn't need to know the sender in most cases other than action methods. It's normally a sign of a bad design. And in any case, when you need to get a reference to another object, it should be passed as an argument to a method.
EDIT: I just stumbled on this and noticed the comment. In case anyone is wondering, the reason it's often a sign of bad design is because it creates a tight coupling between components that is almost never necessary (again, outside of action methods). Usually you can take either a delegate or a callback block to accomplish the same purpose.
No, this isn't possible without passing in a pointer to the sender of the message, like this:
- (void) someMethod:(id) sender {
}
[obj someMethod:self];
I guess you could use the hash value of the underlying NSObject (if the object is a subclass of NSObject). As an NSUInteger it's going to be the same size as the pointer, though, so not much space savings there.
Why exactly do you not want to use a pointer?
I have an object that I'm passing in a method call. Say I'm using a language that only allows you to pass objects by reference, like Java or PHP. If the method makes changes to the object, it will affect the caller. I don't want this to happen. So it seems like I need to make a copy of the object.
My question is: whose responsibility is it to clone the object? The caller, before it calls the method? Or the callee, before it changes the object?
EDIT: Just to clarify, I want this to be part of the contract of this method -- that it never modifies the original object. So it seems like it should be up to the method to make the copy. But then the caller has no protection from a method that doesn't do this properly. I guess that's acceptable -- the only other alternative seems to be to have this built into the language.
Generally, the caller should make the copy if it is concerned about changes. If the caller doesn't care, the method should make the copy if it needs to do something that it knows shouldn't persist.
So you want to do something like
MyObject m = new MyObject();
MyObject n = MyObjectProcessor.process(m);?
It seems simpler to me to do something like
MyObject n = MyObjectProcessor.alter(m.clone());
where it's clear who's doing what to who. You could make the argument that the processor class function should be free of side effects, i.e. it should return a new object any time it's going to change state, but (AFAIK) that's not so consistently followed in OO as opposed to functional programming.
Something like the above is probably harmless, as long as it's clearly named and documented.
We could look at ruby for guidance. They use a ! symbol to indicate that an object is modified in-place. So, salary.add(10000) returns a new object but salary.add!(10000) returns the original object but modified. You could use the same idea in Java or PHP by using a local naming convention.
The caller. Because, sometimes you want to make changes to the objects themselves and other times to a copy.
Although, I consider it a bad practice for callee to modify passed objects (at least in object oriented languages). This can cause many unwanted side effects.
(after your) EDIT: In that case it is callee's responsibility to enforce the contract, so there are two options:
The callee simply does not modify the object
or the callee copies the object and works with the copy afterwards
Depends, is there any reason that the method could be called in the future where you want the change to be seen by the caller? If so then the caller should make the copy. Otherwise the callee should make it. I would say that the second case is probably more common.
If you have the caller clone the object, it gives you the flexibility to not use a copy (by not cloning it first), and also means you don't have to return a new object, you can just operate on the reference passed in.
My first reaction would be that it is the caller's responsibility, but I think it actually depends.
It depends on the contract defined between the two methods. The method that is making changes should explicitly identify that fact and let the caller make the decision. OR, The method that is making the changes should explicitly identify that it will NOT make any changes to the passed object and then it would be responsible for making the copy.
I would say the callee: it simplifies calls and caller won't have to worry for the integrity of the given objects. It is the responsibility of the callee to preserve the integrity.
I assume you would have something like const declaration. This would be compiler enforced and would be more efficient than creating copies of your objects.
I think the caller should make the clone, just to make the naming easier. You can name your method Foo() instead of CloneBarAndFooClone().
Compare:
void RemoveZeroDollarPayments(Order order)
vs.
Order CloneOrderAndRemoveZeroDollarPaymentsFromClone(Order order)
If not changing the object is part of the method contract, the only possibility is having the copy made inside the method. Otherwise you are lying to your client.
The fact that you actually need to modify an object exactly like the one given to you is just an implementation detail that should not put a burden on the caller. In fact, he does not even need to have visibility of that.