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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
