Properly handle CAPI vs Lua libraries #59

New Issue

Aire-One · 2022-12-21T22:41:34+01:00

Aire-One commented

2022-12-21 22:41:34 +01:00

The Awesome documentation groups some CAPI objects with their Lua library from awful. It is the case for client, screen and tag that also have their awful.{client,screen,tag} libraries.

We need to make sure to place every member of these modules to the correct location.

The Awesome documentation groups some CAPI objects with their Lua library from `awful`. It is the case for `client`, `screen` and `tag` that also have their `awful.{client,screen,tag}` libraries. We need to make sure to place every member of these modules to the correct location.

Aire-One added this to the v1.0 milestone 2022-12-21 22:41:34 +01:00

Aire-One commented

2022-12-21 22:47:20 +01:00

Note that the CAPIs are globally available in the awesome runtime. screen, client and tag should be handled specifically to allow definition from the Teal global_env_def (see #60)

Note that the CAPIs are globally available in the awesome runtime. `screen`, `client` and `tag` should be handled specifically to allow definition from the Teal `global_env_def` (see #60)

Aire-One changed title from ~~Properly handle CAPI vs Lua object doc~~ to Properly handle CAPI vs Lua libraries

2022-12-21 22:48:04 +01:00

Aire-One commented

2022-12-21 23:20:36 +01:00

The global_env_def should define CAPIs records for screen, client and tag.

The libraries awful.{client,screen,tag} should define records named after the common First_letter_capitalized convention.

To prevent circular dependencies and global_env_def to depend on non-global modules: The awful. should only define the public static functions exposed by the module. The instance level object type should always refer to the CAPIs records.

It means the CAPIs types should never be required by any means. Only the awful. can be required, and as a user, you only require them to use their static functions.
→ This is the way

The `global_env_def` should define CAPIs records for `screen`, `client` and `tag`. The libraries `awful.{client,screen,tag}` should define records named after the common First_letter_capitalized convention. To prevent circular dependencies and `global_env_def` to depend on non-global modules: The `awful.` should only define the public static functions exposed by the module. The instance level object type should always refer to the CAPIs records. It means the CAPIs types should never be `require`d by any means. Only the `awful.` can be `require`d, and as a user, you only `require` them to use their static functions. → This is the way

Aire-One commented

2022-12-30 18:25:59 +01:00

Most of the work has been done in the scope of #60 with #64.

We want now to improve the implementation by being smarter. We need to make the difference between the members that should be in the global_env and these that should be in the awful. modules.

Most of the work has been done in the scope of #60 with #64. We want now to improve the implementation by being smarter. We need to make the difference between the members that should be in the `global_env` and these that should be in the `awful.` modules.

Aire-One commented

2023-04-20 18:16:57 +02:00

We want now to improve the implementation by being smarter. We need to make the difference between the members that should be in the global_env and these that should be in the awful. modules.

The code refactor from #76 manages this auto-magically. So there should be nothing more to do beside finishing the work on this other PR.

> We want now to improve the implementation by being smarter. We need to make the difference between the members that should be in the global_env and these that should be in the awful. modules. The code refactor from #76 manages this auto-magically. So there should be nothing more to do beside finishing the work on this other PR.

~~Aire-One referenced this issue 2023-05-01 16:45:19 +02:00~~

Move to an AST like data structure #76

Aire-One referenced this issue

2023-05-04 00:26:22 +02:00

Move to an AST like data structure #76

Aire-One closed this issue

2023-09-18 14:53:53 +02:00

Sign in to join this conversation.