Core classes

com.github.badoualy.telegram.tl.core

The package com.github.badoualy.telegram.tl.core package contains all the basic classes to represent the basic types of the TL Language

The package contains the following two basic classes:

• TLObject: all the types of the tl-language (and all the constructors/methods of the tl-schema) have this superclass in common. It only defines some basic methods, and is present to have a superclass less generic than Object
• TLMethod: like TLObject, this class defines a basic operations for a rpc method type.

Then, we have the basic types implementation:

• TLBool: boolean type implementation
• TLBytes: ByteArray type implementation
• TLGzipObject: A TLObject can sometimes be gzipped, this is the implementation (it just contains a ByteArray being the packed data).
• TLVector: array type implementation for TLObject arrays.
• TLIntVector, TLLongVector, TLStringVector: array type implementation for the matching type.

Serialization/Deserialization

For those two operations on the previous basic types, the implementation is delegated to the StreamUtils class that is responsible for writing/reading in a stream.

Why don't we have a TLInt types (and TLString, TLLong, ...)

• For the primitive types (int, long, ...) implementation a subclass of TLObject would be possible, but would mean that every time we use this type in a subclass of TLObject, we would have to use an object instead of a primitive, which is horrible for memory (it would be the same as using Integer object everywhere instead of int, when it's not needed).
• For the String type, we could've had a TLString type, but there's not point of having one.

Then why do we have a TLBool type?

Because the tl-schema contains the following constructors:

JSON

{
  "id": "-1132882121",
  "predicate": "boolFalse",
  "params": [],
  "type": "Bool"
},
{
  "id": "-1720552011",
  "predicate": "boolTrue",
  "params": [],
  "type": "Bool"
}

The reason behind that is that some rpc methods type returns a boolean, more precisely, one of the upper constructor. Maybe in the future, one method will return an integer (not the case as of today) and a integer constructor will be introduced, in this case, we probably will have a TLInt type.

Why can't we simply replace the boolean constructor with boolean primitives in the generated code ?

We could, but here's the catch, you now know that all the methods have the TLMethod as a superclass. This class is defined as followed:

Java

public abstract class TLMethod<T extends TLObject> extends TLObject {
    // ....
}

You can see that the TLMethod type is parameterized by a type T being a subclass of TLObject: T is the type of the response, so we must have an object extending TLObject, thus having the TLBool type.