Usage of autorelease pool in objectAtindex swizzling for NSMutableArray












0















- (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?










share|improve this question

























  • 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
















0















- (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?










share|improve this question

























  • 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














0












0








0








- (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?










share|improve this question
















- (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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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



















  • 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












2 Answers
2






active

oldest

votes


















1














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.






share|improve this answer
























  • 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











  • 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



















1














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 and objectAtIndex (post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; or


  • The 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; or


  • Wishes 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); or


  • Who knows, accept the original author (hopefully!)



HTH






share|improve this answer





















  • 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











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
});


}
});














draft saved

draft discarded


















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









1














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.






share|improve this answer
























  • 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











  • 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
















1














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.






share|improve this answer
























  • 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











  • 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














1












1








1







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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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 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











  • 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











  • 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













1














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 and objectAtIndex (post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; or


  • The 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; or


  • Wishes 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); or


  • Who knows, accept the original author (hopefully!)



HTH






share|improve this answer





















  • 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














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 and objectAtIndex (post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; or


  • The 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; or


  • Wishes 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); or


  • Who knows, accept the original author (hopefully!)



HTH






share|improve this answer





















  • 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








1







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 and objectAtIndex (post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; or


  • The 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; or


  • Wishes 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); or


  • Who knows, accept the original author (hopefully!)



HTH






share|improve this answer















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 and objectAtIndex (post the swizzle) add a significant amount of objects to the autorelease pool and wishes to clean these up; or


  • The 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; or


  • Wishes 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); or


  • Who knows, accept the original author (hopefully!)



HTH







share|improve this answer














share|improve this answer



share|improve this answer








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














  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Florida Star v. B. J. F.

Danny Elfman

Lugert, Oklahoma