In Which @Captain asks C# Beginner Questions

Captain

There is an address object in the framework somewhere, a pretty good one afaik.

Cool, I'll look around. I'll be doing US addresses only, so it should be fine. Is it the CivicAddress class?

dotnet-bot

CivicAddress Class (System.Device.Location)

Represents a civic address. A civic address can include fields such as street address, postal code, state/province, and country or region.

If there isn't, you can make one, or use an enum, since those have methods to parse them.

Except that there's logic to how ISO country codes work, so they're not accurately modeled by an enum, so that it's a non-trivial bit of work to implement the 200+ country codes. (Been there, done that, for a Haskell library I wrote)

I guess I'll just use the official ISO xml file if/when I need country codes. I was just hoping for examples of solutions for that "kind" of thing: states, measures, etc -- the stuff you find at the back of a dictionary.

dkf

@Captain said in In Which @Captain asks C# Beginner Questions:

I was just hoping for examples of solutions for that "kind" of thing: states, measures, etc -- the stuff you find at the back of a dictionary.

That's a really deep rabbit hole to chase down (it leads to things like RDF and OWL). Apply YAGNI and stop worrying about such things until you find that you need to care for a specific use-case.

Captain

@dkf I need the 50 states. I figured there might be a "simple", commonly used library for "facts" about the real world, since virtually everybody has to deal with these domains and .Net is so much better than Haskell.

But I get your point about complexity.

Jaloopa

@Captain there are Nuget packages but nothing built in to the standard library

dkf

@Jaloopa said in In Which @Captain asks C# Beginner Questions:

nothing built in to the standard library

And why should there be? That would just open the C# spec up to needing to be changed in a hurry if Puerto Rico ever votes to become a state, which is ridiculous. Indeed, for many of the cases where you care about having a list of states, PR and DC are state-like (e.g., for addressing purposes), but there are also cases where they aren't. You can bet that if you try to define it in a standard way, someone will insist on making you deal with all the complexity that you usually can ignore. You'd probably also have to deal with some places insisting that they are commonwealths and not states.

It pays to keep things simple and define terms to mean what is useful to you. I really mean this.

anonymous234

@Captain For something like countries or states, that doesn't change often, the best solution would probably be custom class/struct with the data hard coded. It could be simply updated via NuGet whenever there's any change.

For something larger or more frequently updated, like a list of all cities in the US, you could have a custom class but with the data loaded from an XML file somewhere.

For addresses... globally, there's no common elements other than country and maybe post code. Just store it as a string and let the post office deal with it. In some particular countries, the government or post office might have an official database of valid cities and addresses in them (I only assume that because I've seen many websites auto-fill mine), or you could rely on a 3rd party service (Google Maps comes to mind). Or you could store a string and let the post office deal with it.

The problem is, because "real world things" are so variable and fuzzy, there's no other way to represent them than by writing custom code for each one (and even that only works for the simplest cases). People have tried to make a "common format to represent everything" many times and it has never really caught on, probably because the resulting thing was so complex that they basically just reinvented XML (funny when you think about it, custom types are only useful because of the things you can't store in them).

dkf

@anonymous234 said in In Which @Captain asks C# Beginner Questions:

reinvented XML

Ontologies are often serialised using XML (they're actually using RDF, but RDF can be written using XML among a bunch of other formats; the format is actually really a bunch of triples, (subject,verb,object), where all three are URLs). When you're just stating facts they're simple enough, but when you start trying to add reasoning (even just handling synonyms) then the excrement hits the ventilator in short order.

boomzilla

@Captain said in In Which @Captain asks C# Beginner Questions:

I need the 50 states.

Don't forget territories and overseas military addresses (I assume...maybe that's really not an issue for you, but it's the sort of thing that's easy to overlook).

aliceif

@boomzilla said in In Which @Captain asks C# Beginner Questions:

territories

Is that what DC is?

boomzilla

@aliceif said in In Which @Captain asks C# Beginner Questions:

