Re: blocks and id
Re: blocks and id
- Subject: Re: blocks and id
- From: Mike Abdullah <email@hidden>
- Date: Wed, 12 Dec 2012 13:51:30 +0000
On 12 Dec 2012, at 13:24, Andreas Grosam wrote:
>
> 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
I presume you mean "duck typing"? Duck typing is pretty much the opposite of what you're trying to do. Duck typing is being handed an object and told it meets a certain requirement. Rather than trying to test if it really is of the expected *class*, you message it anyway on the understanding that it will behave as you expect.
The point is that you care whether the object *behaves like* a duck; not whether it actually is a duck.
> and the usage -respondsToSelector:, -conformsToProtocol:, or any other introspection are a bad design, too. ;)
These methods contribute to duck typing sort of behaviour in Cocoa, not the approach you describe below. It's worth noting that Cocoa actually uses these methods pretty sparingly in practice.
>
>
> 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.
Writing category methods seems no more elaborate than writing a big series of if statements checking the class of an object.
> AND it would requite a respondsToSelector anyway,
Not true; if the object doesn't implement the selector, you can consider that to be a programmer error and throw an exception.
> 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.
This is going to end badly, believe me. Look around Cocoa, you will find very, very few APIs, if any, that behave the way you want this one to. You want separate methods for the different types of input to handle. If you accomplish this by defining a protocol that a variety of objects conform to, that's fine; then you only need to publish two methods — one for blocks, and one for other object types.
_______________________________________________
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