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