-
Notifications
You must be signed in to change notification settings - Fork 460
[Question] Is it possible to do some kind of block argument overloading? (oslt) #69
Comments
You could use a variable argument list ( |
This is true, but for that I need at least one named argument. Which I cannot afford given the way things are now :) |
From what I read about the blocks implementation, I understood that behind the scenes, the block descriptor itself is the named argument passed to the invocation function. Perhaps this could be a starting point, but simple |
You'd probably have to get deep within libffi to find something that can help if you really don't want any named arguments. I'm afraid I don't know much more than that. |
It looks like I got something working :)
Surprisingly, this seems to work fine! I wonder how valid it is :D |
you can't return a block that takes an "id" as parameter |
|
the above has a segfault error |
@liuyaouestc That's true. The above approach assumes you know the correct argument type before the call. |
Hey Justin! I don't know if this is the right place, but I really would like to ask you about one tricky feature I'm struggling with :)
Is it possible to somehow have a block which would accept an argument of different types without complaining? The argument could be
id
, but might as well bedouble
or evenstruct
(e.g.,CGPoint
).A solution I'm currently using is a macro-based one. I use a macro to wrap scalar/struct arguments in
NSValue
, using their encoded types, and then retrieve them back. However, this has a drawback of littering global namespace with defines, which may be undesired.One thing I noticed is that you may do like this:
Perhaps there's a way to retrieve these passed arguments inside the block? We could assume that we actually know which type we are currently expecting.
Maybe there's another clever approach I'm missing? I know you are an expert on all kinds of crazy things, so perhaps you could give me a clue :) Thanks a lot!
The text was updated successfully, but these errors were encountered: