Welcome to the Lounge

6-Dec-19 4:28

So I need to resolve the "type" of a this reference, but I cannot do it without knowing how my object was created because what type arguments were used? This is where generics ridiculously complicate things.

I know how the C# compiler does it internally. Each generic instantiation is given its own "name" and type entry.

In the CodeDOM this just *can't* work that way. At least not in any fashion I can figure out. There is only one CodeTypeDeclaration for any given type, even if it is generic.

To make it otherwise would break the CodeDOM. I'm trying to use "userData" tags to mark up the codedom with extra information, but frankly, I don't even know how to "trace" the this reference back to the create object statement that brought it to life.

*scratches head*

I've taken breaks. I've even coded different stuff to cleanse my mind. It's just not coming to me.

I'm so frustrated right now. This project is an absolute bear.

Edit: I'm not even 100% sure this is the right approach even if I do figure it out. Sigh | :sigh:

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.

Greg Utas6-Dec-19 4:51

Greg Utas

6-Dec-19 4:51

When I squint at C#, it kinda looks like C++.

If you know the Class to which the function in question belongs, isn't this a Class*, possibly const?

For a C++ class template instance, I treat it as its own class, although it knows the template from which it was instantiated.

honey the codewitch6-Dec-19 4:56

6-Dec-19 4:56

Greg Utas wrote:
If you know the Class to which the function in question belongs, isn't this a Class*, possibly const?

I do, and it is, though C# has no const modifier in that context.

The trouble is when generics (c#'s answer to C++ templates) are used.

I'd like to treat each template instantiation as its own class but I have nowhere to even put this alternative nametable i'd have to use, and to explain why would involve explaining the CodeDOM and my source up to this point.

It could be that I've painted myself into a corner. That's not unlikely as this is preliminary code I wrote in order to learn how to do this thing.

I don't know yet though. This whole thing is so confusing to me. It's basically the middle part of a compiler (type, member resolution, etc) because C# requires that in order to even be parsed properly.

It has a similar issue that C does in regard to parsing types, but it goes deeper. They just said to hell with simplifying 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.

Greg Utas6-Dec-19 5:17

Greg Utas

6-Dec-19 5:17

Just in case it will help, here is a sketch of how I handle it in C++.

Classes and class templates have type Class, one of whose members is an optional list of template parameters (e.g. <T>).

Class template instances have type ClassInst, derived from Class. Rather than generate mangled names, I allow punctuation that can appear in a template argument list to be valid in an internal identifier. That identifier, with each of its constituent names fully qualified, gets added to the symbol table.

honey the codewitch6-Dec-19 5:33

6-Dec-19 5:33

The only trouble with that for me right now is I need to get the CodeDOM to be able to handle that. I may have to resort to namemangling due to the nature of CodeTypeReference but maybe not. It's making my brain hurt right now so I should probably back away. I'll chew on your tactic though.

I've still got to figure out where to keep all those symbols.

I've also been considering importing *all* types from a given namespace import rather than playing go fish, and if i do that, then I'll end up with a table for my generic instances as well. So we'll see.

There's so much here that's still TBD i think i need to outline or something.

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.

Richard Andrew x646-Dec-19 9:51

Richard Andrew x64

6-Dec-19 9:51

I hope this is not a programming question disguised as an interjection. Horrors!

The difficult we do right away...
...the impossible takes slightly longer.

honey the codewitch6-Dec-19 12:06

6-Dec-19 12:06

I don't even know how to phrase this level of suffering as a question Laugh | :laugh:

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.

englebart9-Dec-19 4:39

englebart

9-Dec-19 4:39

Having one object take and action based on the type of another object is usually an anit-pattern. It typically ends up with a bunch of if else statements or even a switch/case statement in some languages: maintenance nightmare for the future.

The answer you seek might be figured out by asking the object itself for the answer, or just telling it to do something.

var answer = this.TellMeWhatINeedToKnow(...);

or

this.DoWhatIsRightForYourType(...); // I Don't Care How You Accomplish It

You might have to support an interface for this to work, or use some other technique like reflection to see if the method is implemented. Does C# support friend methods like C++?

honey the codewitch9-Dec-19 4:47

Why use .NET technologies vs., say, Node?

9-Dec-19 4:47

I don't have control over the objects I'm manipulating and reflection is off the table.

I've reduced some of the switch casing by factoring it into a visitor over the codedom tree but such is the nature of the beast.

The whole point of this project is that the CodeDOM sucks to use, so I'm building a mini programming language on top of it that spits out the constructs for you.

So you don't need to code nasty bizness like this (even wrapped it's bad magic)

