<BlaXpirit>
RX14, well these are basically globals then anyway
<RX14>
...yes
<RX14>
so are class vars
<RX14>
as the issue stated multiple tmes
<RX14>
this is not about removing mutable global state
<RX14>
just global vars
<BlaXpirit>
so, again, what is the problem with globals specifically if class variables are globals too?
<RX14>
class vars have a defined initialization and typing point
<BlaXpirit>
solution: require globals to have the same
<RX14>
it looks to me like you didn't read it all
<RX14>
do you really want def $foo syntax?
<RX14>
i don't
<BlaXpirit>
why def
<RX14>
it looks ugly in ruby
<RX14>
BlaXpirit, because what other initializer syntax is there
<BlaXpirit>
$asdf : Thing = make_thing()
<RX14>
so the first asignment?
<BlaXpirit>
this is not an assignment, it's a declaration
<BlaXpirit>
could drop the '='
<RX14>
what if you want to leave off the global var's type
<FromGitter>
<drosehn> For my purposes, getting rid of global variables isn't really going to be much of an issue. I took a simple program which had a few dumb global variables, added a `module` and `end`, changed the $-variables to @@-variables, added setter/getter methods, and it worked fine.
<RX14>
then it's an assignment
am_ has joined #crystal-lang
<FromGitter>
<drosehn> That might sound like a lot, but it was more work to type in that description than it was to make the changes to my script... :)
<RX14>
again, it only affects hacky scripts which is ruby's market
<BlaXpirit>
drosehn, these silly changes is exactly what I don't want because there is no meaning behind this
<RX14>
plus the workaround is easy
<RX14>
BlaXpirit, yes there is - again it seems like you havent read the issue
<BlaXpirit>
goddammit what do you want from me
<BlaXpirit>
i'm not saying class variables can't be used for global state, i'm saying it's stupid
am_ has quit [Client Quit]
am_ has joined #crystal-lang
<RX14>
and i'm saying that the technical issues are most of the reason why
<FromGitter>
<drosehn> <shrug>. It's a good idea to drop globals, even if it causes a tiny bit of extra work in a few cases. The larger the program, the more trouble you'll have from global variables. That's been true in my experience, at least. And crystal is geared towards larger programs, not small scripts. I do not see it as problem to get rid of $-variables for smaller programs.
<RX14>
the compiler needs to tell the difference between declarations and assignments of global variables
<RX14>
it's clear for class vars
<RX14>
it's not for global vars
<BlaXpirit>
yes, but it's not a reason to drop global variables
<RX14>
yes it is because it makes it incredibly difficult for global variables to work in the compiler
<FromGitter>
<drosehn> I did ponder the issue when asterite brought up the idea of dropping $-variables, and after a few hours of thinking about it (and a good night's sleep!), I gave a thumbs-up to the idea.
<am_>
without globals, main function will need to pass the "ideally globals" to all function it calls, which in turn will need to do the same, possibly caring for "ideally globals" variables which doesn't use, but are used on the level below
<am_>
either you have some Rust paranoid attitude, or it's a bad idea wiping out the globals
<RX14>
no, this is not about removing global state
<BlaXpirit>
RX14, it's about removing the reasonable way to have global state
<RX14>
for flips sake it means declaring one module and using macros to declare your global vars
<RX14>
it's not an appreciably large amount of extra effort
<RX14>
and it's cleaner AND much easier for the compiler devs
<RX14>
whereas you needed to write `$x = 0` you write `property self.x = 0`
<BlaXpirit>
and come up with a meaningless wrapper
<BlaXpirit>
i can only hope that in reality i'd be able to come up with some meaningful name for the wrapper
<RX14>
you have to name the file you're working in anyway
<RX14>
the module can be the same
<FromGitter>
<drosehn> how about `class Globals` ?
<RX14>
even that if you're lazy
<BlaXpirit>
that's the worst class name i've seen in my life
<RX14>
it's a hacky script if you're using global vars anyway
<FromGitter>
<drosehn> Obviously you haven't seen programs I have written! :)
<RX14>
so it really doesn't matter
<BlaXpirit>
RX14, there are legitimate global resources, like a texture
<RX14>
and if it's a serious program they will be class vars or constants
<BlaXpirit>
i hope that such global resources can actually be constants instead
<BlaXpirit>
they will not be class vars because even two instances of an application don't need separate copies of a texture
<RX14>
if you're using global vars in anything more than single-file prototyping you're doing it wrong imo
<FromGitter>
<drosehn> Though more seriously, I found that if I did have a lot of global variables, that I soon wanted to group them. "These ten global variables are for one thing, and these other ten are for something totally unrelated to that". So I'd end up moving the globals into classes just for name-space reasons.
<BlaXpirit>
uh wait what nevermind what I just said
<RX14>
yeah
<RX14>
class vars == namespaced globals
<RX14>
its that simple
<FromGitter>
<drosehn> yep.
<RX14>
except for a few differences which make it hard to compile
<BlaXpirit>
welp, onto my next pet peeve. I don't like how it's difficult to use functions without putting them in a class
<BlaXpirit>
because functions can't reference top-level variables
<BlaXpirit>
it's a bit related to globals because top-level variables and globals are synonymous in Python
Oliphaunte has quit [Remote host closed the connection]
<BlaXpirit>
again, it's for simple scripts, but this leaves few good alternatives
<FromGitter>
<drosehn> do you mean module-level @@-variables? it's easy enough to reference them.
<BlaXpirit>
no I mean a script where you write a = 5 without any indentation
<RX14>
no, local vars in the top level scope
<BlaXpirit>
these will feel out of place because they remain the only first-class items at the top level, if that makes any sense
<FromGitter>
<drosehn> dunno. I'm not having any problems with it.
bjz has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<BlaXpirit>
they can't be referenced in any inner scope
<BlaXpirit>
but again this is only weird to me because I'm used to nested scopes, but Crystal has basically one scope
<BlaXpirit>
that is - local to the current method
<RX14>
it has lexical scopes in the method, with a class scope that can be accessed via alternate syntax
<RX14>
only constant (incl. class, module) lookups really use nested scopes
<BlaXpirit>
finally I understand what seems off
<RX14>
i like how it works
<RX14>
because it encapsulates well
<RX14>
it encourages good code
<BlaXpirit>
everything that you define in a function can be accessed in the nested lexical scopes
<RX14>
when you're making a hacky script in crystal you can really feel it
<BlaXpirit>
however if you're at the top level, not everything you define can be seen inside functions
<RX14>
the top level is essentially it's own function
<BlaXpirit>
top level is too special of a case. on one hand you feel like in a function but you're not because you can define functions inside it
<RX14>
yeah top level is interesting...
<BlaXpirit>
I just checked that you can define a function inside a function in ruby, but it seems to be pointless?
<BlaXpirit>
oh they're not nested, you're still defining it at top level. well then...
<RX14>
yeah ruby is weird
<BlaXpirit>
if this top level is just as weird in ruby, then I suppose I should drop all my concerns
<BlaXpirit>
thanks
<bjmllr>
the ruby toplevel is weirder
<BlaXpirit>
right
<FromGitter>
<drosehn> it isn't really all that weird, once you get comfortable with the idea that everything is an object.
<BlaXpirit>
drosehn, please... functions are not objects
<RX14>
neither is everything an object in crystal
<BlaXpirit>
i'm actually too used to a language where everything is actually an object, sometimes i can't get over functions not being them in ruby
<RX14>
numbers are not *really* objects in crystal
<RX14>
they look like them
<RX14>
in that they have methods and you can reopen the class
<RX14>
but they are not
bjz has joined #crystal-lang
bjz has quit [Client Quit]
<BlaXpirit>
top level feels especially strange because a `require` can lead to code execution
<FromGitter>
<cjgajard> BlaXpirit, methods ARE objects in Ruby, but to access that object you have to use `method(function_name_as_symbol)`
<RX14>
you can pass around methods now?
<RX14>
without making them procs?
* BlaXpirit
puts 4 spaces in front of a big chunk of code and sighs
<bjmllr>
`method(:puts)` will give you an instance of `Method` describing `puts` but it's not "the puts method". you'll get a different `Method` each time. you can `call` it like a proc though.
<bjmllr>
in ruby
<RX14>
huh
bjz has joined #crystal-lang
bjz has quit [Max SendQ exceeded]
bjz has joined #crystal-lang
bjz has quit [Ping timeout: 244 seconds]
<jhass>
RX14: conceptually numbers are objects, that they have a different memory representation is just an implementation detail. Same in Ruby, Fixnum's do not allocate a whole object structure, their value is encoded into their "pointer"
<RX14>
i guess
<jhass>
Ruby's toplevel is less mysterious once you introduce the concept of self and the default definee being different things
<jhass>
the toplevel definee in Ruby is Object, so def foo; end; and class Object; private def foo; end; end; is the same
<jhass>
def changes self, but not the definee
<jhass>
self on the toplevel is an instance of Object called "main"
<BlaXpirit>
mm yeah... well then that just leaves Crystal's toplevel mysterious
<jhass>
it is, it's full of special cases still
<FromGitter>
<drosehn> wrt methods in ruby: define a method named "blah" in irb. Then do `xxx = method(:blah)`. Then see what you can do with `xxx`.
<jhass>
it's just a representation of the method though, a description of it if you so will
<FromGitter>
<drosehn> for instance: `xxx.class` returns `Method`. and `xxx.methods` returns an array with all the methods which are available on that `Method` object.
<jhass>
to make it a first class function something like 1.upto would need to return a Method object and parens would need to be required to call it
<jhass>
or bar(def foo; end) would need to pass a Method object to bar
<jhass>
however some people argue that Proc's/the stabby lambda are actually first class functions
Oliphaunte has joined #crystal-lang
Oliphaunte has quit [Remote host closed the connection]