Public table looks a bit messy #4

Open
opened 2024-04-17 22:14:28 +02:00 by AliasAlreadyTaken · 3 comments

Let's have

  • api
  • internal
  • chatcommands (cmd)

and so on instead.

Let's have * api * internal * chatcommands (cmd) and so on instead.
Member

what's this about, the publicly exposed data/API from yl_* mods? i've got opinions on that.

what's this about, the publicly exposed data/API from yl_* mods? i've got opinions on that.
Author
Owner

In the template, currently all functions, data and whatnot sit in the main table under yl_template. I'd like to separate them a bit so its clear what's what.

You're talking about your-land/administration#150 ?

In the template, currently all functions, data and whatnot sit in the main table under yl_template. I'd like to separate them a bit so its clear what's what. You're talking about your-land/administration#150 ?
Member

somehow, i didn't notice that this was an issue created against yl_template itself.

what's this about, the publicly exposed data/API from yl_* mods? i've got opinions on that.

In the template, currently all functions, data and whatnot sit in the main table under yl_template. I'd like to separate them a bit so its clear what's what.

You're talking about your-land/administration#150 ?

i forgot about that attempt to consolidate the yl code into more logical subdivisions. it'd be hard to do that without pausing other active efforts, though maybe that's not impossible. yl_commons continues to try to be too many things at the same time.

my "opinions about the yl_* mods" are moreso that after trying to create "api" and "util" ("internal") sub-namespaces in some of my mods, i found that these didn't decrease the namespace complexity in a uniform way. particularly for mods that are entirely API, there's no need for a discrete "api" namespace.

on the topic of mod boilerplate, i'd be happy to donate fmod code for use in yl_* mods, under your preferred license. that code automatically parses mod.conf and settingtypes.txt and makes it so that the documentation doesn't fall out of sync with the implementation.

somehow, i didn't notice that this was an issue created against yl_template itself. > what's this about, the publicly exposed data/API from yl_* mods? i've got opinions on that. > In the template, currently all functions, data and whatnot sit in the main table under yl_template. I'd like to separate them a bit so its clear what's what. > > You're talking about your-land/administration#150 ? i forgot about that attempt to consolidate the yl code into more logical subdivisions. it'd be hard to do that without pausing other active efforts, though maybe that's not impossible. yl_commons continues to try to be too many things at the same time. my "opinions about the yl_* mods" are moreso that after trying to create "api" and "util" ("internal") sub-namespaces in some of my mods, i found that these didn't decrease the namespace complexity in a uniform way. particularly for mods that are *entirely* API, there's no need for a discrete "api" namespace. on the topic of mod boilerplate, i'd be happy to donate fmod code for use in yl_* mods, under your preferred license. that code automatically parses mod.conf and settingtypes.txt and makes it so that the documentation doesn't fall out of sync with the implementation.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/yl_template#4
No description provided.