'What's the use of count() as we already have size for Map, List and Array?

In Kotlin collections (list, array and map), to get the size, we already have size. What's the use of count()?

val list = listOf(1, 2, 3)
list.size
list.count()

val map = mapOf(1 to 1, 2 to 2, 3 to 3)
map.size
map.count()

val array = arrayOf(1, 2, 3)
array.size
array.count()

Essentially, if we check them under the hood, they just return size.

kotlincollectionsphpiosfirebasefirebase-realtime-database


Solution 1:[1]

size and count() come from different interfaces. size is defined on kotlin.collections.Collection, which List and Set both implement:

public interface Collection<out E> : Iterable<E> {
    // Query Operations
    /**
     * Returns the size of the collection.
     */
    public val size: Int

    ...

while count() is an extension method defined on kotlin.collections.Iterable (which Collection inherits from):

/**
 * Returns the number of elements in this collection.
 */
public fun <T> Iterable<T>.count(): Int {
    if (this is Collection) return size
    var count = 0
    for (element in this) checkCountOverflow(++count)
    return count
}

So merely inheriting from Iterable gives Collections, including Lists and Sets, a count() method automatically. And we definitely want Collection to inherit from Iterable so that we can pass a Collection to a method that will accept any Iterable. Then, finally, Map (which is not a Collection) gets both the size property and the count() method too for the sake consistency with List and Set.

Technically I guess that already answers the question of why collections have the count() method, but it is not yet a satisfying explanation because it invites a followup question: why do Collections have the size property, then? Why didn't the standard library developers simply not bother adding size and instead have us call count() on Collections?

The implementation of count(), quoted above, shows us the answer to that question: size is a performance optimisation. When called on a non-Collection Iterable of n elements, count() has O(n) time complexity, because it loops over all the elements in the iterable. When called on a Collection, it should have O(1) time complexity because it simply defers to the size property (which will hopefully be O(1) to evaluate!).

Next we might ask: could this optimisation have been achieved in some other way? Instead of complicating the API with an additional property, couldn't the standard library developers have simply had all the Collections they implemented provide their own count() member function, with O(1) time complexity?

Nope. Because extensions are resolved statically - so if you didn't have size, and instead had O(1) implementations of count() provided on List, Map, Set, and so on, then those O(1) implementations wouldn't get used when you passed a List or Map or Set to a function that takes an arbitrary Iterable as an argument and calls its count() method; instead, the call would be statically resolved to the O(n) extension method.

Having size and count() both exist is thus the only way to be able to make count() available on all Iterables but also have it be O(1) for Collections.

As a final note, if you were wondering why count() is a method and size is a property, the Coding conventions offer a clue:

Functions vs properties In some cases functions with no arguments might be interchangeable with read-only properties. Although the semantics are similar, there are some stylistic conventions on when to prefer one to another.

Prefer a property over a function when the underlying algorithm:

  • does not throw

  • is cheap to calculate (or cached on the first run)

  • returns the same result over invocations if the object state hasn't changed

(bolding mine). Since count() is (potentially) expensive to calculate but size is cheap, it follows that count() should be made a method and size a property - which is indeed what the standard library developers did.

Solution 2:[2]

There is nothing iOS specific about a Firebase Realtime Database instance, so you can indeed access that same database from PHP. To do so you can either use the REST API that Firebase provides, or you can use a 3rd party wrapper library, such as kreait/firebase-php.

Also see:

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Frank van Puffelen

Related Questions