Talk:Duck typing

Criticism

Currently the paragraph about criticism contains: "One issue with duck typing is that it forces the programmer to have a much wider understanding of the code he or she is working with at any given time." But that is totally wrong. In ruby you usually see .is_a? String or even better a .responds_to? some_method relationship. At this point you do NOT AT ALL need to understand WHAT the code is doing as long as it gives you meaningful results (which it should, since it will support "duck typing" already. Whoever wrote this was either biased, didnt know what he is writing about, or simply lies. It should be reworded or removed, because the issue as described here does NOT exist. Duck typing really is about not worrying at all that the object will do something "illegal" and it frees programmer's brain. —Preceding unsigned comment added by 80.108.103.172 (talk) 23:19, 17 April 2008 (UTC)

sorry, you are promoting and arguing in favour, while this paragraph is about Criticism. In such an paragraph, it is not the point to show if the Criticism is true or false, it's about mentioning that there is Criticism. Much of the problem with this page stems from people trying to argue here (in the enceclopedia), instead of documenting (underpinned with valid references) the arguments brought forth elsewhere by the experts of the matter. —Preceding unsigned comment added by 91.12.1.109 (talk) 01:40, 22 July 2009 (UTC)

Another criticism of duck-typing is that it depends on testing, which in most software organizations can fall anywhere between 'ok' and 'terrible'. Compiler type checking is meant to catch a range of errors concerned with sloppy code organization and type usage. Duck typing assumes that away under the aegis of 'good testing', which is by no means guaranteed in most normal organizations. All software development methods depend on one thing not normally present in most programmers: discipline. In a situation where there are a lot of software engineers who exhibit discipline, duck-typed languages will most likely provide benefits. In more typical situations, things may not go so well (since many errors are delayed to runtime, which will inevitably be released to the field). I also agree with the above comments about 'presenting true or false'.. that is not the purpose of an encyclopedia. —Preceding unsigned comment added by 207.67.226.96 (talk) 01:26, 7 April 2010 (UTC)

Can I ask -- how would that criticism not be true with duck typing? Clearly the developer does need to know at least the following:

1. That the method should exist (since it may or may not actually be written down or have docs anywhere).
2. That the receiver on which the method is being called should be able to receive the method.
3. What parameters the method should expect to receive (as well as some semblance of their types).
4. What the contents and type of result will be returned by the method.

In languages that use static interfaces rather than duck-typing, the developer only needs to follow the documented contract, rather than having to have the knowledge & understanding for the above. If they aren't passing the right things or the method doesn't exist, they get immediate feedback in the form of a compile error. Granted, they may need to look-up more information to understand how to assemble everything in the static interface contract, but there's not a lot of knowledge the developer needs to already have to know what the signature of the method is. GuyPaddock (talk) 16:13, 31 August 2017 (UTC)

Article appears biased

After reading this talk section and experiencing seemingly random deletions by Paddy3118, I wish to call for a dispute resolution. It appears that Paddy3118 has a strongly formed opinion that there is no such thing as Duck-typing in static languages. While multiple authors here believe there well is. This needs to be documented and clearly worked out rather than just deleting our works on sight. I don't see any harm in stating that generic programming is seen by some (many?) as duck-typing - rather than suppressing this point. Unless there is some authoritative reference stating that Duck-typing is by definition connected to a dynamic type system, I would defend the position that generic programming is a perfectly valid way to implement the concept of Duck-typing. — Preceding unsigned comment added by Wiki Tesis (talk • contribs) 08:15, 29 October 2013 (UTC)

Hi Tesis. Sections 3.1, 3.2 and 3.3 distinguish Duck typing from similar schemes. Does the method you propose fit any of them? I note that rather than try and argue why your example language should be included you seem to be stating that because you can accomplish one example that happens to not show a run time addition of class methods which is the dynamic part of DT, that that is enough for your examples inclusion.

Duck typing is a term from the dynamic languages world. If not then it would be just another word for probably generic or structural typing and so redundant. So, does what you propose match any of the typing schemes that DT is compared to in section 3? What is the normal term used for what you propose in your languages documentation? Is your language statically typed? We could have a discussion. --Paddy (talk) 23:15, 29 October 2013 (UTC)

"Duck typing is a term from the dynamic languages world." - Even if this is historically true, it still does not mean that the typing-concept does not apply to static languages as well. A typing-concept as a language-independent concept is not defined by the fact in which language it appeared first, but by the underlying concept it represents. Section three states "Template, or generic functions or methods apply the duck test in a static typing context" - which I believe is correct to say. And while I believe that the Duck test is the essence of Duck-typing, you seem to believe that the fact that it is done at run-time is the defining feature. Nothing in the original references to Duck-typing seem to support that. Please provide proof to the opposite if my view is wrong. Duck-typing is also not redundant with respect to structural or generic typing as the concept can be interpreted as a specific case of e.g. generic typing, while it also applies to dynamic typing environments (without any generic elements). I would still stick to the interpretation that Duck-typing refers to the concept of dispatching based on the characteristics of the methods or functions which are defined on a type. Whether this is done statically of dynamically is a secondary feature. — Preceding unsigned comment added by Wiki Tesis (talk • contribs) 01:47, 30 October 2013 (UTC)

I haven't seen duck typing discussed as a concept in static languages (perhaps it is though). It doesn't matter whether it is a concept, just whether it is discussed as a concept by secondary sources, not original research. Seems completely fine to me to add content about static languages, but it needs to be referenced, with noteworthy sources (not a non-expert blog post with 0 comments). In the current version I just saw, the only reference (other than a podcast about Boo that I didn't watch), was a StackOverflow post with 5 upvotes. Whereas it's extremely verifiable for Python. Anyway, I condensed the original research about reflection, etc. into a couple of sentences.  dmyersturnbull  ⇒ talk 21:14, 2 February 2022 (UTC)

Paring down examples

Similarly to the Language Support section, the examples are incredibly verbose to the point of confusion. The output text is needlessly "humorous", and having two examples - in two different languages no less - merely complicates the issue. I'll replace them with a simple Python example, which of course can be edited as needed. — Preceding unsigned comment added by CrackedP0t (talk • contribs) 04:48, 15 June 2017 (UTC)

Cited limitation of protocols is only true for some languages

This wiki page asserts that a limitation of protocols is that externally defined classes cannot be made to support the interface (without something like an adapter class). While this is true for many languages, it is not true for all. For example, the Swift programming language allows you to extend external classes to support an internal protocol. — Preceding unsigned comment added by Jmacglashan (talk • contribs) 17:18, 6 September 2019 (UTC)

Very Confusing

The article is too confusing at several levels and should be rewritten, at least partly. It starts by referring to the origin of the expression rather than explaining what it is, then provides an unpolished definition, and ruins the effect with a ludicrous and irrelevant code example.

1. The definition

With duck typing, an object is of a given type if it has all methods and properties required by that type.

No, that's too restrictive and confusing. Again, this is simpler: With duck typing, an object is defined by its properties. And this should come first, before any comparison to nominal typing.

With nominative typing, an object is of a given type if it is declared as such

No, at best that's a truism. This is simpler: With nominal typing, an object is defined by its declared type.

• Nominal subtyping isn't necessarily incompatible with duck typing, so caution is required there. In particular, nominal subtyping include objects that are identified by their interface, but an interface only specifies a part of an object property - generally a set of methods - and thus are a good example of duck typing. If an interface `Display` declares a method `print`, and the types `Integer` and `Float` both implement this interface, one piece of code accepting a `Display` object is only interested in the `print` method, with no regards to the object type. The interface requirements are the duck test.
• Structural typing isn't mentioned here, but in the Comparison with other type systems section.

So perhaps it would be better to include a comparison with nominal typing and subtyping in that section and only keep a brief mention of nominal typing here.

What is duck typing? Duck typing is a programming method that identifies and processes objects according to their properties — such as methods or attributes — rather than to their type. By extension, it may also be a programming method that tries to use some properties of an object without checking its type, optionally handling any error this may trigger.

Then the origin of the expression may be given.

Note also that of the 2nd reference is obsolete (404), and the only remaining reference points to a Python manual.

2. The example

Just because there is a 'duck' in the expression doesn't make it necessary, nor even preferable, to have a 'duck' in the example.

This simple example in Python 3 demonstrates how any object may be used in any context until it is used in a way that it does not support.

How could that example be of any help to understand what duck typing is? It's not realistic, and it doesn't use the object properties to define the object.

If it can be assumed that anything that can swim is a duck because ducks can swim, a whale could be considered a duck; however, if it is also assumed that a duck must be capable of flying, the whale will not be considered a duck.

This, I think, is the final nail in the coffin. At that point, any person trying to understand the meaning of 'duck typing' has left and is looking for the answer elsewhere.

A better example would be, for instance, how the update method of dictionaries operate:

class dict(object):
    def update(self, E=None, **F): # known special case of dict.update
        """
        D.update([E, ]**F) -> None.  Update D from dict/iterable E and F.
        If E is present and has a .keys() method, then does:  for k in E: D[k] = E[k]
        If E is present and lacks a .keys() method, then does:  for k, v in E: D[k] = v
        In either case, this is followed by: for k in F:  D[k] = F[k]
        """

This method accepts another dictionary, an iterable of tuples, or any object implementing either keys() or __getitem__(self, index). It uses duck typing to provide a flexibility that could not be achieved by checking the object's type with isinstance(obj, class_or_tuple), or by declaring the object's type in a statically-typed language.