Is that what DC is?

Actually, no. It's a special thing of its own meant to hold the national capital but not be part of any state (as it was originally). Territories are other places that are part of the US but that haven't become a state yet.

The District of Columbia was carved out of Maryland and Virginia, though the Virginia part was later ceded back to the state, which is why it's no longer square shaped.

error

@Captain said in In Which @Captain asks C# Beginner Questions:

.Net is so much better than Haskell.

Not sure how sarcastic this remark is meant to be.

ScholRLEA

@dkf Perhaps the best solution - not a good one, but the best one can hope for - is a set of webservices fronting a database of localization information, which applications could download a local copy of the relevant portions of, and periodically poll to see if anything has been updated. It doesn't solve all of the problem, not even close (there would be issues of connectivity, frequency of updates, data format, and a host of other undecidable propositions), but it would be an improvement over every application having to have it's own hand-rolled whenever that sort of information is needed.

The real problem with something like that is dealing with disputed territorial claims, conflicting or overlapping jurisidictional assertions, and so forth, which would mean that one way or another you'd be pissing in someones pool. These can get you into political or even legal hot water, as anyone who remembers the problems Encarta had over Kashmir (the Indian government banned it because it marked the region as 'disputed'), Wikipedia over Tibet and Taiwan (which got it blocked in China on multiple occasions - eh. what else is new?), or anyone who stuck their johnson in the hornets' nest that is Israel and the Palestinian Authority, could tell you.

In fact, I wouldn't be surprised if one or more such services already existed, though I don't know of any offhand. I should go check on that...

Jaloopa

@ScholRLEA there's also the timezone map in Windows 95

The Old New Thing

Captain

I'm starting to hate how weakly typed C# is. Especially, for example, EntityFramework, which uses ints for every single key.

That would be okay, except that if I want to change my code from:

 thing = (from p in db.Patients where p.PersonId.Equals(pid) select p).First()

to

 thing = (from p in db.Patients where p.PatientId.Equals(pid) select p).First()

The mother fucker type checks despite being utterly wrong. FUCK YOU! (Haskell has a thing called "Persistent" which is a lot like EntityFramework, except it wraps field values in their own types so you never make that stupid refactoring mistake I just did.)

dkf

@Captain said in In Which @Captain asks C# Beginner Questions:

The mother fucker type checks despite being utterly wrong. FUCK YOU!

The problem is that if the ID is communicated outside the system (as happens far too often) the only information you've got is that it is looks like an integral number. Types are all very well, but they're always fragile when they hit reality.

Captain

@dkf said in In Which @Captain asks C# Beginner Questions:

The problem is that if the ID is communicated outside the system (as happens far too often) the only information you've got is that it is looks like an integral number. Types are all very well, but they're always fragile when they hit reality.

Sure, but the refactoring happened "in" the system. I didn't take in any data EntityFramework doesn't know about. The EF model isn't rich enough to catch simple mistakes.

With Haskell, I could use a newtype, which is basically a new type identity that wraps over a "concrete" value. So I could have

data Person = Person { firstName :: FirstName
                     , lastName :: LastName
                     }

newtype Key Person = PersonKey Int
newtype FirstName = FirstName String
newtype LastName = LastName String

newtype Key Patient = PatientKey Int

instead of

class Person
{
    public *int* PersonId { get; set; }
    public *string* FirstName { get; set; }
    public *string* LastName { get; set; }
}

I get that if I round trip a key outside of the system, I'll have to parse it and pick a type for it. (And then I'm right back where I started, except hopefully with a much smaller scope for concrete type errors, since I hopefully wouldn't be round-tripping anywhere near as often as I write queries)

But not all ints are created equal, and it's good to be able to keep them apart conceptually after they've been parsed and sorted out.

Jaloopa

@Captain In Linq to SQL, so presumably EF as well, you can do

thing = (from p in db.Patients where p.Person.Equals(person) select p).First();

The relations are encoded via the foreign keys in the database