Some thoughts on duck typing
andre at andregarzia.com
Wed Jan 12 07:26:54 EST 2011
Be aware that this type inference will cost you cpu and degrade performance
if used constantly in the code like thousand steps in a loop. If it is a
variable which you control all the lifecycle, then you could attach metadata
to it and thus be able to create a little type system which I think is not
the case here because if this was an option you would not be asking this
list, so forgive my previous comments, they are just for archival benefit in
case someone search for this kind of info.
Now, about figuring out ducks from the rest of the fauna, I usually take
some other approach. I don't do usual duck typing by using something like:
"if it looks like a duck, if it quacks like a duck", I do extreme duck
typing, which is: "Can I make it quack?", so what I do is try exclusive
operations on the variable, if the operation succeeds, then it is a duck.
If you can figure out some operation that can only be done on images, then,
treat duck-to-be variable as image and try that operation, if it returns
true, then it is an image for all that we care, if it fails, it is something
This kind of inference by behaviour is easy to implement once you found some
exclusive test operations but it is not error proof. For example, you can
try setting a player video to the content of duck-to-be then check out the
codec or the number of frames or something that only a real movie would have
but before that, you need to make sure that setting the video player to
random binary blobs will not yield results that can be tagged as false
PS: I coined the term extreme duck typing as I was writing this email, think
I will write a book about it and market it not for monetary benefit but to
have such thing next to all those agile books and other buzzword books...
On Wed, Jan 12, 2011 at 9:37 AM, David Bovill <david at vaudevillecourt.tv>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.
> 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
> 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
> 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?
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
http://www.andregarzia.com All We Do Is Code.
More information about the Use-livecode