{"_id":"57e0db732d9d3b1900b5a3dd","category":{"_id":"57e0db616a1c2e0e0081fe64","__v":0,"project":"5703d527bb69fc1700553ce0","version":"5703d527bb69fc1700553ce3","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-09-20T06:46:57.444Z","from_sync":false,"order":2,"slug":"tl-module","title":"TL module"},"parentDoc":null,"version":{"_id":"5703d527bb69fc1700553ce3","hasDoc":true,"__v":6,"hasReference":true,"project":"5703d527bb69fc1700553ce0","createdAt":"2016-04-05T15:09:27.620Z","releaseDate":"2016-04-05T15:09:27.620Z","categories":["5703d527bb69fc1700553ce4","5703d8b7aceacc17003ef303","5703e60b6116142000db25f6","57e0db616a1c2e0e0081fe64","57e0f141ff540c22007b45fa","57e0f14b8929550e00f1d9bc"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.0.6","version":"0.0.6"},"githubsync":"","project":"5703d527bb69fc1700553ce0","__v":0,"user":"5631f962c3b04b0d00ba9bf1","updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-09-20T06:47:15.748Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"The package `com.github.badoualy.telegram.tl.core` package contains all the basic classes to represent the **basic types** of the **TL Language**\n\nThe package contains the following two basic classes:\n- `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`\n- `TLMethod`: like `TLObject`, this class defines a basic operations for a rpc method type.\n\nThen, we have the basic types implementation:\n- `TLBool`: boolean type implementation\n- `TLBytes`: ByteArray type implementation\n- `TLGzipObject`: A `TLObject` can sometimes be gzipped, this is the implementation (it just contains a ByteArray being the packed data).\n- `TLVector`: array type implementation for `TLObject` arrays.\n- `TLIntVector`, `TLLongVector`, `TLStringVector`: array type implementation for the matching type.\n\n### Serialization/Deserialization\nFor 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.\n\n### Why don't we have a `TLInt` types (and `TLString`, `TLLong`, ...)\n- 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).\n- For the `String` type, we could've had a `TLString` type, but there's not point of having one.\n\n### Then why do we have a `TLBool` type?\nBecause the tl-schema contains the following constructors:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"id\\\": \\\"-1132882121\\\",\\n  \\\"predicate\\\": \\\"boolFalse\\\",\\n  \\\"params\\\": [],\\n  \\\"type\\\": \\\"Bool\\\"\\n},\\n{\\n  \\\"id\\\": \\\"-1720552011\\\",\\n  \\\"predicate\\\": \\\"boolTrue\\\",\\n  \\\"params\\\": [],\\n  \\\"type\\\": \\\"Bool\\\"\\n}\",\n      \"language\": \"json\"\n    }\n  ]\n}\n[/block]\nThe 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.\n\n### Why can't we simply replace the boolean constructor with boolean primitives in the generated code ?\nWe 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:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"public abstract class TLMethod<T extends TLObject> extends TLObject {\\n    // ....\\n}\",\n      \"language\": \"java\"\n    }\n  ]\n}\n[/block]\nYou 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.","excerpt":"com.github.badoualy.telegram.tl.core","slug":"core-classes","type":"basic","title":"Core classes"}

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: [block:code] { "codes": [ { "code": "{\n \"id\": \"-1132882121\",\n \"predicate\": \"boolFalse\",\n \"params\": [],\n \"type\": \"Bool\"\n},\n{\n \"id\": \"-1720552011\",\n \"predicate\": \"boolTrue\",\n \"params\": [],\n \"type\": \"Bool\"\n}", "language": "json" } ] } [/block] 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: [block:code] { "codes": [ { "code": "public abstract class TLMethod<T extends TLObject> extends TLObject {\n // ....\n}", "language": "java" } ] } [/block] 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.