[Interest] Why does QML prefer 'count' over '.length'?

Jason H jhihn at gmx.com
Thu Jul 28 15:46:50 CEST 2016


> It makes perfect sense. "count" makes sense for visual things. "length" only means "amount" in computer science, and only then in the realm of containers. You don't say "white blood cell length" when referring to the amount of blood white cells, you say "white blood cell count". You don't say "the length of items in a view", you say "the count/amount of items in a view".
> 
> Names should be intuitive, and often the best way to do that is to be analogous to real life.
> 
> The correct response to
> 
> "What is the combined length of your pets?"
> 
> is fear and confusion.
> 
> Whereas a valid response to
> 
> "How many pets do you have?"
> 
> is
> 
> "Oh, three."
> 
> > That's not a potential confusion, that's a real confusion today:
> 
> This is the first time I've heard anyone have a problem with it.
> 
> > property variant items: [1, 2, 3, "four", "five"] // this will use length
> > ListModel{ id: items; ... } // this will use count.
> 
> One is a JavaScript type for storing almost any type of data, the other is a Qt type whose sole purpose is for use with visual types.


Look, I know JS was invented in 10 days back in 1995. There's no shortage of things to complain about. But 'length' was chosen, and it is the number of items. I would agree with you that length is not as good as 'count', but the language is the language. Qt should move to be in compliance wit the language because JS was using it first, then Qt moved into JS. Unless you want to convince JS they should add count to everything as well. And I assure you there is more lines of JS using length than all lines of QML put together.

Consider the absurdity of the reverse:
Why don't we ditch .length in QML and just make everything count? 



More information about the Interest mailing list