"Maybe we are not talking about the same thing ?" We do I just brought an alternative. My initial question is why this data is not stored inside a Collection and instead individual methods are preferred.
But now that I thought it through I understand in practice would not make much difference. And as you said methods are already browsable, Collections are not. "If so, then the reason to keep them in image has to do with resource management, an image is self contained. I was talking about managing resources as a collection of methods, an example would be ZnByteEncoder, where mappings are defined on the class side. If resources are originally downloaded from somewhere else but cached inside the image, it is worth mentioning that, and shipping the necessary code to redo it, in the case of the example, #generateByteToUnicodeSpec:" Yeah I think I understand that now too, it makes the distribution of the image much easier not to have to worry about external resources. Yes I did understood what you were talking about, I just was not clear about the benefits of this approach over using Collections and instance variables instead. But I do think that now I understand . Thank you for trying to help me understand :) It was important for me to understand this because I want to import a lot of SVG data into the image and I was not sure if I should use just SVG files or instead use methods that return SVG strings. I would be using methods since it will make my distribution much simpler and easier to version control too.
