|
Jörgen Andersson wrote: And there you parted with OG. He's diehard Whitesmith. I don't want to hang around such psychopaths anyway
Seriously though, you'd have to change all the Visual Studio defaults and anyone working with your code after that will curse you for doing so
Jörgen Andersson wrote: but they also state that fields should be Pascal cased Fields Pascal? Where did you find that? I always camelCase them and never seen different.
Intellisense works fine for same name variables that are differently cased, at least in C#
I don't think I do it a lot though, but I wanted to do it in VB because of the auto-property issue I mentioned.
I also use it when, for example, I have a property MyResult and then in a method I calculate myResult in a local variable.
Jörgen Andersson wrote: Is it? Works fine for me since long. Try to set Public ReadOnly Property MyProperty As String (there's that verboseness again).
I figured it out, you have to set the invisible field _MyProperty
Jörgen Andersson wrote: You shouldn't blame the tool for the tools using it. I'm not sure what you mean, but I never blamed tools.
I blame VB programmers for writing abysmal code
|
|
|
|
|
Sander Rossel wrote: and anyone working with your code after that will curse you for doing so
I wouldn't curse you, only turn passive aggressive and think you're stupid.
Sander Rossel wrote: Fields Pascal? Where did you find that? Names of Type Members | Microsoft Docs[^]
Note though something I didn't notice yesterday: design-guidelines wrote: The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines But guess how the private invisible backing variable to the autoimplemented property looks like. Also in C#.
So even if they removed that guideline some years ago, the compiler still does it.
|
|
|
|
|
Sander Rossel wrote: One thing VB does right (in WinForms development) is Sub MyButton_Click(sender As Object, e As EventArgs) Handles MyButton.Click , which I find more clear than the C# way of adding a handler in the designer.
Just don't look at the generated code.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's the point.
If I want to remove a handler in VB I just remove the handler and be done with it.
In C# I have to visit two places and if I remove just the addhandler I'm left with some handler that's never triggered!
|
|
|
|
|
no typedef!
dt = new KeyValuePair<KeyValuePair<CharFA<TAccept>, CharFA<TAccept>>, RegexExpression>(
new KeyValuePair<CharFA<TAccept>, CharFA<TAccept>>(
dt.Key.Key,
dt.Key.Value),
tt[dt.Key]);
I want to make the C# language team have to declare things like this all day long.
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.
|
|
|
|
|
using KV = KeyValuePair<CharFA<TAccept>, CharFA<TAccept>>;
|
|
|
|
|
Doesn't work. Using requires hard types. It can't use the type parameter TAccept
FOr it to be able to do that it would have to work like C++ where typedef kinda runs like a preprocessor macro (as do source templates)
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.
|
|
|
|
|
Mmm... Like Harold said, compiles for me!
using System;
using ListI = System.Collections.Generic.List<int>;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var f = new ListI();
f.Add(1);
Console.WriteLine(f.Count);
}
}
}
|
|
|
|
|
That only works because int is a hard type.
You can't use using with type parameters.
You cannot do using ListT = IList<TAccept>;
You can in C++ because template stuff basically works like source macros internally, which means they don't have to "resolve" type parameters, they can just preprocess/replace them in whatever context they're used in. C# does not treat generics like source macros so it cannot do a C++ style templated typedef
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.
|
|
|
|
|
Mmmm.. you mean typedef can't be generics, didn't you?
ha well... true that...
On a side note, one that is only vaguely relevant. When generics got out I went all out on generics... and my code became an increasingly complicated and unusable bag of noodles...
Then I realised generics are better when used in moderation!
Works for me, at least!
|
|
|
|
|
Unfortunately, when doing functional style programming heavy use of generics is pretty much unavoidable.
C++ does so much better at this kind of thing. I wish C# would add "template" to the language and allow you to do source style templates like C++ as well as generics (which are binary)
Source level templates are simply far more flexible. You can do things like that typedef, you can do things like get the compiler to make complicated calculations like generating parse tables at compile time (see the Spirit C++ parser framework for an example), and you can do partial template specializations and just all kinds of things you'll never be able to do at the binary level.
It's unfortunate. I love C++ for this stuff. I wish other languages had it.
Ironically, Java/J2EE comes close with their templates, since they are source level but they are so poorly architected that they're a bad joke.
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 can use an interface for TAccept to represent a wide variety of types, am I right? Albeit it is more restrictive that a completely wild symbolic type ...
|
|
|
|
|
No, because the whole point of TAccept is it can be a value type like int, or a reference type like string.
It has to be a basic type so it can be serialized to code via System.CodeDom.CodePrimitiveExpression or via an InstanceDescriptor in the worst case. I don't want to have to force the user to declare a type for TAccept. It should be able to accept intrinsic types at face value.
Worse, one of the main points of generics is accessing value types without boxing/unboxing. If I access a value type by interface, I take the boxing hit anyway, and there's almost no reason to use a generic at all versus using System.Object at that point. Boxing in a lexing routine needs to be avoided because it's a tight, performance critical operation. It's one of the few areas where bit twiddling to get some extra speed is worth it.
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.
|
|
|
|
|
OK, I see what you mean. The C++ generic codes are sources for the C++ template concrete code generator whilc C# generic codes are concrete ones in themselves, therefore it could be harder to achieve what you are looking for ...
|
|
|
|
|
That's precisely it.
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.
|
|
|
|
|
public class MyKvp<TAccept> : KeyValuePair<CharFA<TAccept>, CharFA<TAccept>
{
public MyKvp(TAccept key, TAccept value) : base(key, value)
{ }
}
public class WhateverTheHellThisIs<TAccept> : KeyValuePair<MyKvp<TAccept>>, RegexExpression>
{
public WhateverTheHellThisIs(MyKvp<TAccept> kvp) : base(kvp)
{ }
}
var thing = new WhateverTheHellThisIs<TAccept>(new MyKvp<TAccept>(dt.Key.Key, dt.Key.Value)); That should solve of the verboseness and greatly improve readability.
Although I think I did that slightly wrong, but you get the idea
|
|
|
|
|
Yeah, that's not practical. I use too many different combos of generics. I'd have zillions of one off types, and that actually makes things less maintainable and less intelligible. At least with the templates they are using well known types, and a limited number of them.
welcome to functional programming w/ generics - something C# is *almost* good at.
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.
|
|
|
|
|
|
Gah!
And an IDictionary<TKey, TValue> is just an IEnumerable<KeyValuePair<TKey, TValue>>
In that case, writing your own 3rd gen general purpose language and making it one of the most popular languages that works on all machines is the only clean solution that I can think of
I guess we now know what @code-witch next article is going to be about
|
|
|
|
|
Now you're just baiting me. But right now, I'm working on Rolex, the gold-plated lexer
Imma teach y'all how to build it.
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 was just thinking of using an extension method. I autocorrected the source code in my head.
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 miss C++ typedef, and macros - they were pretty hamn dandy... Does anyone know if they're available in c++.net?
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I feel kinda naked without them to be honest.
It's deeply uncomfortable working outside C++. I always find myself wishing for some feature or another I don't have.
Once you know how to use it C++ is pretty much a Domain Specific Language - you can even utterly alter it to your problem domain and create a whole different language out of it practically (once again, the Spirit Parser framework in C++ is an excellent application of this) - i *love* that even if i rarely use it.
It can do just about anything except protect you from yourself.
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.
|
|
|
|
|
Un-managed C/C++ is not for wussies. I did C/C++ from 1990 to 2007. Moving to .net was a bit jarring.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I did a lot of backend C++ development, including ISAPI stuff in the early aughts.
Switching to .NET was iffy for me too, but I had been forced to know VB6 so C#'s sugary syntax didn't entirely blindside me. And I was already using a garbage collected string table in most of my C++ server apps, so the GC end of it rather appealed to me. Used correctly garbage collection is kickass on servers due to limited heap fragmentation. Your apps performance doesn't degrade over time. This is especially critical of strings, which tend to be thrown around a lot in HTTP apps =)
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.
|
|
|
|