|
public IDictionary<string,ICollection<(CfgRule Rule,string Symbol)>> FillPredictK(IEnumerable<string> prefix, IDictionary<string, ICollection<(CfgRule Rule, string Symbol)>> result=null)
{
if (null == result)
result = new Dictionary<string, ICollection<(CfgRule Rule, string Symbol)>>();
return result;
}
Trying to implement this:
The PREDICT-k Function[^]
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Cards against humanity: programmer edition?
|
|
|
|
|
yep. or self-flagellating my way to better code. how much self-inflicted emotional abuse will it take to get me an LL(k) table generation algorithm?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Psst...it's much less grating if you make your default assignment properly in the first place.
Also, declare some classes every one in while! At least an interface: IRuleSymbolCollection or something!
public IRuleSymbolCollection FillPredictK(IEnumerable<string> prefix, IDictionary<string, IRuleSymbolCollection> result = new Dictionary<string, IRuleSymbolCollection>()){...}
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Nathan Minier wrote: IRuleSymbolCollection or something
My thoughts exactly 
|
|
|
|
|
Do you have any idea how many of those little one off types I'd have to define for this code if I did that?
These tuples are used for like one calculation. And there's all kinds of different ones.
It doesn't make sense to define types for them since they are just purely data holders for the purpose of computational functions. The functions themselves represent mathematical equations and the math behind them also uses tuples.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I get that, but you can fulfill an interface with a tuple rather than a concrete type.
Even if that interface only exists for this method, the moment you wrote it more than once it became worth moving the definition to an interface for single-point refactoring.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Nathan Minier wrote: I get that, but you can fulfill an interface with a tuple rather than a concrete type.
Color me stupid (it's late in my defense), but I don't understand.
That's what I am doing, as far as I can tell. You changed my tuple to a concrete type.
Nathan Minier wrote: Even if that interface only exists for this method, the moment you wrote it more than once it became worth moving the definition to an interface for single-point refactoring.
One of the side effects of this method coming from math is the math is like 40 years old and has been proved to death so the odds of refactoring this method are almost nil, short of me for some reason changing to entirely different collection interfaces which I also probably won't do since I derive them strictly from the math involved (which one i use i mean, IEnumerable (stream or minimal set), ICollection (unordered set), IList (ordered set), IDictionary (set with grouping)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: You changed my tuple to a concrete type.
No, an interface is not a concrete type.
codewitch honey crisis wrote: One of the side effects of this method coming from math is the math is like 40 years old and has been proved to death
Absolutely, and if your tuples were nothing but primitives this argument would hold water. The types you're using in the tuple are not primitives, though, and you might well want to modify or replace those at some time.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Oh okay, I was misunderstanding you. You mean because CfgRule isn't primitive?
in the math it is. that's the kicker. it's always it's own "tuple" but for the purposes of coding it's easier to work with as a class.
still, I don't think that should "poison" anything it touches - IOW it should still be containable by a tuple especially if it's represented that way math-wise.
EDIT: They used to *be* tuples in previous incarnations of the code but I was performing so many operations on them they needed a class so I could customize the value comparisons to compare the right hand side collections. thats' the only reason they aren't tuples. I'm not really interested in extending the rule class much. It's basically a tuple with corrected value semantics to handle the collection it contains
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It's all good, if you like the verbose style that's really up to you. I think this is one of those places where readability might be influenced by background. I don't like it as it lacks abstraction, but then again it's not mine to like.
Modern IDE's make many of the single-refactor points moot, I suppose.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
If my code works right you will never have to see it unless you want to debug a parser generator. 
I provide it public because i provide the "math" for all of my code in this publically. Theoretically you could use it like Mathematica or JFLAP but in practice you don't need the stuff.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I have to agree with Nathan here. Your code may be hidden from the casual user, but that's not really the point. If you used an interface rather than a concrete type it would lead to more flexible code. As it is, it's rather brittle and not very readable.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
if you saw the rest of the code you might change your mind. If I did that here, I'd have like 40 other places I'd also need to declare a one off type.
no. just no.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: I'd have like 40 other places I'd also need to declare a one off type.
That's part of the problem with the approach here.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Then the problem is the math, I guess. It's really heavy on tuples.
Such is the nature of context-free parsing.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Nathan Minier wrote: Psst...it's much less grating if you make your default assignment properly in the first place.
Except default parameter values have to be compile-time constants, so that won't work. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Bah, stop with your correctness!
I'ma have some more coffee.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
Nathan Minier wrote: public IRuleSymbolCollection
Always have an interface with a name starting with IRule. Every time you use it, say out loud "I Rule" - that should boost your self esteem.
There must be other good interface names, e.g. IRockPaperScissors (say "I Rock")
|
|
|
|
|
heh. yeah. except every time i think i rule the code shows me i'm still subordinate to the gods of the debugger.
But yeah i-interfaces in this code would be spurious at best.
that's not true of the runtimes component but i use abstract base classes instead of interfaces there, for reasons
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
What's the point of declaring collections for everything when I have generics for collections?
that was primary time saver moving from .NET 1.x to 2.0
I'm not going back.
I'd add, there's no reason for I-interfaces to be declared in this code.
There's no justification for it whatsoever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote:
if (null == result)
A fan of these "Yoda conditionals" I also used to be, hmmm, yes.
But with C# 7, I now prefer:
if (result is null)
If the null-coalescing assignment operator[^] makes it into C# 8, this line could be further simplified to:
result ??= new Dictionary<string, ICollection<(CfgRule Rule, string Symbol)>>();
Add in target-typed new expressions[^], and you can really annoy the var haters with:
result ??= new();
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I love var but some of what you posted is too much. C# 12 will end up looking like perl at this rate. :/
I'm a fan of yoda conditionals for two reasons:
The first is old habits from back when compilers were more primitive (preventing accidental assignment)
The second is I've found that if you must use a series of ifs on the same target value it is easier to visualize what you're doing when the target is on the left hand side. For example
if("foo"==target)
else if("bar"==target)
else if("baz"==target)
that one obv is simple and can be changed to a switch but once you start adding || and && in there and breaking each subcomparison out on it's own line the difference is clear. yodaized looks better in the source in terms of figuring out what you're doing. The target being on the right makes it less distracting
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I agree. It started as the same old habit to avoid accidental assignment, but I got used to it and still like it.
if (null == target) seems to make much more sense than if (target == null).
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
This gets so much prettier in F#, where IDictionary<string,ICollection<(CfgRule Rule,string Symbol)>> simply becomes a type, like "RuleMap"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
