Usage of autorelease pool in objectAtindex swizzling for NSMutableArray
- (nullable id)myObjectAtIndex:(NSUInteger)index{
@autoreleasepool {
id value = nil;
if (index < self.count)
{
value = [self myObjectAtIndex:index];
}
return value;
}
}
I have no idea about the purpose of using autoreleasepool here. Can someone give me a hand?
objective-c nsmutablearray swizzling
add a comment |
- (nullable id)myObjectAtIndex:(NSUInteger)index{
@autoreleasepool {
id value = nil;
if (index < self.count)
{
value = [self myObjectAtIndex:index];
}
return value;
}
}
I have no idea about the purpose of using autoreleasepool here. Can someone give me a hand?
objective-c nsmutablearray swizzling
Swizzling a Foundation method that is frequently? That code, right there, would be enough for me to suspect that the entire codebase is complete and utter trash that really really needs to be rewritten.
– bbum
Nov 13 '18 at 20:01
add a comment |
- (nullable id)myObjectAtIndex:(NSUInteger)index{
@autoreleasepool {
id value = nil;
if (index < self.count)
{
value = [self myObjectAtIndex:index];
}
return value;
}
}
I have no idea about the purpose of using autoreleasepool here. Can someone give me a hand?
objective-c nsmutablearray swizzling
- (nullable id)myObjectAtIndex:(NSUInteger)index{
@autoreleasepool {
id value = nil;
if (index < self.count)
{
value = [self myObjectAtIndex:index];
}
return value;
}
}
I have no idea about the purpose of using autoreleasepool here. Can someone give me a hand?
objective-c nsmutablearray swizzling
objective-c nsmutablearray swizzling
edited Nov 13 '18 at 11:51
cool_jb
345
345
asked Nov 13 '18 at 5:51
霍John霍John
1
1
Swizzling a Foundation method that is frequently? That code, right there, would be enough for me to suspect that the entire codebase is complete and utter trash that really really needs to be rewritten.
– bbum
Nov 13 '18 at 20:01
add a comment |
Swizzling a Foundation method that is frequently? That code, right there, would be enough for me to suspect that the entire codebase is complete and utter trash that really really needs to be rewritten.
– bbum
Nov 13 '18 at 20:01
Swizzling a Foundation method that is frequently? That code, right there, would be enough for me to suspect that the entire codebase is complete and utter trash that really really needs to be rewritten.
– bbum
Nov 13 '18 at 20:01
Swizzling a Foundation method that is frequently? That code, right there, would be enough for me to suspect that the entire codebase is complete and utter trash that really really needs to be rewritten.
– bbum
Nov 13 '18 at 20:01
add a comment |
2 Answers
2
active
oldest
votes
There is no scientific reason.
The whole code is an example of "this app crashes and I do not know why" panic code:
Obviously the author had a problem with guaranteeing correct indexes, what would be the correct approach. Therefore he wrote a special method to "repair" it. The naming ("my") shows, that he thought: I can do it better (instead of insuring correct indexes).
Moreover, adding an ARP to a piece of code, that obviously does not create an bigger amount of objects, is a sure sign for the fact, that he couldn't oversee his code anymore.
Move the whole code to /dev/null.
A little harsh maybe. If you index a dictionary with a non-existent key you getnil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)
– CRD
Nov 13 '18 at 21:10
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
add a comment |
Unless I'm missing the obvious, which is always possible, we can only guess:
There is a stack of autorelease pools, the top of the stack being the one in use. When the @autoreleasepool { ... }
construct is entered a new pool is created and pushed on the stack, on exit from the construct the pool is drained and popped off the stack.
The reason to create local pools is given in the NSAutoReleasePool
docs (emphasis added):
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
So what is the purpose in the code you are looking at? Some guesses:
Either the original author knows/believes that the called methods
count
andobjectAtIndex
(post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; orThe original author was/is planning to add future code to
myObjectAtIndex
which will add a significant amount of objects to the autorelease pool and wishes to clean these up; orWishes to be able to call
objectAtIndex
and ensure there is no impact on the memory used for live objects (e.g. maybe they were measuring memory use by something else); orWho knows, accept the original author (hopefully!)
HTH
1
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53274623%2fusage-of-autorelease-pool-in-objectatindex-swizzling-for-nsmutablearray%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is no scientific reason.
The whole code is an example of "this app crashes and I do not know why" panic code:
Obviously the author had a problem with guaranteeing correct indexes, what would be the correct approach. Therefore he wrote a special method to "repair" it. The naming ("my") shows, that he thought: I can do it better (instead of insuring correct indexes).
Moreover, adding an ARP to a piece of code, that obviously does not create an bigger amount of objects, is a sure sign for the fact, that he couldn't oversee his code anymore.
Move the whole code to /dev/null.
A little harsh maybe. If you index a dictionary with a non-existent key you getnil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)
– CRD
Nov 13 '18 at 21:10
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
add a comment |
There is no scientific reason.
The whole code is an example of "this app crashes and I do not know why" panic code:
Obviously the author had a problem with guaranteeing correct indexes, what would be the correct approach. Therefore he wrote a special method to "repair" it. The naming ("my") shows, that he thought: I can do it better (instead of insuring correct indexes).
Moreover, adding an ARP to a piece of code, that obviously does not create an bigger amount of objects, is a sure sign for the fact, that he couldn't oversee his code anymore.
Move the whole code to /dev/null.
A little harsh maybe. If you index a dictionary with a non-existent key you getnil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)
– CRD
Nov 13 '18 at 21:10
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
add a comment |
There is no scientific reason.
The whole code is an example of "this app crashes and I do not know why" panic code:
Obviously the author had a problem with guaranteeing correct indexes, what would be the correct approach. Therefore he wrote a special method to "repair" it. The naming ("my") shows, that he thought: I can do it better (instead of insuring correct indexes).
Moreover, adding an ARP to a piece of code, that obviously does not create an bigger amount of objects, is a sure sign for the fact, that he couldn't oversee his code anymore.
Move the whole code to /dev/null.
There is no scientific reason.
The whole code is an example of "this app crashes and I do not know why" panic code:
Obviously the author had a problem with guaranteeing correct indexes, what would be the correct approach. Therefore he wrote a special method to "repair" it. The naming ("my") shows, that he thought: I can do it better (instead of insuring correct indexes).
Moreover, adding an ARP to a piece of code, that obviously does not create an bigger amount of objects, is a sure sign for the fact, that he couldn't oversee his code anymore.
Move the whole code to /dev/null.
answered Nov 13 '18 at 12:25
Amin Negm-AwadAmin Negm-Awad
14.8k32646
14.8k32646
A little harsh maybe. If you index a dictionary with a non-existent key you getnil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)
– CRD
Nov 13 '18 at 21:10
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
add a comment |
A little harsh maybe. If you index a dictionary with a non-existent key you getnil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)
– CRD
Nov 13 '18 at 21:10
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
A little harsh maybe. If you index a dictionary with a non-existent key you get
nil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)– CRD
Nov 13 '18 at 21:10
A little harsh maybe. If you index a dictionary with a non-existent key you get
nil
back, if you index an array with a non-existent index you get an error – which isn't exactly consistent. The code as it stands fixes that inconsistency, so maybe the author just favours consistency more than you do. (That doesn't explain the autorelease pool, but that is a different issue.)– CRD
Nov 13 '18 at 21:10
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
Is this about consistency. You can expect consistency if you have similar cases two times. An index is a closed range. An array is for indexed access. If you choose to use an array, you choose to take care of the index. A dictionary has no closed range of values. That's for. If you choose a dictionary, you do not choose a closed range and have to deal with it on access level.
– Amin Negm-Awad
Nov 14 '18 at 4:32
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
I did not say, that the key-range is fixed for arrays. I said, that it is closed, therefore a simple number describes all valid keys. This is not true for dictionaries. This is the difference I talked about.
– Amin Negm-Awad
Nov 14 '18 at 8:36
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
No, the words finite and infinite does not appear in my comments.
– Amin Negm-Awad
Nov 14 '18 at 11:10
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
Cleaned up the uninteresting and hence pointless thread. Consistency can clearly be in the mind of the beholder, in this case how they view the domains of two forms of discrete functions. I'll still give the original programmer the benefit of the doubt.
– CRD
Nov 15 '18 at 4:15
add a comment |
Unless I'm missing the obvious, which is always possible, we can only guess:
There is a stack of autorelease pools, the top of the stack being the one in use. When the @autoreleasepool { ... }
construct is entered a new pool is created and pushed on the stack, on exit from the construct the pool is drained and popped off the stack.
The reason to create local pools is given in the NSAutoReleasePool
docs (emphasis added):
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
So what is the purpose in the code you are looking at? Some guesses:
Either the original author knows/believes that the called methods
count
andobjectAtIndex
(post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; orThe original author was/is planning to add future code to
myObjectAtIndex
which will add a significant amount of objects to the autorelease pool and wishes to clean these up; orWishes to be able to call
objectAtIndex
and ensure there is no impact on the memory used for live objects (e.g. maybe they were measuring memory use by something else); orWho knows, accept the original author (hopefully!)
HTH
1
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
add a comment |
Unless I'm missing the obvious, which is always possible, we can only guess:
There is a stack of autorelease pools, the top of the stack being the one in use. When the @autoreleasepool { ... }
construct is entered a new pool is created and pushed on the stack, on exit from the construct the pool is drained and popped off the stack.
The reason to create local pools is given in the NSAutoReleasePool
docs (emphasis added):
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
So what is the purpose in the code you are looking at? Some guesses:
Either the original author knows/believes that the called methods
count
andobjectAtIndex
(post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; orThe original author was/is planning to add future code to
myObjectAtIndex
which will add a significant amount of objects to the autorelease pool and wishes to clean these up; orWishes to be able to call
objectAtIndex
and ensure there is no impact on the memory used for live objects (e.g. maybe they were measuring memory use by something else); orWho knows, accept the original author (hopefully!)
HTH
1
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
add a comment |
Unless I'm missing the obvious, which is always possible, we can only guess:
There is a stack of autorelease pools, the top of the stack being the one in use. When the @autoreleasepool { ... }
construct is entered a new pool is created and pushed on the stack, on exit from the construct the pool is drained and popped off the stack.
The reason to create local pools is given in the NSAutoReleasePool
docs (emphasis added):
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
So what is the purpose in the code you are looking at? Some guesses:
Either the original author knows/believes that the called methods
count
andobjectAtIndex
(post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; orThe original author was/is planning to add future code to
myObjectAtIndex
which will add a significant amount of objects to the autorelease pool and wishes to clean these up; orWishes to be able to call
objectAtIndex
and ensure there is no impact on the memory used for live objects (e.g. maybe they were measuring memory use by something else); orWho knows, accept the original author (hopefully!)
HTH
Unless I'm missing the obvious, which is always possible, we can only guess:
There is a stack of autorelease pools, the top of the stack being the one in use. When the @autoreleasepool { ... }
construct is entered a new pool is created and pushed on the stack, on exit from the construct the pool is drained and popped off the stack.
The reason to create local pools is given in the NSAutoReleasePool
docs (emphasis added):
The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects generated while processing an event. If you use the Application Kit, you therefore typically don’t have to create your own pools. If your application creates a lot of temporary autoreleased objects within the event loop, however, it may be beneficial to create “local” autorelease pools to help to minimize the peak memory footprint.
So what is the purpose in the code you are looking at? Some guesses:
Either the original author knows/believes that the called methods
count
andobjectAtIndex
(post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; orThe original author was/is planning to add future code to
myObjectAtIndex
which will add a significant amount of objects to the autorelease pool and wishes to clean these up; orWishes to be able to call
objectAtIndex
and ensure there is no impact on the memory used for live objects (e.g. maybe they were measuring memory use by something else); orWho knows, accept the original author (hopefully!)
HTH
edited Nov 13 '18 at 14:21
answered Nov 13 '18 at 6:58
CRDCRD
44.8k44870
44.8k44870
1
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
add a comment |
1
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
1
1
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
Who knows, accept the original author (hopefully!) I would make a bet, that he didn't.
– Amin Negm-Awad
Nov 13 '18 at 12:29
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53274623%2fusage-of-autorelease-pool-in-objectatindex-swizzling-for-nsmutablearray%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Swizzling a Foundation method that is frequently? That code, right there, would be enough for me to suspect that the entire codebase is complete and utter trash that really really needs to be rewritten.
– bbum
Nov 13 '18 at 20:01