| Time |
Nick |
Message |
| 00:14 |
|
proller joined #minetest-dev |
| 00:21 |
|
Alias2 joined #minetest-dev |
| 00:40 |
|
proller joined #minetest-dev |
| 02:11 |
|
v-rob joined #minetest-dev |
| 02:18 |
|
v-rob joined #minetest-dev |
| 02:35 |
|
Yad joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 07:13 |
|
calcul0n joined #minetest-dev |
| 08:15 |
|
YuGiOhJCJ joined #minetest-dev |
| 09:20 |
|
appguru joined #minetest-dev |
| 10:16 |
|
Fixer joined #minetest-dev |
| 11:02 |
|
proller joined #minetest-dev |
| 12:01 |
|
HuguesRoss joined #minetest-dev |
| 12:01 |
|
erlehmann joined #minetest-dev |
| 12:56 |
|
proller joined #minetest-dev |
| 12:58 |
|
troller joined #minetest-dev |
| 13:27 |
|
erlehmann joined #minetest-dev |
| 14:24 |
|
Taoki joined #minetest-dev |
| 15:17 |
|
Fixer joined #minetest-dev |
| 15:59 |
|
troller joined #minetest-dev |
| 18:16 |
|
Taoki joined #minetest-dev |
| 18:19 |
|
olliy joined #minetest-dev |
| 18:21 |
|
Desour joined #minetest-dev |
| 18:41 |
|
Fixer_ joined #minetest-dev |
| 19:22 |
|
v-rob joined #minetest-dev |
| 20:04 |
|
Fixer joined #minetest-dev |
| 20:23 |
|
v-rob joined #minetest-dev |
| 21:02 |
sfan5 |
merging #11963 #12020 in 10m |
| 21:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/11963 -- Make get_sky return a table by Zughy |
| 21:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/12020 -- Debug HUD flag by appgurueu |
| 21:06 |
erlehmann |
i still think that zughy's transition plan for a new API makes very little sense |
| 21:06 |
erlehmann |
because it is a two-stage thing: first you add an argument to get the table, then at a future point, you deprecate the same argument? |
| 21:07 |
erlehmann |
or something like that |
| 21:07 |
erlehmann |
i don't believe it has been thought out beyond “it should change behaviour, but lets preserve the old one for now” |
| 21:08 |
erlehmann |
and this is not about future rug-pulls, i just think it's weird, because you could keep the old way probably at little cost (judging from the code), not deprecating anything. or you deprecate it and ALWAYS need the argument. |
| 21:09 |
erlehmann |
(i.e. deprecating not needing it) |
| 21:09 |
sfan5 |
thing is: we don't want to keep the old way |
| 21:10 |
erlehmann |
yeah, but that means that first you deprecate not having the argument and then at some later point you deprecate the argument |
| 21:10 |
erlehmann |
unless i am misunderstanding something major about the ”at some later point” |
| 21:11 |
erlehmann |
i mean it seems fine if you always need the argument in the future |
| 21:11 |
erlehmann |
because *then* you can definitely detect code that is deprecated |
| 21:12 |
erlehmann |
(and automatically offer advice) |
| 21:13 |
erlehmann |
(“fine” as in: among the rug-pulls it's the least bad ones) |
| 21:14 |
MTDiscord |
<jordan4ibanez> Perhaps in game development, supporting old versions to no limit can lead to extreme bloat |
| 21:14 |
sfan5 |
after the deprecation period we don't want to detect code that is deprecated |
| 21:17 |
erlehmann |
i guess then to you my “deprecation could/should maybe done in a different way” is no different than my other “if engine devs put more work into their API design, game developers will have less changes” arguments, which makes it kinda useless to complain (as we wall know where we stand on this) |
| 21:18 |
erlehmann |
jordan4ibanez just to be clear, i am not arguing for supporting old versions forever here. i am arguing that it's at least ”a bit weird” to change a function signature twice to basically achieve one function signature change. |
| 21:18 |
erlehmann |
especially since the end state will be indistinguishable from the start state |
| 21:19 |
erlehmann |
(from a function signature POV) |
| 21:21 |
erlehmann |
regardless, i see no reason to rehash this if “deprecation should be done different” is structurally too similar to “nothing should be deprecated”. deprecation will probably proceed exactly as zughy outlined it and that's it. |
| 21:21 |
MTDiscord |
<jordan4ibanez> Oh sorry |
| 21:21 |
erlehmann |
no need to be sorry |
| 21:23 |
erlehmann |
i just wanted to point out that this time i am only criticizing the way *how* it is done, not *that* it is done. |
| 21:23 |
erlehmann |
(and i do not have a better proposal on hand that is acceptable to engine devs) |
| 21:24 |
sfan5 |
the "better" proposal is to make a get_sky2() but I am sceptical |
| 21:24 |
erlehmann |
it would definitely lead to a much easier deprecation detection |
| 21:24 |
erlehmann |
i.e. contentdb could detect deprecated mods for example |
| 21:25 |
erlehmann |
or you could just grep your whole codebase |
| 21:26 |
erlehmann |
but as i said, we had these arguments already. i am interested in new objections to that kind of deprecation though! |
| 22:13 |
|
appguru joined #minetest-dev |
| 22:46 |
|
proller joined #minetest-dev |
| 22:49 |
|
v-rob joined #minetest-dev |
| 22:56 |
|
proller joined #minetest-dev |
| 23:15 |
|
proller joined #minetest-dev |
| 23:28 |
|
beanzilla joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:50 |
|
v-rob joined #minetest-dev |
