Should I release Luvnit?

[airstruck]

Hmm, if that's what OP meant by properties then I completely agree with you, it's pointless cruft.

Just looked at the linked example, apparently that was what OP meant. Just want to reiterate that these aren't properties according to any normal definition, for anyone else reading this. I do think "true" properties have a useful place in Lua, like in many other languages. I've found them to be a pretty elegant solution in certain cases, anyway.

[pgimeno]

My reading of the OP is that the same call (newProperty) creates the field, the setter and getter functions, and gives it an initial value, but that doesn't preclude one from using normal fields. It looks useful to me; I frankly don't see the problem.

This is why I don't usually engage in style discussions: whatever works with you, go for it! If something bothers you enough as to not wanting to make it the same way in future, you'll look into changing the way you do it and look for information on how to do better. That's what experience brings you.

My 0.02€.

[Karai17]

If you don't engage in discussion, they you don't get the viewpoint of other people. What currently works for you might not be as good as something you hadn't thought of yet, and someone else could inform you of. Obviously these discussions are subjective, but I think still important for people to have for the sake of diversity.

There is no "problem" with having the functionality of the setProperty stuff in place, but there isn't any actual value in it being there other than "this is how I learned to program, so I want to keep doing that". Not to mention it's more code to maintain. My position, and I think airstruck's position as well is that it's an inefficient way of creating objects because it simply bogs down the API with tonnes of functions that don't do anything special. I am simply pointing out that there are other ways to do this both in Lua and programming in general which don't generate a massive API for each object.

Imagine creating a player object with update, draw, and move_to functions. You want the object to have x, y, w, h, r, and sprite properties. If you use OP's setProperty method to create each property, your object's API goes from 3 methods to 15. And what do you gain from that? More memory usage, and slightly slower access times since you need to execute a function every time you want to interact with the object.

In my scenario, you simply interact with the object directly, bypassing all that API nonsense. obj.x = 5; obj.x = 9; obj:move_to(11, 17); etc.

[Kingdaro]

That last example Karai gave there really captures the essence of what an API should be. And honestly, it captures the essence of programming in general. Adding needless function wrappers to do the same thing as a variable assignment is stupid, but adding a function that makes doing a certain thing is what makes functions valuable. Following the DRY principle at its purest is normally the best way of going about things.

[airstruck]

It looks useful to me; I frankly don't see the problem.

Well, it could be useful from a design standpoint if you want to have some validation or manipulation in some setters, or caching in some getters, and you just want to have a uniform and stable (and Java-esque) API, and you want to build/prototype it quickly (but don't want to use text editor macros). You're right, it's not necessarily "pointless."

I think it outlives its usefulness when you get around to writing getters and setters that actually do something, though. The code you've already written is no longer useful; you can't just drop another line in with math.floor or whatever, you need to write a new function and might as well remove the old function call. If you wrote getters and setters by hand (or used a text editor macro) you could build on your existing code when you needed to.

It's "cruft" in the sense that you need a helper module to set these default accessors/mutators up, and client code to generate stubs, where with "true" properties you don't; you only need to define properties when you need to do something in particular with them and not before that. If you can commit to the idea of eventually using some properties if needed, you can prototype or write early versions with fields and not need any helper module. You still get a uniform and stable (but Lua-esque) API.

The only problem I had with it was being confused by the mention of properties when it's really more of a stub generator.

This is why I don't usually engage in style discussions

Maybe it's an acquired taste

I think design bears discussion because it's fairly subjective. I enjoy reading your posts about math algorithms, and ivans posts about physics algorithms, but there's limited room for discussion. There are usually a limited number of solutions to a problem, their benefits and drawbacks can be objectively measured, and once the solutions are described properly there's nothing left to discuss.

[alloyed]

These sorts of framework-y things, I think, tend to be more personal than most other libraries, because they turn style questions into policy questions. That, and because they don't represent a huge amount of code anyways: my personal "shared stuff" framework is <700 loc, and has actually been getting smaller over time.

If you think your framework/game organization has clever ideas, then you should probably write it up as a blog post: it'll help people think more deeply about whether or not they want it for their game, and eventually add it to their own code toolbelt in a way that they like.
Adn's blog does this pretty well IMO: https://github.com/adonaac/blog

[Tjakka5]

I think Alloyed nailed it in saying what I couldn't find the words for.
Luvnit is, like any personal library, something that turns my style into a policy; which for me, is a good thing.

I don't know if Luvnit has any things things that are worth it to talk about in a blog, instead, all the systems work nicely in tandem.
I've also found in the time that I used Luvnit that it making small prototypes is quite easy and fast to do, while bigger projects can really take advantage of the event system.

[4aiman]

@OP
Why ask? Just do it!
Release it and see how many downloads you'll get.
That would be a true measure of how much your work is needed.
As far as I understand, you'll continue using it, so why bother how many people will try Luvnit anyway? ^_^

P.S. That being said, ECS was like a fresh air after years of OOP.