Some thoughts on duck typing

Richard Gaskin ambassador at
Wed Jan 12 09:37:02 EST 2011

David Bovill wrote:

> If it quacks like a duck it is a duck.
> So I have some data in a variable that I want to display. I can use is an
> array/number/date - but for other types of data I'm wandering... xml should
> be easy, but harder would be to distinguish long text files from binary. Any
> ideas for hacks to distinguish:
>    1. images
>    2. sounds
>    3. video
>    4. binary blob
>    5. text
>    6. rtftext
>    7. utf8
> I think a lot of these can be tested by trying them out in various
> containers - ie can I create an image? What happens if I set the unicodetext
> of a field... but some of the work needs to be done by looking at the data
> first. So what would a duck_Type handler look like for LiveCode:
> function duck_Type someData
>   switch
>     case someData is an array
>       return "array"
>     case someData is a date
>       return "date"
>     case someData is a number
>       return "number"
>     case ???
>       return "???"
>   end switch
> end duck_Type
> Note - the idea is to work on data in a variable, not a file. I have a few
> handlers for looking at files - any suggestions / snippets of code?

If such metadata are needed for the variables, what would be the 
downside of using an array?  That way you could store/access the type 
metadata quickly:

   put tData into gMyDucksA["label"]["data"]
   put "rtfText" into gMyDucksA["label"]["type"]

I realize that this is an obvious solution you've probably already 
considered, but given the difficulties of imposing types and OOP 
constructs in a typeless non-OOP language, for practical purposes such a 
Lua-metatable-esque option may provide a reasonable balance between 
performance and flexibility.

If an array is unsuitable for your needs I would be interested in 
learning more about the problem being solved to see if there's an 
efficient solution.

  Richard Gaskin
  Fourth World
  LiveCode training and consulting:
  Webzine for LiveCode developers:
  LiveCode Journal blog:

More information about the Use-livecode mailing list