How to LÖVE - Now with text-based tutorials

[airstruck]

Thats it.. no more globals

I'm not sure what you mean, you just declared about 20 globals there. If you don't "instinctively" see the advantage in favoring encapsulation over globals, and your own experience isn't waving a giant red flag, and you aren't convinced by countless articles listing countless reasons to avoid globals, I don't know what I'd be able to say to change your mind.

[MadByte]

I'm not sure what you mean, you just declared about 20 globals there. ....

Yes, and saved about 20 lines of code (if not more) in every single file I got in my project which will help me to keep my code short and maintainable.

reasons like "you could accidentally overwrite anything else" or "you could get some more performance out of it" are non sense applied to small to medium sized one-man game projects. The performance reasons also can be easily avoid by using locals where they're needed (and as I said I don't use any more globals apart from lib/state/game system tables, anyway).
I agree that it would be really bad to use globals in libraries you create for others or in projects you collaborate with people. But where is the huge advantage in avoiding them generally? It simply is the fastest and most enjoyable way to handle things ... and thats more importent then hyper performant code and as less as possible memory usage - at least for me.

The whole discussion about globals/locals feels like it's older then programming itself...

[airstruck]

Yes, and saved about 20 lines of code (if not more) in every single file I got in my project which will help me to keep my code short and maintainable.

If you're saying that all of those globals are used in every single file in your program, then they do represent cross-cutting concerns and (in my opinion) that's a valid use for globals. Looking over that list, though, I have a hard time believing that you've actually managed to organize your code in such a way that you use all (or most?) of those globals in every (or almost every?) file in your source tree (and if you have, I'd say that raises even more serious concerns about your design). Common sense says that something like "anim8" is not the kind of thing that cross-cuts multiple facets of your program, for example.

[Sheepolution]

...

I'm not convinced either. I've tried it in the past, but I felt like I was making it more complicated for myself for the sake of doing it "the right way". I've never had trouble with using globals, and if I ever encounter a problem I can always switch to making them local.

I might make a video about it someday though. But I don't think it's something I should be teaching so soon.

[airstruck]

I felt like I was making it more complicated for myself for the sake of doing it "the right way"

Why do you feel like it's more complicated? You're talking about one extra "return" per module, and one extra "require" per dependency. In return for that, you get no namespace pollution and no chance of name collisions, no ambiguity about what things are or where they came from, a clear picture of what your dependency graph looks like, clear indicators of overly tight coupling, modular testability, increased code comprehension / predictability, and so on.

If you want to cut corners in your own code, nobody can stop you, but consider that doing that in a tutorial for beginners may be doing your audience a disservice, given that (by your own words) this is not "the right way" to do things. Whether this kind of indiscriminate use of globals is good or bad design shouldn't even be a debate, it is bad design, and it encourages more bad design, hands down. You don't have to take my word for it, you can read pretty much any article on the subject and it will come to the same conclusion.

The only reason I chose to say something about it here is because encapsulation is generally considered to be one of the core tenets of OOP, and the irony of using globals over encapsulation in a tutorial about classes was just too hard for me to ignore.

I don't think it's something I should be teaching so soon.

It might not be something you need to teach at all, just lead by example; if your viewers want to cut corners with globals instead, let them work that out for themselves.

[pgimeno]

...

I'm not convinced either. I've tried it in the past, but I felt like I was making it more complicated for myself for the sake of doing it "the right way". I've never had trouble with using globals, and if I ever encounter a problem I can always switch to making them local.

I might make a video about it someday though. But I don't think it's something I should be teaching so soon.

Namespace pollution becomes an issue when a project gets large. You may end up declaring two globals with the same name without noticing. For Thrust II Reloaded I used globals, but they are all defined in main.lua. No module declares any globals.

Also, if you're not careful you may run into a situation of this kind:

Code: Select all

function a()
  i = 1
  while i <= 5 do
    print(i)
    i = i + 1
  end
end

function b()
  i = 1
  while i <= 5 do
    a()
    i = i + 1
  end
end

b()

That code prints 1, 2, 3, 4, 5 and stops, rather than repeating it 5 times. In real world usage the dependencies may become subtler and it may be a hell to debug. Avoiding globals or being careful about them prevents that risk, by enabling usage of static or run-time checking for globals, to see if you missed a 'local' keyword. I detected a couple bugs in the Gspöt library that way.

[airstruck]

Someone pointed out that my earlier comments might have seemed rude or discouraging. I'm sorry if they came off that way. It wasn't my intent to bash these tutorials, there's a lot to like about them and I agree with all the positive stuff that was said in other comments. I only meant to suggest that they might be even better if the examples adhered to commonly-accepted "best practices." I think this is important when creating learning material for beginners. I apologize if anyone was offended by my comments.

[Sheepolution]

Someone pointed out that my earlier comments might have seemed rude or discouraging. I'm sorry if they came off that way. It wasn't my intent to bash these tutorials, there's a lot to like about them and I agree with all the positive stuff that was said in other comments. I only meant to suggest that they might be even better if the examples adhered to commonly-accepted "best practices." I think this is important when creating learning material for beginners. I apologize if anyone was offended by my comments.

No problem! You gave fair criticism and I appreciate that. And you're right, maybe I should.
I'm really stubborn when it comes to these things, but I will think about it.

[scissors61]

I like your style of teaching, straight to the point and concrete, I started using löve without previous knowledge of programming, and there are some series and tutorials that I can't follow because they seem to be made for people with some basic knowledge of programming, but at least I can follow yours.

One quick question about your classes video. I learned to use classes recently doing this

Code: Select all

function ball.new(...)
	local self = {}
---code
	return self
end

I find it very simple and thanks to this I am able to do a lot of stuff comfortably without using metatables for oop, which I can't seem to understand at all. Well, I see that in your videos you use a library, classic, that it's usage is not that different to the way I managed to do oop or pseudo oop. well, Is there's any advantage of using classic instead of the way I'm doing classes?
Thanks for your series, looking forward to it.

[Sheepolution]

Is there's any advantage of using classic instead of the way I'm doing classes?

Take a look at the Github page of the library to see all the features

To name some reasons:

Preformance
When you create a new instance, you don't have to make new functions for that instance.
With your code, assuming you create the functions in the --code section, each instance would have a separate function.

Inheritence
Being able to extend classes, override functions, and call the superclass' functions.

Type checking
With instance:is(ClassName) you can check if an instance is a certain class.