Re: blocks and id
Re: blocks and id
- Subject: Re: blocks and id
- From: Andreas Grosam <email@hidden>
- Date: Wed, 12 Dec 2012 14:24:13 +0100
On 12.12.2012, at 13:02, Mike Abdullah wrote:
>
> On 12 Dec 2012, at 09:57, Andreas Grosam wrote:
>
> Why does your code care if some unknown object is a block? This is a strong sign of a bad design.
Oh, then a lot of common Cocoa patters like dug typing and the usage -respondsToSelector:, -conformsToProtocol:, or any other introspection are a bad design, too. ;)
I don't like it either, but the alternative would be a quite elaborate approach and would require to define categories for every class that is possibly involved in this particular case. AND it would requite a respondsToSelector anyway, AND would require some mechanism that "processes" a block and the other objects through sending the object a common single message.
The reason why I would like to have this is a rather generic interface which shall be as flexible and as convenient as possible. It is used for a network library when generating HTTP messages. For example, the following snippet creates a Foundation representation of a multipart/form-data part suitable to upload a file to a server:
id<RXMultipartFormdataPart> part6 =
[RXMultipartFormdataSource makeFilePartWithName:@"submit"
fileName:@"data2.txt"
headers:@{@"content-type":@"text/plain"}
value:[NSData dataWithBytes:"0123456789" length:10]];
The construction of a valid sequence of bytes constituting various HTTP headers is more than cumbersome.
In this snipped, the parameter `headers` are defined as a NSDictionary. However, it could also be a NSData containing a valid sequence of bytes constituting *one* header, or *many* headers, or an NSArray of NSDatas constituting a number of headers. And since a header may have a set of parameters, a header entry in the dictionary may have a params dictionary as well, and so force. The parameter `headers` (and the others, too) will simply pass a serialization process, which eventually generates a NSData object - constituting one or more HTTP message headers.
Likewise, parameter `value` constituting the body part can be anything that can be eventually converted to something that is a valid byte sequence for the body data of a multi part, conforming to the context defined through the headers already set. If the header would be empty, and value would have been a NSString, the string would be encoded properly with a default encoding (UTF-8), and the headers would be set accordingly (-> "Content-Type: text/plain; charset=utf8").
If the parameter `value` would be NSNumber for instance, the NSNumber would be first converted to a NSString, and then encoded as mentioned above.
If a Content-Type header with a charset definition has been defined already and the value is a NSString, the string will be encoded as stated in the charset parameter value (e.g. charset=utf8).
The parameter value can be a file URL, too -- in which case a more elaborated mechanism is used to construct the body of the whole message during the request is active.
And, it can be a block as well, where the block is responsible to feed the consumer (the id<RXMultipartFormdataPart>) with data when it has bytes available when the request is active.
You can do this with the same method, same API. Well, it MUST, otherwise the number of combinations of the various types yielding different methods, would explode.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden