faustinoaq changed the topic of #amber to: Welcome to Amber Framework community! | https://amberframework.org | Developer happiness, productivity and bare metal performance | GH: https://github.com/amberframework | Docs: https://docs.amberframework.org | Gitter: https://gitter.im/amberframework/amber | IRC Logger: https://irclog.whitequark.org/amber | Amber::Server.start
<FromGitter> <Blacksmoke16> check this out
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/amberframework/amber?at=5d968d6037073b36a06733b2]
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/amberframework/amber?at=5d968d6a92920c36a1094034]
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/amberframework/amber?at=5d968d8049c7720aaf5f0c4d]
<FromGitter> <Blacksmoke16> if you did `Book.new "Moby Dick", year: "1999"
<FromGitter> <drujensen> that looks great
<FromGitter> <Blacksmoke16> the update method might be hard to handle
<FromGitter> <Blacksmoke16> well not too bad, less than idea tho
<FromGitter> <drujensen> question, can we have a macro create the initialize method?
<FromGitter> <Blacksmoke16> thats what its doing atm yes
<FromGitter> <Blacksmoke16> use wouldnt have to define that
<FromGitter> <Blacksmoke16> user*
<FromGitter> <drujensen> ```def initialize(@title, @author, @year, @published)```
<FromGitter> <Blacksmoke16> neg
<FromGitter> <Blacksmoke16> dont have access to ivars outside of a method
<FromGitter> <drujensen> the macro wouldn’t need access
<FromGitter> <Blacksmoke16> how you going to know what the ivars are?
<FromGitter> <drujensen> it just needs to generate the method, no?
<FromGitter> <Blacksmoke16> right but you dont know what they are
<FromGitter> <drujensen> don’t we have a list?
<FromGitter> <Blacksmoke16> not anymore since we arent using the mutable constants
<FromGitter> <drujensen> i thought you could query the annotations to get the list
<FromGitter> <Blacksmoke16> yes but has to be within the context of a method
<FromGitter> <drujensen> not in a macro
<FromGitter> <Blacksmoke16> otherwise `@type.instance_vars` returns an empty array
<FromGitter> <drujensen> kk
<FromGitter> <Blacksmoke16> i mean if you have an idea give it a try
<FromGitter> <drujensen> you are the king of annotations. lol
<FromGitter> <drujensen> i trust you when you say you can’t get access to them. ;-)
<FromGitter> <Blacksmoke16> might be able to not make columns nilable by default as well with this
<FromGitter> <Blacksmoke16> but save that for another day
<FromGitter> <drujensen> what does the `verbatim do` do?
<FromGitter> <Blacksmoke16> know about the like `\{{some macro code}}` syntax?
<FromGitter> <Blacksmoke16> basically its an alternative to that, just a bit cleaner
<FromGitter> <Blacksmoke16> yea im on a roll
<FromGitter> <Blacksmoke16> ```code paste, see link``` [https://gitter.im/amberframework/amber?at=5d969a450e67130aae0dc565]
<FromGitter> <Blacksmoke16> yea this is pretty great
<FromGitter> <Blacksmoke16> ill make a draft PR prob tomorrow/weekend
fyber has joined #amber
<FromGitter> <drujensen> @Blacksmoke16 nice work!
_whitelogger has joined #amber
<FromGitter> <Blacksmoke16> im actually thinking it would be better to keep properties nilable by default?
<FromGitter> <Blacksmoke16> but have getter/setter mask that fact, or maybe catch it in the initializer
<FromGitter> <Blacksmoke16> mainly so you could hydrate only some properties i.e. specific fields on select, or if working with APIs you might not want to read properties from the JSON body, leaving them nil but would be set at some point shortly after
<FromGitter> <sclee15> Does Granite supports the virtual field?
<FromGitter> <Blacksmoke16> i.e. a property that isnt a column?
<FromGitter> <Blacksmoke16> yes, just use `property` vs `column`
<FromGitter> <sclee15> Oh that is good to know. thank you.
<FromGitter> <sclee15> @Blacksmoke16
<FromGitter> <eliasjpr> @Blacksmoke16 devs should be able to define what can be nil and what not
<FromGitter> <eliasjpr> It might cause side effects if we default to nil
<FromGitter> <sclee15> can a property in a granite model serialized automatically?
<FromGitter> <eliasjpr> Serializer to Json, yaml yes
<FromGitter> <sclee15> oh..
<FromGitter> <sclee15> than I can use a property as a virtual column.
<FromGitter> <sclee15> I tried a property in a granite model, and I think set_attributes seems not aware a property that is manually created.
<FromGitter> <Blacksmoke16> correct
<FromGitter> <Blacksmoke16> that only sets columns
<FromGitter> <Blacksmoke16> @eliasjpr i more so mean keep it how it works now, where the properties are nilable internally, but the getters/setters we define prevent it
<FromGitter> <Blacksmoke16> otherwise you couldnt do `Model.new`, or say you want to only select a few columns
<FromGitter> <Blacksmoke16> maybe that would be the more ideal behavior? im not sure yet
<FromGitter> <eliasjpr> I think it should behave the same as with the property, getter, setter keywords
<FromGitter> <Blacksmoke16> thats how i have it now, where it just uses default property macro
<FromGitter> <Blacksmoke16> but i feel like that would be harder to work with
<FromGitter> <Blacksmoke16> ill play with it more