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 thanObject
TLMethod
: 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
: ATLObject
can sometimes be gzipped, this is the implementation (it just contains a ByteArray being the packed data).TLVector
: array type implementation forTLObject
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
, ...)
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 ofTLObject
, we would have to use an object instead of a primitive, which is horrible for memory (it would be the same as usingInteger
object everywhere instead of int, when it's not needed). - For the
String
type, we could've had aTLString
type, 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