{"metadata":{"image":[],"title":"","description":""},"api":{"url":"","auth":"required","results":{"codes":[]},"settings":"","params":[]},"next":{"description":"","pages":[]},"title":"Core classes","type":"basic","slug":"core-classes","excerpt":"com.github.badoualy.telegram.tl.core","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.","updates":[],"order":0,"isReference":false,"hidden":false,"sync_unique":"","link_url":"","link_external":false,"_id":"57e0db732d9d3b1900b5a3dd","category":{"sync":{"isSync":false,"url":""},"pages":[],"title":"TL module","slug":"tl-module","order":2,"from_sync":false,"reference":false,"_id":"57e0db616a1c2e0e0081fe64","__v":0,"project":"5703d527bb69fc1700553ce0","createdAt":"2016-09-20T06:46:57.444Z","version":"5703d527bb69fc1700553ce3"},"parentDoc":null,"version":{"version":"0.0.6","version_clean":"0.0.6","codename":"","is_stable":true,"is_beta":true,"is_hidden":false,"is_deprecated":false,"categories":["5703d527bb69fc1700553ce4","5703d8b7aceacc17003ef303","5703e60b6116142000db25f6","57e0db616a1c2e0e0081fe64","57e0f141ff540c22007b45fa","57e0f14b8929550e00f1d9bc"],"_id":"5703d527bb69fc1700553ce3","createdAt":"2016-04-05T15:09:27.620Z","hasDoc":true,"releaseDate":"2016-04-05T15:09:27.620Z","__v":6,"hasReference":true,"project":"5703d527bb69fc1700553ce0"},"createdAt":"2016-09-20T06:47:15.748Z","githubsync":"","project":"5703d527bb69fc1700553ce0","__v":0,"user":"5631f962c3b04b0d00ba9bf1"}