Kind of an OOP related question, maybe

Why isn't the fact that a string is a sequence of characters an implementation detail?

(remember that I do C and assembly for fun where strings really ARE an array of characters / pointer to an array of characters)

I thought the String object was assumed to encapsulate how the data is stored, though I guess an Enumerable is just another interface, so maybe it doesn't matter, maybe it does (right to left languages?)

I mostly ask this because knowing that a string really IS a char array somewhere makes it kind of hard to figure out what parts of that would be useful to callers and what parts are just a leaky abstraction (personally I'm alright with String having IEnumerable, but I'd use IEnumerable in that case knowing I may need to remember how RTL strings are handled).

@jrh IEnumerable does not break encapsulation. It just says the object contains many things that you can loop over. RTL does not pose any challenges regarding text storage, only text rendering and user interfaces become complicated, precisely because the visual order isn't the same as the logical order.

If string iteration breaks encapsulation, it's because of the concept of "char". Is that a byte? A encoding-specific code unit? An Unicode code point? A visual character (grapheme cluster) with all diacritics and modifiers? There are many ways how strings can deal with text encoding.

(1) The system might be encoding-oblivious and only store bytes (like char[] in C, std::string in C++). Disadvantage: no random-access logical character access, and programmers have to track encoding manually.

(2) They might be encoding-transparent and only deal in logical characters (like str in Python3). Disadvantage: no random access unless we use wasteful UTF32 internally.

Of course Java and .NET try to do (2) but ended up doing something more like (1) because their chars are UTF16 code units. An Unicode code point may be represented as one or two chars. So if you loop over an IEnumerable<char> like String, you may actually have only half a logical character. That's terribly wrong. The programmer having to understand UTF16 surrogate pairs, that's breaking encapsulation.

@amon I sort of feel like I'm getting into OOP lawyer territory here but would it be possible to make the case that RTL is only for text rendering and is only a visual ordering of characters may also be an implementation detail of string? Theoretically, is there a metric for putting RTL clearly not within the responsibilities of string, or was it just a convenient design that stuck?

I could make an (IMO, rather lame) argument that programmers in RTL cultures wouldn't expect the data to be stored backwards?

Of course this sort of gets into the murky territory of whether an object needs to handle how it's displayed, and whether the value property of an object is a form of displaying the object, I guess.

Luckily, all writing systems that I know of have a concept of direction – whether top-down or LTR or RTL or alternating RTL and LTR for each line…. That means the character can be ordered, and how the order is defined is uninteresting. In a computer, the first character is not stored on the “left” or the “right” of memory, there's simply “first” and “last”.

No, a string should not concern itself with GUIs, but only with data storage. E.g. a HTTP server needs to deal with strings and encodings, but never with writing direction.

@amon so should IEnumerable follow the order of the characters in the culture (if so, which culture?) or the order of the characters in LTR?

on second thought I think I want to think this through more

The characters should be represented in logical order. Smarter people than me have thought about bidi text storage for the Unicode standard. Each Unicode character has a bidi-class (e.g. LTR or RTL or characters like punctuation that have no direction of their own, and some other types). If this is simpler to think about: logical order is the order in which the characters are pronounced, not in the order in which they appear visually.

I'm still relatively newish to modern web development, are there ORMs that aren't convention-driven? In my experiences, these convention-driven ORMs tend to favor rapid development over good performance, based on their conventional table structure and how they generate queries. Maybe I'm looking at the wrong thing.

A good example is Rails (haven't used Rails 5, so maybe things are better) and ActiveRecord. It's great for developers. But it makes it harder to enforce good data integrity in the database (FK relationships and other structures require extra steps, relying on the model for everything). It also doesn't scale terribly well for performance (unless there are tricks I don't know about yet).

@ThomasOwens Really? Why don't you just add constraints to the database, and catch the resulting exceptions? Forces the developers to fix their code.

That's how we did it, old skool. How we still do it.

@RobertHarvey You can. However, in a migration, it's extra manual steps. At least in Rails 4.

All of the relations are captured in the models. You can add FK relationships and other constraints in a migration.

The other problem is querying. If you don't use their conventions for storing data, it becomes harder to manage.

Why does Rails have a voice in the database design?

Because ActiveRecord is a part of Rails. You can swap out ActiveRecord for a different ORM.

But then again, you could use a lighter weight framework (like Sinatra) that doesn't come bundled with all sorts of other stuff.

And choose your own ORM from day one. It's still a matter of finding an ORM that makes it easy to model data your own way rather than in terms of its conventions.

