⚡ Feature: Pluggable predicate-based resolution method #166

New Issue

deavmi · 2024-03-10T10:51:43Z

deavmi commented

2024-03-10 10:51:43 +00:00

Purpose ✍️

The purpose of this is to re-work many of the methods within the Resolver such that they can be parameterised by a Predicate when doing searches. This predicate will be used to match against whether something is found or not found.

We would then make every existing search method basically be a predicate-custom call to these few base methods.

Todo 🏁

resolveWithin(..., ...)
resolveUp(..., ...)
~~resolveBest(..., ...)~~

## Purpose ✍️ The purpose of this is to re-work many of the methods within the `Resolver` such that they can be parameterised by a `Predicate` when doing searches. This predicate will be used to match against whether something is _found_ or _not found_. We would then make every existing search method basically be a predicate-custom call to these few base methods. ## Todo 🏁 - [x] `resolveWithin(..., ...)` - [x] `resolveUp(..., ...)` - [ ] ~~resolveBest(..., ...)~~

deavmi referenced this issue

2024-03-10 10:52:12 +00:00

⚡ Feature: Multi-module support #157

deavmi added a new dependency 2024-03-10 10:52:29 +00:00

#157 ⚡ Feature: Multi-module support

deavmi changed title from ~~⚡ Feature: Pluggable predicate-nased resolution method~~ to ⚡ Feature: Pluggable predicate-based resolution method

2024-03-10 10:52:37 +00:00

deavmi added reference feature/multi_module

2024-03-10 10:52:40 +00:00

deavmi added this to the Basics milestone 2024-03-10 10:52:42 +00:00

deavmi added the

resolution

label 2024-03-10 10:52:49 +00:00

deavmi self-assigned this 2024-03-10 10:52:54 +00:00

deavmi added this to the Dependency tree, type-checking and codegen project 2024-03-10 10:52:56 +00:00

deavmi added spent time 2024-03-10 11:03:36 +00:00

10 minutes

deavmi started working 2024-03-10 11:03:39 +00:00

deavmi commented

2024-03-10 11:03:44 +00:00

Working on this now...

deavmi changed reference from ~~feature/multi_module~~ to feature/predicate_based_resolver

2024-03-10 11:03:52 +00:00

deavmi commented

2024-03-10 12:05:47 +00:00

From BNET's #programming:

[00:58:55] <-- mittwerk (Thunderbir@ytjtzqfufigfbtpxgpjuu3jn44oc23kuvgosxjmr37m4zbz3hoxa.b32.i2p) has quit (Quit: mittwerk)
[11:09:36] --> mittwerk (Thunderbir@ytjtzqfufigfbtpxgpjuu3jn44oc23kuvgosxjmr37m4zbz3hoxa.b32.i2p) has joined #programming
[11:15:52] <-- mittwerk (Thunderbir@ytjtzqfufigfbtpxgpjuu3jn44oc23kuvgosxjmr37m4zbz3hoxa.b32.i2p) has quit (Quit: mittwerk)
[13:06:21] <deavmi> Working on making the tlang resolver
[13:06:29] <deavmi> all predicate based, will clean up many specific search type methods
[13:06:46] <deavmi> By using this approach because I intend to add more very specific lookup methods required for the multi-module support I have been working on
[13:22:28] <deavmi> Doing some meta programming to make this shit fuego fire
[13:49:14] <deavmi> Coming up with something in generl is hard atually
[13:49:14] <deavmi> mmmmh
[13:51:11] <deavmi> makes sese for some methods
[13:51:25] <deavmi> But some are too speciic in bith what is searched for and what is to be returned
[13:51:30] <deavmi> Not sure if thse can be generalized
[14:03:51] <deavmi> Okay, got another function almost done
[14:03:52] <deavmi> Just testing now
[14:03:55] <deavmi> resoleWithin is good
[14:03:59] <deavmi> resolveUp now being worked on
[14:05:20] <deavmi> Looks like it worked

From BNET's `#programming`: ```irc [00:58:55] <-- mittwerk (Thunderbir@ytjtzqfufigfbtpxgpjuu3jn44oc23kuvgosxjmr37m4zbz3hoxa.b32.i2p) has quit (Quit: mittwerk) [11:09:36] --> mittwerk (Thunderbir@ytjtzqfufigfbtpxgpjuu3jn44oc23kuvgosxjmr37m4zbz3hoxa.b32.i2p) has joined #programming [11:15:52] <-- mittwerk (Thunderbir@ytjtzqfufigfbtpxgpjuu3jn44oc23kuvgosxjmr37m4zbz3hoxa.b32.i2p) has quit (Quit: mittwerk) [13:06:21] <deavmi> Working on making the tlang resolver [13:06:29] <deavmi> all predicate based, will clean up many specific search type methods [13:06:46] <deavmi> By using this approach because I intend to add more very specific lookup methods required for the multi-module support I have been working on [13:22:28] <deavmi> Doing some meta programming to make this shit fuego fire [13:49:14] <deavmi> Coming up with something in generl is hard atually [13:49:14] <deavmi> mmmmh [13:51:11] <deavmi> makes sese for some methods [13:51:25] <deavmi> But some are too speciic in bith what is searched for and what is to be returned [13:51:30] <deavmi> Not sure if thse can be generalized [14:03:51] <deavmi> Okay, got another function almost done [14:03:52] <deavmi> Just testing now [14:03:55] <deavmi> resoleWithin is good [14:03:59] <deavmi> resolveUp now being worked on [14:05:20] <deavmi> Looks like it worked ```