var varDecl = new CodeVariableDeclarationStatement(typeof(int),"i",new CodePrimitiveExpression(0));

just to render this:

int i = 0;

Even wrapped you end up with things like:

var varDecl = CD.Var(typeof(int),"i",CD.Literal(0));

Better, but still hard to read.

Slang is a subset of C#

it allows you to declare these constructs in C# so instead of the above you can do like:

var varDecl = SlangParser.ParseStatement("int i = 0;");

to create the same thing.
or even

var varDecl = SlangParser.ParseStatement("var i = 0;");

it will fill in the type because CodeDOM doesn't support var

and of course it can parse more than statements. It can parse groups of C# source files, statements, expressions, namespaces, types and members at the top level as well. Since it uses recursive descent instead of LL(k) it doesn't get confused by that.

Main issue right now is it's not complete and error handling in the parser stinks.

Edited: vardecls are statements, not expressions Laugh | :laugh:

It's early in the day yet for me. not fully present yet.

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.

Marc Clifton6-Dec-19 3:03

Marc Clifton

6-Dec-19 3:03

This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript.

Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app.

So what's you're take? Why would you use one vs. the other for back-end development?

Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?

Latest Articles:
16 Days: A TypeScript application from concept to implementation
Database Transaction Management across AJAX Calls

Advanced TypeScript Programming Projects

Pete O'Hanlon6-Dec-19 3:05

Pete O'Hanlon

6-Dec-19 3:05

I love TypeScript. As a language, it has so much going for it but, and this is a massive but, if I were rewriting a .NET app now, I would go with .NET Core all the way. The new hosting model is faster than Node's; it runs on just about every platform you could possibly want and the new features such as Span<t> means that it can work with much lower code overhead.

#realJSOP6-Dec-19 4:06

#realJSOP

6-Dec-19 4:06

TypeScript isn't a language as much as it is a wrapper around javascript. It's still javascript.

".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

Fernando A. Gomez F.9-Dec-19 8:43

Fernando A. Gomez F.

9-Dec-19 8:43

Wouldn't that be true of any language? Say, C or C++ being a wrapper around assembly language, C# and Java being a wrapper around their IL, which in turn is a wrapper around assembly?

#realJSOP9-Dec-19 10:34

#realJSOP

9-Dec-19 10:34

No, it's not the same at all. Typescript simply adds features to an existing language, and is not a language itself. Your other examples are languages unto themselves.

Dan Neely6-Dec-19 4:41

Dan Neely

6-Dec-19 4:41

Can you debug typescript as typescript yet, or are you stuck trying to figure out how to map the fugly javascript that it was transpiled to back to your original code?

Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius

Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt

Advanced TypeScript Programming Projects

Pete O'Hanlon6-Dec-19 5:18

Pete O'Hanlon

6-Dec-19 5:18

You've been able to debug TypeScript as TypeScript for a long time now.

Dan Neely6-Dec-19 5:26

Dan Neely

6-Dec-19 5:26

cool, does it work in all browsers or need helper plugins?

Not being able to do so was the biggest downfall of the project using coffeescript I was on some years back; and when I asked about typescript a few times before I never got an answer.

Marc Clifton6-Dec-19 6:59

Marc Clifton

6-Dec-19 6:59

Dan Neely wrote:
cool, does it work in all browsers or need helper plugins?

No plugins required. I'm able to debug TypeScript in VS without problems. VSC - now there I had problems with setting up breakpoints.

Latest Articles:
16 Days: A TypeScript application from concept to implementation
Database Transaction Management across AJAX Calls

Idaho Edokpayi11-Dec-19 8:03

Idaho Edokpayi

11-Dec-19 8:03

You absolutely can.

Idaho Edokpayi

Marc Clifton6-Dec-19 7:17

Marc Clifton

6-Dec-19 7:17

Pete O'Hanlon wrote:
and the new features such as Span<t> means that it can work with much lower code overhead.

Care to elaborate on that a bit? As in, I can understand memory overhead, so I'm curious how it can affect code overhead?

Latest Articles:
16 Days: A TypeScript application from concept to implementation
Database Transaction Management across AJAX Calls

modified 6-Dec-19 13:50pm.

Advanced TypeScript Programming Projects

Pete O'Hanlon8-Dec-19 20:39

Pete O'Hanlon

8-Dec-19 20:39

I was loose with my terminology here. It should, of course, be memory overhead.

F-ES Sitecore6-Dec-19 3:15

F-ES Sitecore

6-Dec-19 3:15

"We're going to stop speaking English and start speaking French."

If there is a compelling reason to do something then do it. If you're doing something simply because you fancy a change or you think other people are doing it so there has to be a reason, then you shouldn't be in charge of making technical decisions.