Encapsulation, is it so hard?
-
Please when you write parsers, separate your parsing logic from the rest of your app's logic so the app's main code isn't actually tied directly to your parser's grammar! I mean, I get there's going to be some intermingling between different areas of your code but when I crack open a project, and I find a codebase where every section of the app is intimately tied to every other section of the app it's really frustrating. For example, the parser in this case returns LexSpan classes which hold a text buffer, and start and end positions within that buffer. Great for parsing, so you know where your fragments of text are. But then when you build say, your Regex syntax tree with it, DO NOT use LexSpans as your member fields! unpack the values therein for witch's sake! Now if i want to implement a different parser i have to completely tear apart the app's core logic. Lovely.
Real programmers use butterflies
I don't think I have ever seen lexer/parser code which wouldn't struggle to pass most code reviews.
-
Please when you write parsers, separate your parsing logic from the rest of your app's logic so the app's main code isn't actually tied directly to your parser's grammar! I mean, I get there's going to be some intermingling between different areas of your code but when I crack open a project, and I find a codebase where every section of the app is intimately tied to every other section of the app it's really frustrating. For example, the parser in this case returns LexSpan classes which hold a text buffer, and start and end positions within that buffer. Great for parsing, so you know where your fragments of text are. But then when you build say, your Regex syntax tree with it, DO NOT use LexSpans as your member fields! unpack the values therein for witch's sake! Now if i want to implement a different parser i have to completely tear apart the app's core logic. Lovely.
Real programmers use butterflies
Sounds like you need to send Uncle Bob around to visit them...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I don't think I have ever seen lexer/parser code which wouldn't struggle to pass most code reviews.
-
Take yourself to QA, and peruse a few dozen questions before you ask that. Most of 'em can't spell "Emcapsull..." "Encapcalation" "Encrapsilating" "Encapsuoolasion" the word let alone use it!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
Most of 'em can't spell "Emcapsull..." "Encapcalation" "Encrapsilating" "Encapsuoolasion" the word let alone use it!
can be a bit tricky, so I do the other ting thng one.
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!
-
Please when you write parsers, separate your parsing logic from the rest of your app's logic so the app's main code isn't actually tied directly to your parser's grammar! I mean, I get there's going to be some intermingling between different areas of your code but when I crack open a project, and I find a codebase where every section of the app is intimately tied to every other section of the app it's really frustrating. For example, the parser in this case returns LexSpan classes which hold a text buffer, and start and end positions within that buffer. Great for parsing, so you know where your fragments of text are. But then when you build say, your Regex syntax tree with it, DO NOT use LexSpans as your member fields! unpack the values therein for witch's sake! Now if i want to implement a different parser i have to completely tear apart the app's core logic. Lovely.
Real programmers use butterflies
honey the codewitch wrote:
LexSpan classes which hold a text buffer, and start and end positions within that buffer
So, a ReadOnlySpan<char>[^], but not as efficient? :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
"These people looked deep within my soul and assigned me a number based on the order in which I joined" - Homer
-
honey the codewitch wrote:
LexSpan classes which hold a text buffer, and start and end positions within that buffer
So, a ReadOnlySpan<char>[^], but not as efficient? :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Well in this I will defend them, as ReadOnlySpan is only available on the latest non-DNF framework
Real programmers use butterflies
-
Well in this I will defend them, as ReadOnlySpan is only available on the latest non-DNF framework
Real programmers use butterflies
It's available in DNF 4.5 or later via a NuGet package: NuGet Gallery | System.Memory 4.5.3[^] The DNC version has slightly better performance, because some of the BCL methods have been updated to use it. But the DNF version should be at least as good as rolling your own. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Please when you write parsers, separate your parsing logic from the rest of your app's logic so the app's main code isn't actually tied directly to your parser's grammar! I mean, I get there's going to be some intermingling between different areas of your code but when I crack open a project, and I find a codebase where every section of the app is intimately tied to every other section of the app it's really frustrating. For example, the parser in this case returns LexSpan classes which hold a text buffer, and start and end positions within that buffer. Great for parsing, so you know where your fragments of text are. But then when you build say, your Regex syntax tree with it, DO NOT use LexSpans as your member fields! unpack the values therein for witch's sake! Now if i want to implement a different parser i have to completely tear apart the app's core logic. Lovely.
Real programmers use butterflies
Some patterns don't become obvious until later on. If you're not into constant refactoring (due to fatigue or whatever), things stay.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Please when you write parsers, separate your parsing logic from the rest of your app's logic so the app's main code isn't actually tied directly to your parser's grammar! I mean, I get there's going to be some intermingling between different areas of your code but when I crack open a project, and I find a codebase where every section of the app is intimately tied to every other section of the app it's really frustrating. For example, the parser in this case returns LexSpan classes which hold a text buffer, and start and end positions within that buffer. Great for parsing, so you know where your fragments of text are. But then when you build say, your Regex syntax tree with it, DO NOT use LexSpans as your member fields! unpack the values therein for witch's sake! Now if i want to implement a different parser i have to completely tear apart the app's core logic. Lovely.
Real programmers use butterflies
honey the codewitch wrote:
Please when you write parsers,
That's all I needed to read. You can take comfort in the fact that I've somehow managed to make it thus far in my programming career without ever having to write any sort of parser. Well, certainly not at the level you're dealing with.
-
It's available in DNF 4.5 or later via a NuGet package: NuGet Gallery | System.Memory 4.5.3[^] The DNC version has slightly better performance, because some of the BCL methods have been updated to use it. But the DNF version should be at least as good as rolling your own. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
That's interesting. At one point i heard the DNF couldn't support stack alloc'd ref types the way DNC could but maybe I heard wrong. Adding, the author intends to target .NET 2.0+ although i think that's a little silly.
Real programmers use butterflies
-
Some patterns don't become obvious until later on. If you're not into constant refactoring (due to fatigue or whatever), things stay.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
i don't think this code was all that factored to begin with. I think was just intended to be a quick and dirty port of lex basically, but then grew from there
Real programmers use butterflies
-
honey the codewitch wrote:
Please when you write parsers,
That's all I needed to read. You can take comfort in the fact that I've somehow managed to make it thus far in my programming career without ever having to write any sort of parser. Well, certainly not at the level you're dealing with.
I mean, aside from the regex the parsing isn't even that complicated, but the way it was built into the project just stinks.
Real programmers use butterflies
