MarseyFX #206
No reviewers
Labels
No Milestone
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: rDrama/rDrama#206
Loadingβ¦
Reference in New Issue
There is no content yet.
Delete Branch "<deleted>:marseyfx"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Revamped emoji rendering engine. Includes 12+ new modifiers.
TODO:
Here is a sample post which you can use to test out all of the features:
jesus christ
I thought this was finished since there was talk of a merge but seems like there are still some things you want to do add so I won't do a full review. It's cool work, I like the new features, can't wait to put bulges on all the marseys.
Here are the main things I nooticed:
On style:
It would be good if there were some docstrings to explain the basics of the syntax of the language and architecture of the code as well as non-obvious arguments and returns for all functions, especially those with multiple returns like parse_emoji.
You left some prints in. ( 1 in parser, 2 in modifiers)
White-space only change at the end of const.py with bad indent
Dead code in sanitize lines 228, 318, 324.
It'd be good not to rely on wildcard imports for new code (sanitize line 293)
"match" is a keyword since 3.10 sanitize line 628
On the architecture, I'm not sure you need OO for a lot of this stuff. Your tokenizer could be a single function half that length since you don't even use the polymorphism as far as I can tell and just check the instance type every time, and it'd be more readable. Making it a generator could be good, not sure, I haven't groked the parser fully yet.
The heavy function in modifiers.py doesn't need to be a decorator. Also you can define the arguments as self, *args, **kwargs, rather than doing *args, **kwargs and self = args[0] in all decorators, you can use self instead of slf, it's not a keyword.
Your classes (Modifier, ModifierContextFrame) should be data tuples if they are only meant to hold a couple values and no methods, unless they interact in some way with the soup that I don't know about.
I don't understand what context_frames do but my gut is something is odd since they're just added then popped, something to do with the soup? If they are not needed this decorator would also work as just a function.
One last thing that concerned me with these changes, beside the regexes which I haven't looked at, is whether the changes are backward compatible.
That's from a cursory first look, I might look more tomorrow.
One love.
They are totally backwards compatible since rDrama "renders" every post into HTML when you submit it and then just stores that HTML. So nothing needs to be done regarding other posts.
IMO you never "need" OO for this kind of stuff, but I prefer it -- makes things easier to reason about.
Context frames are a concept borrowed from React (simply called "context" in React). Its an implicit way of passing variables from parent to child.
Cool
I don't think you know what codebase ur reviewing πππ
Yeah asking for docstrings in this is a lost cause lol.
Looks really nice, big supporter of improving this part of the codebase.
That being said @transbitch a couple of things you'll need to make this ready to merge (maybe you already know):
Maintainers, please reject this PR.
I think it's self-documenting enough. Dora voice: Can YOU guess what the
@modifier
decorator means?Thx :marseyhearts:
Maybe but honestly that can be put on a later update. I really dont want to fuck with frontend stuff without any view framework, its awful. Maybe @Aevann would be open to having a little itty bitty framework?
This is already the case. It is designed with this in mind, it is entirely compositional
@top
The modifier decorator is a good example because it's not clear what it 's for. You already have modifier functions which you would expect to hold that logic. And the role of the ContextFrame as a recursive name stack would be clearer if the syntax of the modifiers had been documented as compositional somewhere.
I guessed there was something like this going on but without even a short description of how the system works anywhere in the code I had no idea what the actual syntax of an emoji was supposed to be short of my reverse-engineering of the parsers and tokenizer.
I think some explanation of the syntax like you did in the readme would go a long way to make the code easier to interpret, as well as some selective info about the idiosyncracies and interplay of each architectural element (parser, modifier, tokenizer).
Anyway that's my $2c but it's your free time so I get if you don't want to waste it on this.
I meant docstrings for this codebase lol
I get that it's a pain in the ass but it's kinda required so that users know what their comment will look like before they post. If you really don't want to do it I can port over your python code.
Good that it works for all manner of modifier combinations, I really only skimmed it lol
Only 10 merge conflicts wow
WIP: MarseyFXto MarseyFXtoo many pointless changes, unreviewable
Pull request closed