Replies: 2 comments 12 replies
-
|
Yeah I understand that, and that's another reason I'd love to help, a project like this is a lot for one person, with some help, maybe one day it will be more than a prototype 😄 And I'm cool with the C# Type, I'm not personally familiar with C# but I was reading the docs and it seems all good Is there anything you have on the todo list but cannot get to yet? |
Beta Was this translation helpful? Give feedback.
-
|
Just as a quick example, it could be something like this... it's just a lot of code to be throwing in the transpiled version declare global {
interface Function {
__getSymbol(): symbol;
getType(): Type;
}
interface Object {
__getSymbol(): symbol;
getType(): Type;
}
}
export class SomeClass {
someMethod() {
return "";
}
}
Object.defineProperty(SomeClass, '__getSymbol', {
enumerable : false,
get(): any {
return function () {
return Symbol.for("485");
}
}
});
Object.defineProperty(SomeClass, 'getType', {
enumerable : false,
get(): any {
return function () {
return Type._getTypeMeta(Number(this.__getSymbol().description))
}
}
});(this actually works with the id for the type :D) |
Beta Was this translation helpful? Give feedback.
-
My formatting is affected by the C# formatting,.. .NET devs friendly, JavaScript devs unfriendly. 😅 |
Beta Was this translation helpful? Give feedback.
-
|
That's totally fine with me, I like the style of it. and perfect, I was hoping it was JetBrains based :D I will do some experimenting with my idea above, it seems there may be some flaws, jut realised that maybe I've mis-understood how javascript prototype works over all of the years 😅 |
Beta Was this translation helpful? Give feedback.
-
|
There will be problem with Methods and similar things.. All of that can be used as Type. (I've implemented some of those things today :D) module mod {}
class A {
doSomething();
}
let x: A["doSomething"] = function() {};
let m: typeof mod = {};You want to generate those defineProperty, right? And make it available for everything? It means generate those defineProperty for every type in the source code; even those inside 3rd party packages... BTW: What is your usage? So it would be: Object.defineProperty(Object.prototype, 'getType', {
enumerable : false,
get(): any {
return function () {
return Type._getTypeMeta(Number(this.__getSymbol().description))
}
}
});And generate only those __getSymbol(). |
Beta Was this translation helpful? Give feedback.
-
|
IMHO, it will be much easier to handle all And just add global declaration into the tst-reflect package:
interface Object
{
getType: (() => import("tst-reflect").Type) & { __tst_reflect__: true }; // that object with __tst_reflect__ is for identification of our `.getType()`, cuz somebody can override that with own method.
}and
Object.defineProperty(Object.prototype, "getType", {
enumerable: false,
get(): any
{
return function () {
return undefined;
};
}
});And final usage: class A {}
const a = new A();
a.getType(); // handled by transformer and replaced by tst_reflect.getType(12345)PS: Maybe I just missed your point,.. write me some example, what to change in runtime, transformer and what will be the usage. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah this is a good point, it's not great to generate it for everything 😅 Only reason I thought of doing this is because it was a nice thing to have access too, but also came with the I wont worry too much about these things for now any-way, will help get some of the other parts of the package that are probably more critical Now that you mention it though, I do also prefer this syntax a lot :D class A {}
const a = new A();
a.getType(); // handled by transformer and replaced by tst_reflect.getType(12345) |
Beta Was this translation helpful? Give feedback.
-
Yes and no. Base(/first implemented) mode is per-file "cache". Each type's info is generated once per file, no matter how many getType calls are there. Because in TS you don't know which file is "root" (executed/loaded first), so you don't know where to place all the generated metadata. Example of the base per-file mode:
"reflection": {
"metadata": false, // disable second "metadata" mode, which is under development but it is default mode now, cuz it is better
"debugMode": false
}
import {
getType,
Type,
TypeKind
} from "tst-reflect";
abstract class Animal
{
abstract get kind(): string;
abstract get name(): string;
protected constructor(protected readonly _kind: string)
{
}
abstract makeSound();
}
const typeOfAnimal: Type = getType<Animal>();
console.log("Kind of the Type: ", TypeKind[typeOfAnimal.kind], " Name of the Type:", typeOfAnimal.name, " Full name of the Type:", typeOfAnimal.fullName, " Details:", typeOfAnimal);
console.log(getType<Animal>().name);
console.log(getType<Animal>().fullName);
console.log(getType<Animal>().baseType);Generated JS:
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
const tst_reflect_1 = require("tst-reflect");
tst_reflect_1.getType({ n: "Animal", fn: "..\\index.ts:Animal", props: [{ n: "kind", t: tst_reflect_1.getType({ n: "string", k: 2 }) }, { n: "name", t: tst_reflect_1.getType({ n: "string", k: 2 }) }, { n: "_kind", t: tst_reflect_1.getType({ n: "string", k: 2 }) }], ctors: [{ params: [{ n: "_kind", t: tst_reflect_1.getType({ n: "string", k: 2 }) }] }], k: 1, ctor: () => Animal }, 23251);
class Animal {
constructor(_kind) {
this._kind = _kind;
}
}
const typeOfAnimal = tst_reflect_1.getType(23251);
console.log("Kind of the Type: ", tst_reflect_1.TypeKind[typeOfAnimal.kind], " Name of the Type:", typeOfAnimal.name, " Full name of the Type:", typeOfAnimal.fullName, " Details:", typeOfAnimal);
console.log(tst_reflect_1.getType(23251).name);
console.log(tst_reflect_1.getType(23251).fullName);
console.log(tst_reflect_1.getType(23251).baseType);
//# sourceMappingURL=index.js.mapTransformer goes through source code and looks for Second "metadata" mode (work in progress, buggy)Enabled by default as I wrote in first section. I wanted to implement config option to enable "full" metadata library, it means generate metadata for all of the types in the project (including packages) but cuz of performance, it is not a good idea.. |
Beta Was this translation helpful? Give feedback.
-
|
Okay I see now, I think I tried the second option at some point, which didn't work for me, but now I think back... I don't think I imported the generated file 😅
Yeah... I can see that, it might be a good idea to be able to configure some paths which will be generated for, regardless of it, kind of like typescripts tsconfig "include" option If for example, with your container, you made a package, but had some logic depending on reflection there, it would cause some problems and not work, or in a mono-repo style project I'd be open to put some more work into this metafile style generator once I'm done with method reflection :) |
Beta Was this translation helpful? Give feedback.
-
|
The biggest issue in metadata lib mode are imports of classes for |
Beta Was this translation helpful? Give feedback.
-
From @iDevelopThings, #9
Hi, this is still a prototype, a lot of things can change but I'm open to contributions. I've not prepared any guide,.. but one important thing for me is keeping
Typeas close as possible to C#'s Type.Beta Was this translation helpful? Give feedback.
All reactions