Well, we still do "database first" at my shop. In fact, a lot of our work is "headless" (i.e. genuine SQL queries, no code-generated DTO's). Dapper would be right at home.

I've never heard of Dapper. Let me look into it. Is it an ORM?

It's the ORM that Stack Exchange uses to run all of their sites.

Interesting. It looks like you write your custom SQL and load it into objects.

So basically something like Dapper.ExecuteQuery<DTOClass>("SELECT blah from blah", params);

So you can do complex queries as long as you have a class to load the columns into.

Exactly. EF has a nearly identical query method, which we use.

So the database and classes are independent of each other.

In something like ActiveRecord, it expects a class for every database table with attributes for every column. Its a mapping from your domain objects to your database. Easy to comprehend and develop, but not always the most performant. This seems to allow you to separate that.

You don't even need a DTO if you don't want one. You can return a dynamic.

Yeah, it's a highly-efficient way to return data. It's a big part of the reason that SE sites are so fast.

I think that's what I'm looking for. I don't see an equivalent for Ruby.

But it seems like Java and .NET have similar things.

I really like working this way. The shop I currently work for has gotten me really comfortable writing SQL statements, and I love the performance. Also, EF can break things in really horrible ways if you're not careful with it.

Yeah. It's definitely going to be a learning curve. I know I didn't really learn about SQL in any of my classes. I did learn about conceptual database (primarily relational) design and some basics, but then again I didn't take a database-specific course, just information systems architecture course.

Learning SQL will change your life.

A learning curve for developers, I mean. Especially since a good chunk is going to be dependent on your DBMS.

Yeah, it's too bad there's so many vendor-specific variations of SQL. You can limit yourself to ANSI SQL, but it's not always fun to do that; you'd be missing out on some nice vendor-specific optimizations. Though for ORM use, I imagine it doesn't matter all that much, and ANSI SQL would be perfectly acceptable.

Dapper is here, with examples.

To be clear, we don't actually use Dapper. We use a mix of headless calls in EF with raw SQL, and Linq calls with EF proper. We mix and match where we feel it is appropriate.

But I've tested Dapper. It's a code-compatible drop-in replacement for the EF headless calls, and it's mind-blowingly fast.

@RobertHarvey Ideally, I wouldn't want a mix and match. I'd like a thin layer that sits between my well-designed database and my well-designed domain model.

That works too.

Is that not what Dapper is?

It seems like it is. I can write my queries over whatever my database is and load stuff into whatever my domain model is.

Well, with Dapper (and EF headless calls) you get back a collection of DTO's, right? You can use ordinary linq on those.

But EF linq generates SQL, and returns an IQueryable. So there's some deferred execution going on there.

Yeah, looks that way. I wish there was something like that in Ruby. I'd promote its use at work.

Also this: samsaffron.com/archive/2011/03/30/…

@ThomasOwens This looks interesting: rom-rb.org

@RobertHarvey Is Dapper an implementation of the DataMapper pattern?

[looks up datamapper]

Fowler to the rescue.

@ThomasOwens Yes, that seems like an apt description.

Though to be fair, that doesn't seem like much of a "pattern" to me. It's barely a patt.

@RobertHarvey Some of the POEAA patterns are...meh. Money?

Sells books.

Did you read the Money pattern, though?

That does not need to be a pattern.

Holy crap. There really is a "Money" pattern. No wonder programmers think everything is a pattern.

Did you really think I could make something that awful up?

People like Martin Fowler and Bob Martin have a disproportionate effect on the industry. Though to be fair, I don't think either one of them counted on people learning their patterns and principles before learning how to write code.

Maybe if I change my name to Martin, I can get rich selling dubious programming patterns and principles.

@RobertHarvey Change your name to Martin Martin.

Double the effect, obviously.

Heh.

:D

Hey, we're all blue! :D

I think we're one of the blue-est non-mod-only rooms on the network.

Any tips?

Gimme advice

If you see any user that mentions cross posting messages to Programmers or Software Engineering, suspend them for at least 365 days. :P

That would escalate too fast. Maybe start with a month?

:D

@AaronHall Tips?

Yeah, lecture the noob mod.

@AaronHall What did you have in mind? Anything specific?

[votes to close as Too Broad] :P

How to be a great software developer

@AaronHall Here's my go-to philosophy as a moderator: Does This Belong Here? That has relieved me of much navel gazing and splitting hairs. I no longer worry about things like "Is this not- an-answer answer not an answer?" I simply ask myself "does this belong here?" If it clearly does not, BOOM.

ok

Stack Overflow generates an enormous amount of flags. Save yourself some time and heartache by keeping things simple and not sweating the small stuff.

And don't let yourself get burned out. The moment you feel that, step away and go do something else for awhile.

Yeah. My goal: my fellow moderators declared I did a good job.

My goal: leaving the area a little cleaner than when I arrived.

Would be nice if the community agrees.

Kudos is nice, but it's a thankless job, so don't do it because someone might think you're good at it. If you're doing it properly, you won't be noticed.

Yeah, don't get noticed. :)

By that definition, I'm not one of the best mods. Bill The Lizard was. He was a machine; he did at least a couple hundred flags a day, and got very few complaints. That said, if nobody ever complains about you, you're probably not moderating hard enough.

Yeah, I thought about that too.

So that's my two cents. Probably what it's worth. :)

When I was in door-to-door book sales, they said if the company wasn't getting a complaint once a week, you weren't asking for the sale hard enough.

I don't think I got any complaints for the whole summer. I'm not a great salesman. :D

The greatest of salespeople don't have to ask for the sale. People buy from them. There are many reasons why; one reason is those kinds of salespeople don't sell books or vacuum cleaners door-to-door, unless they really believe one hundred percent in what they're selling.

That's a special breed. You don't need those kinds of mad skillz to be a Stack Overflow mod. You just need to know how to sweep the floor and clean up after the occasional vomit.

(it's not a glamorous job)

There's different kinds of sales, there's impulse buys (which it turned out my books for the most part, were) and there's important buys with a potentially longer sales cycle (which have to be sold an entirely different way). And the difference is relative, an item can be one kind for one party, and another kind for another. You could probably make a lot more distinctions and build a professional sales marketing textbook out of that.

I'm sure moderating SO is a different beast that moderating SE.

I'd love to experience the life of an SO mod for a week.

You can work through more flags on SO in one day that you probably get on Programmers in a month.

In a year. :D

Actually, more flags get cast on Stack Overflow in one day than I've probably cast on SE.SE in the entire time I have been a user.

@RobertHarvey Just out of curiosity, why was this question too broad? softwareengineering.stackexchange.com/questions/337395/…

if the OP doesn't use any OS APIs wouldn't it just be a matter of decompiling and recompiling, making the answer just "yes"?