<FromGitter>
<Blacksmoke16> > It will be more efficient to set everything at compile time. One can create another object if needed β β This would be gross if you had to have separate objects just to do what that does
<FromGitter>
<Blacksmoke16> @j8r ^
<FromGitter>
<Blacksmoke16> IMO the extra flexibility you get is much more helpful than having it be faster in benchmarks
<FromGitter>
<j8r> It make sense to have 2 separate objects
<FromGitter>
<Blacksmoke16> why?
<FromGitter>
<j8r> I looked at Serde, AFAIK they haven't this feature
<FromGitter>
<Blacksmoke16> so?
<FromGitter>
<j8r> because the mapping are different, even they look close
<FromGitter>
<Blacksmoke16> just because serde doesnt have it doesnt mean its the end of the world
<FromGitter>
<Blacksmoke16> its literally the same object, you're just altering how it gets serialized at runtime
<FromGitter>
<j8r> I didn't see in other places too, like Go
<FromGitter>
<watzon> Nothing wrong with *cue macintosh boot sound* thinking differently
<FromGitter>
<j8r> There are perf impact and more complexity for a niche feature IMHO
<FromGitter>
<j8r> What is the problem of 2 objects? We can use inheritance and composition already
<FromGitter>
<Blacksmoke16> E.x an ORM model
<FromGitter>
<Blacksmoke16> im totally against having "view" objectss
<FromGitter>
<Blacksmoke16> if you can get the same result from one object with some annotations
<FromGitter>
<Blacksmoke16> sure its going to be a bit slower, but that extra flexibility is much more useful to me imo
<FromGitter>
<Blacksmoke16> than being a bit higher in a benchmark
<FromGitter>
<j8r> In you example,we can have `Example1` and `Example2` inheriting from another object
<FromGitter>
<Blacksmoke16> i.e. like define id/title on parent, and each unique property in its own class?
<FromGitter>
<Blacksmoke16> that still wouldnt work, they all share the same properties, you just need to alter how it gets serialized
<FromGitter>
<Blacksmoke16> to do that currently you would have to do something yourself, or have "view" objects
<FromGitter>
<Blacksmoke16> dosn't *have* to use annotations
<FromGitter>
<Blacksmoke16> but just showing its possible
<FromGitter>
<Blacksmoke16> like `SomeExclusionStrategy` is added at runtime, but only if at least 1 ivar on `self` has the annotation
<FromGitter>
<Blacksmoke16> like you can do it however you want
<FromGitter>
<Blacksmoke16> but yea, working with annotations is a bit harder since we dont have reflection, so im currently just storing an array of applied annotations within the metadata struct
absolutejam1 has quit [Ping timeout: 264 seconds]
<FromGitter>
<j8r> The idea is good, but it will even better if it's an extension of the framework
<FromGitter>
<j8r> Like CrSerializer, in some way
<FromGitter>
<j8r> I'm not convinced everyone will need it every time, I don't know the perf/memory penalty.
<FromGitter>
<Blacksmoke16> @j8r thats idea, the shard defines the structure and common stuff, then users can extend it as needed
<FromGitter>
<dscottboggs_gitlab> why is there no way to iterate over the child-nodes of an ASTNode in macros?
<FromGitter>
<Blacksmoke16> like children of a parent class or?
<FromGitter>
<dscottboggs_gitlab> like `{{@def.body.children.each}}` or something
<FromGitter>
<dscottboggs_gitlab> which would give you like an array of ASTNodes which might be like Calls or Vars or whatever
<FromGitter>
<dscottboggs_gitlab> woke up this morning thinking for sure I could implement Go's `defer` by using just macros, just wound up crashing the compiler a bunch of times because the type given to `@def.body` is basically useful only for string manipulation and stuff
<FromGitter>
<Blacksmoke16> and yea @j8r, its def slower but i doubt it would be noticeable in a real world scenario. prob could see it in benchmarks but meh
<FromGitter>
<Blacksmoke16> boils down to just a few extra method calls and some loops
<FromGitter>
<Blacksmoke16> @dscottboggs_gitlab whats that do?
<FromGitter>
<dscottboggs_gitlab> what's what do? Go's `defer` or `@def.body`?
<FromGitter>
<dscottboggs_gitlab> ye it's pretty simple
<FromGitter>
<dscottboggs_gitlab> it would be pretty easy to implement if you could iterate over the ast nodes in a `Def`'s body...
<FromGitter>
<Blacksmoke16> fair enough
<FromGitter>
<watzon> @dscottboggs_gitlab you can in Nim :/
<FromGitter>
<watzon> I wish you could in crystal
<FromGitter>
<dscottboggs_gitlab> guess I need to learn nim now so I can rip off their implementation for crystal\
<FromGitter>
<dscottboggs_gitlab> :/
<FromGitter>
<watzon> Well what nim has is a more advanced macro system
<FromGitter>
<watzon> In nim you'd be able to loop over the ast of a method definition and change it at compile time
<FromGitter>
<dscottboggs_gitlab> > Nim has is a more advanced macro system β β In like a fundamental, architectural way, or like, it's just more fleshed out?
<FromGitter>
<dscottboggs_gitlab> That's exactly what I want to be able to do
<FromGitter>
<Blacksmoke16> maybe one day
<FromGitter>
<watzon> One could hope, but the maintainers don't seem to be interested