<FromGitter>
<ninetailschris> Yes it follows that order structure.
<FromGitter>
<bew> @eliasjpr we have some of the same problem in Crystal... :/
<FromGitter>
<girng> shouldn
<FromGitter>
<girng> i've always used a class or struct to represent elements especially for a game. @omarroth if you do it like that, is it more performant?
<FromGitter>
<girng> i assume you would just need to write out the indices, and which one represents in a comment or something
<FromGitter>
<girng> for example, array[0] would be health, and array[1][0] would be strength, and array[1][1] would be dex?
<FromGitter>
<omarroth> I'm wondering if you can do that with JSON.mapping
<FromGitter>
<Blacksmoke16> JSON.mapping is deprecated afaik
<FromGitter>
<girng> wait what is it really
<FromGitter>
<omarroth> I didn't know that @Blacksmoke16
<FromGitter>
<girng> what happened to it??
<FromGitter>
<Blacksmoke16> im pretty sure yea...
<FromGitter>
<Blacksmoke16> got replaced by the JSON::Serializable stuff
<FromGitter>
<omarroth> Gotcha
<FromGitter>
<girng> well, oprypin's everything_macro will not die in vane!
<FromGitter>
<Blacksmoke16> @omarroth why not just use a class...
<FromGitter>
<Blacksmoke16> would be the better way to do things
<FromGitter>
<Blacksmoke16> oh sorry that was example for someone else
<FromGitter>
<Blacksmoke16> @ninetailschris wouldnt it be better to have a class with like `name`, `damage` etc properties?
<FromGitter>
<girng> that's what i do, especially if you want to change a property
<FromGitter>
<Blacksmoke16> also would get type safety that way
<FromGitter>
<girng> you don't have do the entire new array
maxpowa has quit [*.net *.split]
jim80net has quit [*.net *.split]
jokke__ has quit [*.net *.split]
jetpack_joe has quit [*.net *.split]
z64 has quit [*.net *.split]
<FromGitter>
<bew> Iirc @ninetailschris is reading that array from a json
<FromGitter>
<Blacksmoke16> still could use a class and use the `.from_json` method
<FromGitter>
<ninetailschris> @Blacksmoke16 This is in the database,
<FromGitter>
<girng> imo, that data is being stored the wrong way
<FromGitter>
<Blacksmoke16> im sure there's a reason but yea prob not the most optimal way :/
<FromGitter>
<omarroth> That's fair enough, I think @ninetailschris is looking to migrate his existing project though
<FromGitter>
<Blacksmoke16> getting the database into a better spot would be my top priority imo, then you could use a nice ORM lib to much more easily access/edit that data
<FromGitter>
<Blacksmoke16> might also be able to use STI for "class" specific attributes
<FromGitter>
<Blacksmoke16> like the `has_wings`
<FromGitter>
<Blacksmoke16> but hey, whatever works :p
<FromGitter>
<omarroth> @ninetailschris here's a quick and dirty solution: https://carc.in/#/r/4u2l
<FromGitter>
<ninetailschris> In ruby the performance from doing this was very little because of how it handle json objects and was actually faster. With crystal because of how it handle JSON objects it could be worst. I'm moving a database so I have to work with structure of the game I made with Jruby. If the game was being made from the ground up with crystal it would have been done differently. ;)
<FromGitter>
<omarroth> That's understandable, I'm glad you picked Crystal :)
maxpowa has joined #crystal-lang
_whitelogger has joined #crystal-lang
<FromGitter>
<Blacksmoke16> yea all good, #grrlegacy
<FromGitter>
<j8r> Honestly, better to use Kemal. OK it's more bloated, but we can improve the performance. Furthermore the creator @sdogruyol is a core member of Crystal
sevensidedmarble has quit [Ping timeout: 250 seconds]
Raimondii has joined #crystal-lang
ashirase has quit [Ping timeout: 252 seconds]
Raimondi has quit [Ping timeout: 240 seconds]
Raimondii is now known as Raimondi
ashirase has joined #crystal-lang
thews has quit [Read error: Connection reset by peer]
thews has joined #crystal-lang
DTZUZO has joined #crystal-lang
dannyAAM has quit [Ping timeout: 276 seconds]
dannyAAM has joined #crystal-lang
zorp has joined #crystal-lang
sevensidedmarble has joined #crystal-lang
<FromGitter>
<vlazar> > feel free to review my second attempt at updating TFB benchmarks to latest Crystal & frameworks https://github.com/TechEmpower/FrameworkBenchmarks/pull/4020 ⏎ ⏎ In terms of performance there will be more recent benchmarks results soon. As far as I know the latest Kemal release should be faster. I'm waiting for Amber guys to release new version of Granite ORM with performance fix and then we can see the
<FromGitter>
<j8r> I've the results, which one is import in all this files?
<FromGitter>
<vegai> so a bit of pointless controversy: does the language really need both { … } and do … end -constructs?
<FromGitter>
<j8r> I hate that they 1. Build containers on my machine 2. Use Ubuntu Xenial 3. Let the files as root on my FS (don't chown to 1000:1000). ⏎ Except that, that's nice
<FromGitter>
<Timbus> @vegai I would argue not, but overall ruby does not hold a very consistent approach when it comes to blocks
<FromGitter>
<asterite> Vesa: not strictly, but they do have different precedences
<FromGitter>
<Timbus> so different situations call for different syntax, i guess.
shalmezad has joined #crystal-lang
<FromGitter>
<j8r> @vlazar what results are relevants?
<FromGitter>
<vegai> @Timbus yeah, but this is not ruby :P
<FromGitter>
<vegai> personally, I’d drop the {}s
<FromGitter>
<j8r> but we can do nice short one liners with
<FromGitter>
<vegai> indeed
<FromGitter>
<j8r> or drop `do; end` for blocks (all the community will be against, maybe also me)
<FromGitter>
<codenoid> i feel excited when coding with crystal
<FromGitter>
<codenoid> from now
<FromGitter>
<codenoid> i will focus in crystal
<FromGitter>
<codenoid> for job, hobby, etc
<FromGitter>
<j8r> you find jobs in Crystal?
<livcd>
some companies allow you to write in whatever you want :)
<FromGitter>
<codenoid> yeah @livcd
<FromGitter>
<j8r> not sure this are the best companies, if everyone write in whatever they want. ⏎ That's OK if we are alone, but it's better to be in a team that being the only dev
<livcd>
yes but finding a reasonable good company is hard
<FromGitter>
<asterite> So, right now you can write `puts [1, 2, 3].map { |x| x + 1 }`. With only `do/end` you'd have to write `puts([1, 2, 3].map do x + 1 end)` (note the parentheses, which will now be necessary in this case)
<FromGitter>
<codenoid> actually not company xD but goverment
<livcd>
what is the biggest blocker for Windows support atm ?
<FromGitter>
<j8r> you mean `puts([1, 2, 3].map do |x| x + 1 end)` @asterite ⏎ If the parentheses could be removed in the future, personally I won't be against removing `{}` blocks. I don't know if there are mandatory now?
<FromGitter>
<asterite> if you write `puts [1, 2, 3].map do |x| x + 1 end`, right now the `do` is attached to `puts`, not to the array literal. This is the precedence I mentioned before. That's why you would need the parentheses in this case
<FromGitter>
<asterite> Of course the rule can be changed so that `do` always attached to the closest identifier, btu then you won't be able to do `fancy_dsl var do`, because it would be parsed as `fancy_dsl(var do ...`. I think that's the reason `do/end` and `{...}` exist in Ruby
<jokke>
hey! i still have this problem:
<jokke>
instance variable '@schemas' of OpenAPI::Components must be (Hash(Symbol, OpenAPI::Reference | OpenAPI::Schema) | Nil), not Hash(Symbol, OpenAPI::Schema)
<jokke>
what am i doing wrong? :/
<FromGitter>
<vegai> I think people who really want to use Crystal should found their own companies to do it
<FromGitter>
<vegai> going ninja in an existing organization might work, but is always a bit shady
<FromGitter>
<vladfaust> Why are big guys so afraid of non-1.0? Having a hand on the language pulse and adapt existing projects to the changes is easy-peasy
<FromGitter>
<bew> With your last example you're creating a `
<FromGitter>
<bew> `Hash(Symbol, OpenAPI::Reference | OpenAPI::Schema)` and fill it with a Symbol & OpenAPI::Schema
<FromGitter>
<bew> So this works
<jokke>
but shouldn't the typesystem recognize Hash(Symbol, OpenAPI::Schema) to be a subtype of that?
<FromGitter>
<bew> No, there is no subtype mechanism
<FromGitter>
<vegai> @vladfaust I think technical leads are afraid of letting people use whatever language they want because that just leads to every language appearing in the organization eventually
<FromGitter>
<vegai> because there just isn’t any language that everybody is happy with, for some reason
<FromGitter>
<bew> Problem is that with generics, the types are really different, and are layed out differently in memeory
<jokke>
well but foo(bar : Array | String) will work with either an array or a string
<FromGitter>
<vladfaust> But Crystal is *objectively* the best :)
<jokke>
hm ok
<FromGitter>
<bew> @jokke
<jokke>
is there no way around this?
<FromGitter>
<vladfaust> *cough* slack for topics *cough*
<FromGitter>
<asterite> jokke not a bug
<FromGitter>
<bew> @jokke you have to create a hash of the correct type, or recreate it
<jokke>
mh :/
<FromGitter>
<bew> Maybe you can do `hash.transform_values &.as(OpenAPI::Reference | OpenAPI::Schema)`
<FromGitter>
<asterite> there's no subtyping relationship between, for example, Array(X | Y) and Array(X). If you could assign Array(X) to Array(X | Y), then you could insert an Y into it, which is wrong. It's explained in several of the issues in Github (but not in the docs :/). Search for covariance and contravariance
<jokke>
sure
<jokke>
that makes sense now that you put it that way
<jokke>
my bad
<FromGitter>
<asterite> That said, we could also allow array/hash literals to automatically cast in this case, so that would be a feature
<FromGitter>
<asterite> I think this is one of the trickiest thing in statically typed languages with generics... I wish it were simple
<jokke>
asterite: do you know of any macro magic that would allow me to write an initializer which would yield and let me assign instance vars which are not nilable and so on compile time fail if i don't assign all the required ones?
<FromGitter>
<asterite> No
<jokke>
mmh
<jokke>
any way to "build" named tuples?
<jokke>
(at compile time)
<FromGitter>
<j8r> with a macro
<jokke>
yeah but how?
<jokke>
it would have to use method_missing somehow to assign values to keys
<FromGitter>
<j8r> don't you want to generate instance properties instead?
<jokke>
well no because the structure is fixed
<jokke>
basically what i'm trying to do: write a type safe dsl to describe a fairly complex nested data structure
<jokke>
this would be pretty easy to do if everything would be nilable
<jokke>
but i don't want to make it so
<FromGitter>
<asterite> Yeah, that's the main drawback of the strictness of crystal
<jokke>
yeah but it's totally understandable
<FromGitter>
<asterite> In C# you can provide a default constructor and then do `new Obj { Foo =1, Bar = 2 }`
<FromGitter>
<asterite> Just make everything nillable and use `property!` :-)
<jokke>
that's a runtime check
<FromGitter>
<asterite> it's not that terrible, specially when it's about creating a configuration object
<FromGitter>
<asterite> it either fails fast at compile-time, or fails fast at runtime when you boot the app
<jokke>
it's not terrible, no
<jokke>
but it'd be soooo cool if it worked during compile time
<FromGitter>
<asterite> what about that `initialize` that uses double splat?
<FromGitter>
<asterite> Or, you can define an initialize with all required named arguments, and use ` = nil` for those that are nillable, and that's it
<FromGitter>
<asterite> It's a bit tedious to define, but it works
<FromGitter>
<yxhuvud> @asterite btw, did you see the golang plans on generics for 2.0 posted yesterday?
<jokke>
asterite: yeah i have a double splat initializer
<FromGitter>
<vlazar> > @vlazar what results are relevants? ⏎ @j8r Not sure what do you men. Have you tried running TFB on your machine and trying Kemal with and without your changes? The results on TFB servers might be different. Actually TFB setup didn't worked for me out of the box so I'm just compiling and running everything locally without Docker.
<FromGitter>
<vlazar> I have no idea how to build charts from plain JSON results but there can be a doc somewhere on TFB site.
<FromGitter>
<asterite> I need to improve the error message, I'd like macros errors to bubble to the caller
<FromGitter>
<asterite> @yxhuvud Yeah, I saw the news about generics in Go. Exciting!
<FromGitter>
<vlazar> btw will it be a crazy idea for HTTP::Server to always add Date header by default?
<FromGitter>
<j8r> yes
<FromGitter>
<j8r> what you should i see, there are files in the results folder
<FromGitter>
<j8r> I'll check their site
sevensidedmarble has joined #crystal-lang
Raimondi has quit [Read error: Connection reset by peer]
<FromGitter>
<j8r> Doesn't appear to have much differences
Raimondii has joined #crystal-lang
Raimondii is now known as Raimondi
<FromGitter>
<paulcsmith> @asterite When you say macro errors to bubble to the caller, do you mean that the last line in the build error would be the caller instead of the expanded macro? If so, that would be awesome!
<FromGitter>
<asterite> @paulcsmith Right, in https://play.crystal-lang.org/#/r/4u9b I'd like the error to just mention "missing named argument: y", without showing the expanded macro. I think when a user uses `raise` inside macros, it's because they want to show an error similar to one of the compile-time errors the compiler shows. Then, if there's a bug in the macro, like, you try to invoke an unknown macro method, or the macro
<FromGitter>
... turns out to be invalid, it would show the expansion
<FromGitter>
<asterite> remove the commans in %i[ ... ]
<jokke>
oh gawd
<jokke>
i'm so stupid xD
<FromGitter>
<paulcsmith> @asterite Yeah that sounds awesome!
<jokke>
this happens to me all the time
<FromGitter>
<paulcsmith> Or even if there is a bug in the macro, it might be nice to show the calling method at the bottom, so you see what you wrote and *then* the expanded macro
<FromGitter>
<paulcsmith> @robacarp Yeah same with ECR or any longish macro. I think the debug output should also be constrained to expanding 10-15 lines before and after the line that caused an error. You usually don't need everything. And then maybe an option to `--expand-macros-on-error` or something so you can fully expand if you really need it
<robacarp>
@paulcsmith yess. 700 lines of context is often overzealous
<FromGitter>
<paulcsmith> Yeah. That combined with the caller being above that text is probably the hardest thing for people when using Crystal/Lucky. The real error is often buried pretty high up. Maybe I'll create a bounty because I'd *love* to see this improved. It'd make things way nicer!
<FromGitter>
<j8r> there is `{% debug %}` already for that @paulcsmith
<FromGitter>
<paulcsmith> Sorry, I didn't explain well. I mean that people get confused by the debug output
<FromGitter>
<j8r> that was only for the `--expand-macros-on-error` proposal :)
<FromGitter>
<paulcsmith> Because it is long and it is from code they didn't write. Also because the caller is *above* the macro output which makes it hard to find. People (myself included) have. a hard time finding the real cause of the error
<FromGitter>
<paulcsmith> @j8r Oh I see
<FromGitter>
<j8r> Yes totally agree, would be awesome
<FromGitter>
<paulcsmith> That works if the macro is in your code, but what if it is in a shard?
<FromGitter>
<paulcsmith> In that case you can't easily throw in a debug. For your own code though I agree that works great 👍
<robacarp>
one thing I've started doing (outside of macros) to help avoid the backtrace confusion is to type-hint public API parameters on libraries, which makes the compiler enforce the correct typing
<robacarp>
unfortunately that doesn't work with duck-typing
<robacarp>
but as it may be several layers deep that a library calls some method on an input object, and a library user tracing back through 16 function calls to where the codepath enters the library isn't an obvious step
<FromGitter>
<paulcsmith> @robacarp I've noticed the same and have tried doing that. Sometimes the problem is in the macro where you can't add a type restriction. That's where I've had trouble. Would be cool if you do something like `macro something(name : StringLiteral)`
<FromGitter>
<paulcsmith> One though for duck typing might be to use generics with a module. That's what I did with carbon. There is an Emailable module you can include in anything so you still get a form of duck-typing but it is still flexible and type safe
<z64>
is it expected that integer literals are autocast to float64 when restricting to an alias that has float64 as a member? https://carc.in/#/r/4uaz i can kind of understand why it happens, but its kind of a POLA issue
<z64>
(may happen in other ways, this is just one example)
<FromGitter>
<bew> Huh that's interesting, you're good to open an issue i guess
<FromGitter>
<ExplodingBanana> Hey, when Crystal'll be on Windows?
baweaver_away is now known as baweaver
<FromGitter>
<girng> WSL :D
<FromGitter>
<girng> @jokke and i thought i had trouble understanding compile issue threads on github... your code is something else omg lol
<FromGitter>
<girng> i have absolutely no idea wtf is going on. however, i do know it's a macro and there is some json stuff going on there
<FromGitter>
<fridgerator> @ExplodingBanana Its being worked on mainly by rx14, he would know the status
<FromGitter>
<fridgerator> There is progress being made though
<FromGitter>
<girng> @ExplodingBanana i know WSL isn't what u want, but i use it with crystals and it's been working great for a year+. so if u don't want to wait for windows port there is always WSL to hold u over until then
<FromGitter>
<ExplodingBanana> I'm already on WSL, but I wanna Windows version
<FromGitter>
<ExplodingBanana> Cuz WSL is *sorry* shit for such things
<FromGitter>
<girng> i see.
<FromGitter>
<girng> this dos deflate script i wrote in crystal is amazing, works sooo nice
<FromGitter>
<girng> maybe i can put it up on github and people can contribute and make it even better??
<FromGitter>
<j8r> snake case isn't enforced for method names?!
<FromGitter>
<girng> used to be wasn't it
<FromGitter>
<j8r> Because i see @vegai taking the liberty to use CamelCase on methods haha 😄
<FromGitter>
<girng> i thoght that only worked for classes?
<FromGitter>
<girng> i thought method names had to be lowercase
<FromGitter>
<j8r> That's the standard, but not enforced for methods name – they can have caps
<FromGitter>
<j8r> That's not really CamelCase, but camelCase
<FromGitter>
<girng> letter starts with, has to be lowercase right?
<FromGitter>
<j8r> yes
<FromGitter>
<girng> oh ok yeah
<FromGitter>
<girng> what's the difference between camelCase and CamelCase?
<FromGitter>
<girng> besides the first letter
<FromGitter>
<girng> wait. what I mean is, why do method names have to start with a lowercase letter? but they also accept uppercase too. is it to differentiate them between Classes?
<FromGitter>
<j8r> Yeah that's weird
<FromGitter>
<j8r> They should only allow lowercase and some specials symbols.
<FromGitter>
<j8r> BTW most already do that :)
<FromGitter>
<girng> well, it's too late my mind is fixated when i create a method it's all lowercase lol
<FromGitter>
<girng> i use a underscore '_' though
<FromGitter>
<girng> oh, u can do `when` and `then` in one line?
<FromGitter>
<j8r> You interpret a string to execute actions in your game?
<FromGitter>
<j8r> Yes ;)
<FromGitter>
<j8r> You code will look better with thens, IMO
<FromGitter>
<j8r> Each action are
<FromGitter>
<girng> yah, but this is just for my master server. for my tick rate one, opyprin said i should use enum check instead of checking on string
<FromGitter>
<j8r> close
<FromGitter>
<girng> it's faster i guess
<FromGitter>
<j8r> If you have the choice, yes totally
<FromGitter>
<j8r> In my side I must do this because that's YAML
<FromGitter>
<girng> i did some json parse benchmarks
<FromGitter>
<j8r> Checking strings (with slices) vs a signature,
<FromGitter>
<girng> shit is still insanely fast so i'm reallyu not that included to switch to enum for cmd, but for the gameserver with tick rate i might do it and benchmark it with a tick rater
<FromGitter>
<j8r> You have also type safety
<FromGitter>
<j8r> You can't check an unimplemented
<FromGitter>
<z64> hi @asterite . was just looking at the diff for that PR you just opened, and just wanted to ask before opening an issue since i saw some comments in the code that made me doubtful: i posted this earlier; https://carc.in/#/r/4uaz - is this intentional or it can be improved?
<FromGitter>
<girng> @j8r in my case, my type safety is checking if it's a string or not? LOL
<FromGitter>
<j8r> Haha, the string could be false. The Enum can be reused :)
<FromGitter>
<girng> checking if enum is a number is faster than checking if a string matches a certain word, right? cause internally the language has to loop through the characters??
akaiiro has joined #crystal-lang
<FromGitter>
<asterite> @z64 it's a bug, it should never be possible to invoke it with a literal that's not either a Float64 or Int64, please report it
<FromGitter>
<j8r> Essentially I think so. Checking an enum only involve some sort of signature checking
<FromGitter>
<asterite> that is, `foo(1)` shouldn't compile either
<FromGitter>
<DanielSokil> Are there any Crystal bindings for rethinkdb?
<FromGitter>
<girng> what happens here? https://carc.in/#/r/4ucu what does "int: " mean now? Does the union types take precedent over the parameter types?
<FromGitter>
<j8r> That's the argument name
<FromGitter>
<j8r> And Alias represents an Union of Types
<FromGitter>
<girng> so union of types takes precedent over argument naming (safe to say?)
<FromGitter>
<plainas> @j8r it looks like the developer/reviewer didn't bother as it was only minor formating/style changes, not new features. Nothing wrong with your pull request, don't get me wrong.
<FromGitter>
<plainas> but yeah, not much activity there
<FromGitter>
<z64> @asterite will do! thank you :)
<jokke>
giring: haha, uncomprehencible code isn't a thing i would brag about though :D Right now it just does it's job. The important part is the way it can be called in the bottom. I will post a little screencast to make it clear :P
<atna>
Could someone explain why this fails with "Don't recognise LiteralText"?
<atna>
SEEMS like pretty straightforward code, and it SEEMS like what it's printing is the value I'm checking for in the case.
<FromGitter>
<drosehn> Hmm. Would it cause problems if I was trying to upgrade from `crystal 0.25.1` (not 0.26.0) to `crystal 0.26.1`?
<FromGitter>
<drosehn> ... this using `brew` on macOS 10.11.6 (El Capitan).
<atna>
Doubt it drosehn.
<FromGitter>
<girng> @jokee most of it is my fault as well because i'm still learning new things w/ crystal
<FromGitter>
<girng> i'm transcending, but it'll be a while before i can flourish
<atna>
No one sees any problem with the above code? It can't be a compiler bug on something as simple as case-checking enum values, I suppose.
<FromGitter>
<drosehn> okay. well, I'll have to try the upgrade again sometime later on and try to figure out what the problem is. Classes start tomorrow at the college I work at, so I'm a bit too busy to investigate it right now.
<atna>
Unless it's how I'm defining some member variables in initialize, and another in the class definition?
<atna>
Can I do that?
<atna>
Using a class definition to override an initialize() definition, that is?
<atna>
Hmm. Tried it with only initialize args. Didn't help.
akaiiro has quit [Ping timeout: 260 seconds]
<oprypin>
atna, u probably meant `case node.@type` ???
<oprypin>
also im pretty sure this enum is entirely unneeded
<atna>
I literally just found the same thing. Thanks :)
<atna>
Umm... it might be, now that you mention it, yeah :D Guess I wrote that before making the thing a class hierarchy.
<FromGitter>
<drosehn> It's the nature of bit-value flags.
<oprypin>
girng it's so that the first value is 0b0001, 2nd is 0b0010, 3rd is 0b0100, etc
<oprypin>
girng, then you can combine them: 0b0001 | 0b0100 == 0b0101
<FromGitter>
<girng> bitwise OR?
<FromGitter>
<girng> interesting
<FromGitter>
<drosehn> you want to store each flag as a single bit with a larger area (usually a byte or an integer). And the most-compact way to do that is to multiply values by 2, so each flag effects one-and-only-one bit in the larger area.
<oprypin>
girng, but you dont need to think about this bitwise OR, flags enum hides it as an implementation detail
<FromGitter>
<girng> ok I think i got it. for example oprypin the gameserver cmds u helped me with, we don't really need to rely on the flags then
<FromGitter>
<girng> since it's just reading 1 command not more than 1
<oprypin>
right
<FromGitter>
<girng> ok, well that's sufficient enough for me. appreciate help. if i run into more problems later i'll ask but im not gonna fiddle with flags for now lol
<FromGitter>
<girng> and speaking of enums i just realized godot engine has them rofl. never even knew
zorp has quit [Ping timeout: 245 seconds]
<FromGitter>
<girng> https://play.crystal-lang.org/#/r/4uf6 ⏎ ⏎ how do i get the fooditem by value? for example, if someone sends input `1` it should correspond to `Apples`. i know oprypin told me how along time ago but i lost the code and can't find his link in gitter search
<FromGitter>
<Timbus> Well, I prefer self.name, as using `@name` means you don't get the abstracted getter behaviour, and using `name` won't work when you try to assign something to it.
<FromGitter>
<Timbus> but I mean, just do whatever
Raimondii has joined #crystal-lang
<FromGitter>
<bew> @Blacksmoke16 `name` and `self.name` will call the getter method, `@name` will access the attribute directly
Raimondi has quit [Ping timeout: 240 seconds]
Raimondii is now known as Raimondi
<FromGitter>
<drosehn> The difference can also be significant if you're subclassing a class, and the subclass wants to override the getter method of the original class.
<FromGitter>
<girng> difference between `property name = "Foo"` vs `property name : String = "Foo"`?
<FromGitter>
<drosehn> Random observation: it seems like `@[Flags]` is mainly meant for working with external functions written in C (such as functions in LibC). As near as I can tell, they're rather verbose to use in plain crystal code.
<FromGitter>
<bew> @drosehn it's not only to interact with C code, it's good practice to use them when you need to represent one or more thing of these things, as oprypin said well
<FromGitter>
<girng> well, i will use `property name = "food"` then, cause i don't feel like i need to re-write String when i already used quotes
<FromGitter>
<girng> it's already implied it's a string so i should be ok i think
<FromGitter>
<Blacksmoke16> @bew thanks :)
<FromGitter>
<Blacksmoke16> is there a cases when one way is better than another?
<FromGitter>
<Blacksmoke16> or in most cases prob best to just use `name`
<FromGitter>
<drosehn> I don't mean to suggest that I do not like them. I'm just saying that they don't seem to be used much in the compiler's source, and that the way crystal implements them seems a bit clunky. It is very likely that I'm just missing something.
<FromGitter>
<drosehn> I use enum's a lot in other languages. It happens that I haven't tried to use them in crystal until the earlier question got me curious about how they work in crystal.
<FromGitter>
<drosehn> well, I should be specific there, and say "flags" instead of "enums".
<FromGitter>
<drosehn> Maybe ignore my rambling for awhile. I think I'm just doing it wrong.
<FromGitter>
<girng> nah, i like to read it. i'm just to new to enums and love to read as much as i can about it =]
<FromGitter>
<drosehn> Well, it won't be very helpful if what I'm saying is wrong!! 😄