deavmi commented

2024-03-10 12:12:35 +00:00

I may as well add the access modifier function I want now as it would be a good test for the searching that I want to do.

It wuld effcievtly be something whereby I give it some Container and then a predicate which disregards any non-Function and then only returns those with an access modifier of my choice.

I may as well add the access modifier function I want now as it would be a good test for the searching that I want to do. It wuld effcievtly be something whereby I give it some `Container` and then a predicate which disregards any non-`Function` and then only returns those with an access modifier of my choice.

deavmi commented

2024-03-10 12:17:17 +00:00

I may as well add the access modifier function I want now as it would be a good test for the searching that I want to do.

It wuld effcievtly be something whereby I give it some Container and then a predicate which disregards any non-Function and then only returns those with an access modifier of my choice.

Got this all coded up now.

> I may as well add the access modifier function I want now as it would be a good test for the searching that I want to do. > > It wuld effcievtly be something whereby I give it some `Container` and then a predicate which disregards any non-`Function` and then only returns those with an access modifier of my choice. Got this all coded up now.

deavmi commented

2024-03-10 12:24:39 +00:00

Working on documentation now.

deavmi commented

2024-03-10 12:37:19 +00:00

Resolver

Documented the class and some new and existing
Implemented a version of resolveWithin(...) which now takes in a Predicate!(Entity) instead of a name and then uses that as the final matching step when iterating over the given Container's Statement[] (the container's immediate body)
Implemented derive_nameMatch(string name) which returns a Predicate!(Entity) closure which matches based on names
Updated resolveWithin(Container, string) to make use of these above two changes
A similar change including the above rework and predicate derivation has been done for resolveUp(...), of which there is now a version available as resolveUp(Container, Predicate!(Entity))
Stub version of resolveBest(Container c, Predicate!(Entity) d) added but not implemented yet
Added some unsued types and methods, SearchCtx and findFrom!(...)(...) respectively
Added derive_functionAccMod(AccessorType) (this is to be moved into DGen as that is where it is needed)

Resolver - Documented the class and some new and existing - Implemented a version of `resolveWithin(...)` which now takes in a `Predicate!(Entity)` instead of a name and then uses that as the final matching step when iterating over the given `Container`'s `Statement[]` (the container's immediate body) - Implemented `derive_nameMatch(string name)` which returns a `Predicate!(Entity)` closure which matches based on names - Updated `resolveWithin(Container, string)` to make use of these above two changes - A similar change including the above rework and predicate derivation has been done for `resolveUp(...)`, of which there is now a version available as `resolveUp(Container, Predicate!(Entity))` - Stub version of `resolveBest(Container c, Predicate!(Entity) d)` added but not implemented yet - Added some unsued types and methods, `SearchCtx` and `findFrom!(...)(...)` respectively - Added `derive_functionAccMod(AccessorType)` (this is to be moved into `DGen` as that is where it is needed)

deavmi commented

2024-03-10 12:42:17 +00:00

All tests pass (local and CI/CD ✅ )

deavmi added the due date 2024-03-14

2024-03-10 12:42:32 +00:00

deavmi commented

2024-03-10 12:43:39 +00:00

I will merge this once I can figure out that last part, the one of resolveBest(Container, strng) which I may very well keep as s and change maybe later. The main thing I required was basically resolveWithin(Container, Predicate!(Entity)) because now I can do a hritntal search for Function(s) and find those with a given access mdifier.

I will merge this once I can figure out that last part, the one of `resolveBest(Container, strng)` which I may very well keep as s and change maybe later. The main thing I required was basically `resolveWithin(Container, Predicate!(Entity))` because now I can do a hritntal search for `Function`(s) and find those with a given access mdifier.

deavmi stopped working 2024-03-10 12:43:43 +00:00

1 hour 40 minutes

deavmi started working 2024-03-12 16:36:00 +00:00

deavmi commented

2024-03-12 16:42:24 +00:00

Documented and cleaned up

deavmi commented

2024-03-12 16:42:49 +00:00

Remaining thing is resolveBest(...). I would really like to get that done in a generic fashion.

Remaining thing is `resolveBest(...)`. I would really like to get that done in a generic fashion.

deavmi commented

2024-03-12 16:46:47 +00:00

Purpose ✍️

The purpose of this is to re-work many of the methods within the Resolver such that they can be parameterised by a Predicate when doing searches. This predicate will be used to match against whether something is found or not found.

We would then make every existing search method basically be a predicate-custom call to these few base methods.

Todo 🏁

resolveWithin(..., ...)

resolveUp(..., ...)

~~resolveBest(..., ...)~~

Not doing resolveBest(..., ...) maybe at a later stage.

> ## Purpose ✍️ > > The purpose of this is to re-work many of the methods within the `Resolver` such that they can be parameterised by a `Predicate` when doing searches. This predicate will be used to match against whether something is _found_ or _not found_. > > We would then make every existing search method basically be a predicate-custom call to these few base methods. > > ## Todo 🏁 > > - [x] `resolveWithin(..., ...)` > - [x] `resolveUp(..., ...)` > - [ ] ~~resolveBest(..., ...)~~ Not doing `resolveBest(..., ...)` maybe at a later stage.

deavmi commented

2024-03-12 16:47:13 +00:00

Testing now.... then will merge