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 thanObjectTLMethod: likeTLObject, this class defines a basic operations for a rpc method type.
Then, we have the basic types implementation:
TLBool: boolean type implementationTLBytes: ByteArray type implementationTLGzipObject: ATLObjectcan sometimes be gzipped, this is the implementation (it just contains a ByteArray being the packed data).TLVector: array type implementation forTLObjectarrays.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, ...)
TLInt types (and TLString, TLLong, ...)- For the primitive types (int, long, ...) implementation a subclass of
TLObjectwould be possible, but would mean that every time we use this type in a subclass ofTLObject, we would have to use an object instead of a primitive, which is horrible for memory (it would be the same as usingIntegerobject everywhere instead of int, when it's not needed). - For the
Stringtype, we could've had aTLStringtype, but there's not point of having one.
Then why do we have a TLBool type?
TLBool type?Because the tl-schema contains the following constructors:
{
"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:
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.
Updated less than a minute ago