i don't like object oriented programming
-
that's exactly what I want. Does .NET support that now? :omg:
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 dunno if there was a problem before.. but it's copy paste from some code I was just running on a test project while thinking about your problem.... So, shortly, this is fine. Assuming it was not always working (which I doubt) the test project use .NET Framework 4.7.2 and C# compiler latest version, i.e. 7.3 **[EDIT & REMARK]**this looks like perfectly valid C# since the beginning of generic to me. Odds are you got confused at some stage...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
that's exactly what I want. Does .NET support that now? :omg:
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.
This has always worked. You can't do that with static and/or non virtual method though, maybe that's what mislead you?!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
i never have. give me templates. or you may as well just give me something procedural. if i can't do generic programming i'm a sad honey bear. C# is barely adequate. And it's too object centric IMO. generics need to be able to do more. I want traits. I want the runtimes to do what i can make a C++ compiler do with templates. I probably just got the BAC up of this entire board saying that, but there it is.
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.
-
one example I'm running into right now is template specialization. I have a finite state machine engine and it works for any transition input type and any accept symbol type. However, there are additional features that can happen - significant ones that can only exist when the transition type is char - this specialization is effectively a regular expression engine, which means it can parse from a regular expression, and provide regex matching over string inputs. The other kind of FAs it wouldn't even make sense for that. So because of this I have two separate classes - one generic FA class, and one called CharFA where the TInput=char basically. It means more code to maintain because a lot of it is duplicated. To unduplicate a lot of which i could, I'd have to add another codefile with an interface, and another with static methods to share common functionality, which again, increases the code size. So it's not even that I can't do it with C#, it's that what is elegantly handled in C++ is clunky in C# to do the same thing, and requires more code.
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.
There are two ways that I can think of to avoid this code duplication. (Whether these are suitable is up to you.) 1. Implement your byte specific class as a subclass of your generic class? 2. Use dependency injection for the byte specific code. Good luck
-
i never have. give me templates. or you may as well just give me something procedural. if i can't do generic programming i'm a sad honey bear. C# is barely adequate. And it's too object centric IMO. generics need to be able to do more. I want traits. I want the runtimes to do what i can make a C++ compiler do with templates. I probably just got the BAC up of this entire board saying that, but there it is.
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.
-
Eddy Vluggen wrote:
That's a non-complaint; like I said, you can put all your procedures in a God-object
Not a complaint. Just attempting to clarify what i meant
Eddy Vluggen wrote:
I'd say you haven't worked in a strict procedural language
Now I wonder what you'd consider procedural. Batch files? SQL? C?
Eddy Vluggen wrote:
Haven't seen much of that, so not going to comment on it. But still, yuck.
Spoken like someone that's never used it. GP is lovely, elegant, concise and powerful. I wish it was more available in places other than C++.
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.
honey the monster, codewitch wrote:
Now I wonder what you'd consider procedural.
AMOS, among others.
honey the monster, codewitch wrote:
Spoken like someone that's never used it.
OO is the most logical step forward from the messy and hard-to-maintain pages of procedures, sprinkled with arguments and global variables.
honey the monster, codewitch wrote:
I wish it was more available in places other than C++.
It is still available; you can abuse any OO language as if it is merely capable of procedures.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
honey the monster, codewitch wrote:
Now I wonder what you'd consider procedural.
AMOS, among others.
honey the monster, codewitch wrote:
Spoken like someone that's never used it.
OO is the most logical step forward from the messy and hard-to-maintain pages of procedures, sprinkled with arguments and global variables.
honey the monster, codewitch wrote:
I wish it was more available in places other than C++.
It is still available; you can abuse any OO language as if it is merely capable of procedures.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
generic programming, not procedures.
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.
-
There are two ways that I can think of to avoid this code duplication. (Whether these are suitable is up to you.) 1. Implement your byte specific class as a subclass of your generic class? 2. Use dependency injection for the byte specific code. Good luck
the latter isn't practical. the former i already did, and it's sloppy as hell
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.
-
This has always worked. You can't do that with static and/or non virtual method though, maybe that's what mislead you?!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
doesn't compile for me.
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.
-
This has always worked. You can't do that with static and/or non virtual method though, maybe that's what mislead you?!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
oh i see what you did. that's not template specialization. that's method overloading
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.
-
You shouldn't look at object oriented programming as if you're working with objects. You should look at it objectively.
i know how to code OO. i just don't like OO because it requires a lot of code to do a little bit.
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 dunno if there was a problem before.. but it's copy paste from some code I was just running on a test project while thinking about your problem.... So, shortly, this is fine. Assuming it was not always working (which I doubt) the test project use .NET Framework 4.7.2 and C# compiler latest version, i.e. 7.3 **[EDIT & REMARK]**this looks like perfectly valid C# since the beginning of generic to me. Odds are you got confused at some stage...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
i looked at your code wrong, didn't notice until i tried writing one myself. that's not template specialization, but simply method overloading - and i'm doing it already class CharFA : FA { .. }
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.
-
oh i see what you did. that's not template specialization. that's method overloading
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.
yeah but... it behave quite similarly...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
yeah but... it behave quite similarly...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
not really. only in the specific scenario where all you need is method overloading. and even then it's not the same, because you have two separate classes in your code now instead of one.
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.
-
yeah but... it behave quite similarly...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
here let me give you an example of where it's not the same ... FooBase DerivedMethod() { return BaseMethod() } ... FooBase BaseMethod() { return new FooBase(); } ... in a specialization there are no base methods, so above would always return the fully derived class
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 looked at your code wrong, didn't notice until i tried writing one myself. that's not template specialization, but simply method overloading - and i'm doing it already class CharFA : FA { .. }
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.
Yeah, I was wondering, isn't that good enough?! But then I realised one could accidentally instantiate
new FA()instead of the desirednew CharFA()But then what of this other syntax? While it's slightly more wordy, I bet the end compiled result is just as you desiredclass A { public void Do(T value) { if (value is int intV) Do(intV); else DoDefault(value); } void DoDefault(T value) { Console.WriteLine("Value: " + value); } void Do(int value) { Console.WriteLine("Int: " + value); } } class Program { static void Main(string\[\] args) { A a = new A(); a.Do(1); } }I mean personally I am happy to solve that using subclasses or interfaces, but since you really didn't want to....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Yeah, I was wondering, isn't that good enough?! But then I realised one could accidentally instantiate
new FA()instead of the desirednew CharFA()But then what of this other syntax? While it's slightly more wordy, I bet the end compiled result is just as you desiredclass A { public void Do(T value) { if (value is int intV) Do(intV); else DoDefault(value); } void DoDefault(T value) { Console.WriteLine("Value: " + value); } void Do(int value) { Console.WriteLine("Int: " + value); } } class Program { static void Main(string\[\] args) { A a = new A(); a.Do(1); } }I mean personally I am happy to solve that using subclasses or interfaces, but since you really didn't want to....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Yeah I can't do that in this code because this code is inner loop critical and the "is" comparison is just a dog. I think "as" is faster, but still, it should be resolved at compile time. I know it seems a minor quibble but this code may be used as part of a lexer. The lexing itself needs to be balls quick to be feasible. also i'd be concerned about bugs this could introduce since i have to repeat a lot of code, but that's not a showstopper. it's just irritating
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.
-
Yeah, I was wondering, isn't that good enough?! But then I realised one could accidentally instantiate
new FA()instead of the desirednew CharFA()But then what of this other syntax? While it's slightly more wordy, I bet the end compiled result is just as you desiredclass A { public void Do(T value) { if (value is int intV) Do(intV); else DoDefault(value); } void DoDefault(T value) { Console.WriteLine("Value: " + value); } void Do(int value) { Console.WriteLine("Int: " + value); } } class Program { static void Main(string\[\] args) { A a = new A(); a.Do(1); } }I mean personally I am happy to solve that using subclasses or interfaces, but since you really didn't want to....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
adding, my solution to the object creation was to have a method in the base class called
CreateFA()that could be overloaded in order to force the base class to create the derived class. Unfortunately to get it to work I had to remove every static method that created objects from the base class =(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.
-
Yeah I can't do that in this code because this code is inner loop critical and the "is" comparison is just a dog. I think "as" is faster, but still, it should be resolved at compile time. I know it seems a minor quibble but this code may be used as part of a lexer. The lexing itself needs to be balls quick to be feasible. also i'd be concerned about bugs this could introduce since i have to repeat a lot of code, but that's not a showstopper. it's just irritating
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 think you probably underestimate the compiler here generic code are some sort of IL that is used to generate code on demand (when a concrete type is used) when, say
Atype is created the compiler will see thatvoid Do(int value) {
if (value is double d) { // dead end code prune by the compiler
}
if (value is int ii) Do (ii);
}some path will never happen and it will removed them from the concrete implementation created when the concrete type is created. and the compiled code will become
void Do(int value) {
Do (value);
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I think you probably underestimate the compiler here generic code are some sort of IL that is used to generate code on demand (when a concrete type is used) when, say
Atype is created the compiler will see thatvoid Do(int value) {
if (value is double d) { // dead end code prune by the compiler
}
if (value is int ii) Do (ii);
}some path will never happen and it will removed them from the concrete implementation created when the concrete type is created. and the compiled code will become
void Do(int value) {
Do (value);
}A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The reason I underestimate the compiler maybe is the last the time I really examined IL was in the .NET 2.0-3.0 days and the compiler didn't do hardly anything for program optimization. Microsoft's rationale seemed to be that JIT would take care of it, but JIT doesn't do whole program optimization. It can only do peephole optimization, so I don't know what they were thinking. My guess is it was an excuse due to deadlines. So I don't trust the compiler that much. Maybe my information is old. The compiler certainly has been revamped since then.
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.