This feels like another "never use if statements". What's the alternative (I assuming you're also not endorsing the use of Object.create), canning prototypes altogether?

this is much more practical, as in, you should seriously actually follow this advice all the time. Object.create is fine, nothing to do with this.

the alternatives are the method recommended in the crockford link, or just use a functional style. if that isn't clear show me an example where you think you need prototype chains, and i'll show you a better alternative.

Now I'm super confused. Never use "new", which initializes an object with a prototype and calls a constructor function, but Object.create is fine, which does the same thing (afaik) minus constructor initialization?

You're right. I was thinking of Object.assign when I wrote that. If you're building up "inheritance" hierarchies with Object.create and prototypes, I'd recommend avoiding that too. At least, it has the advantage of being more explicit about how the JS code is working, versus the "new" operator which tries to paper it over and make it seem like Java.

This conversation would probably be more productive if we were discussing a specific example and the best way to solve it.

Here's the object that started my questions about pulling an object from a database:

Not at all complex, but there's a couple reasons why this feels inherently right to me:
- I'm assuming that if I do this the other way around (make a factory function that creates a new object, assigns it some properties including the save() function, returns it), then when I store this object in the Mongo database, it will have the function included? Unless Mongo specifically excludes functions from being serialized, because otherwise functions are just like any other property on an object, right?
- while it's a JS implementation detail I probably shouldn't care about, I'll sleep better at night knowing that this function is in a prototype in one place, rather than repeated in memory for every single user object

regarding your last point, taken on its own, unless you really have a proven need for such memory optimization (ie, hundredes of thousands of objects or something like that), you should prefer having the repeated memory for each object. This is the whole point of the crockford pattern. In one of his recent videos online (i've linked to it before, but don't have time to dig it up now), he has a whole rant about how worrying about memory in this case is like programming as if it were 30 years ago, rather than as if we all had gigs of RAM in our pockets. that is, you should prefer the thing that is easier to reason about and less likely to bite you at runtime, unless you have a good reason not to.

a few other recommendations, imo even more important.

1. if you're going to put a save function on your user object, you should at the very least be injecting the "db" dependency.
2. better yet, don't put the save function on your user object. Instead, have a UserRepository object with a "save(user)" method, or just a plain function "saveUser(user)". Saving, validation, and the user data itself -- these are separate concerns and should be kept that way.

intuitively, it's kind of odd to want to be storing the function that contains the js logic for how to save the user in the database records themselves, which is what you want to do. your database is for storing data. all that saving stuff is application logic, and changes at different rates and for different reasons than your data. say you have a bunch of users stored, along with their save functions. then you realize there's some bug in your save function, or you want to add something to it or whatever, well now, instead of just updating a save function in your code, you're going to also have to update every single user record in your database.

EDIT: just re-reading your example, if you are only going to do exactly what you have in that code, and delegate the saving of the user to the "db" or repo object, that's a lot more acceptable. but in that case, all you're getting is a tiny bit of syntactic sugar (user.save() vs db.save(user)), and since you should be injecting the db anyway, that first bit is really "user.save(db)" or else injecting the db when user is created. so all told, even if some of my concerns from the last paragraph don't apply, i still think there's no advantage to putting the save() on the user object, and it's probably conceptually muddled. and note, even with a simple one line delegation, my concerns about having to update your user records would still apply if you wanted to, eg, rename either the user's "save" method or the db's "saveUser" method.

On the bus to work atm but to clarify something I may not have written clearly: I most definitely do NOT want to store the save function in the database. My first pro-prototype point was that it's better if the function doesn't get saved, if it's in the prototype and not the object. (assuming Mongo would save it if it were in the object, which I'm not sure of)

ok, that's true, that would be better than saving it. but i still prefer in this case keeping the save function separate from the user, and let the user be a pure data object, as it were.

That is, you are suggesting, say "{name: 'john', age: 20}" is stored in the database, that's the pure data. Then you want to have let's call it "SaveableUser" which has the save method from above on it. So you'd grab your user from the db, then wrap it up:

u = SaveableUser(userFromDb)

and now use "u" in your code, and you have a save method. There are reasons I don't love that, but I think the better angle for the purposes of this discussion is to ask: What does that gain you over having always just saving users with db.saveUser(userFromDb) or similar?

I think you know this already but don't forget that a function is just a pointer as long as you don't force it to close over the environment by referring to outside variables (closure). The better reason to use prototypes IMO is that JS engines are much more easily able to translate them into class equivalents and essentially perform static type analysis and that it's easier to read for non-JS programmers.

I love this discussion but to some extent what's going on is that you just need to make a few nice cheeseburgers and gaming_mouse is giving gourmet chef advice on how to properly age steaks. Definitely good things to think about at some point but I would try to do the simplest thing that works.

definitely agree that getting things done and building (and fixing later) is the way to go, and that's a lesson you never stop learning. that said, the specific advice i'm giving him isn't hard to do or advanced -- it's actually simpler than what he's trying to do. i'm saying, just use plain functions and plain data, and don't add a save() method to your user object. your comment would be more apt if i was recommending that he encapsulate all his error conditions in monads

Sure. And almost value objects that aren't truly value objects and have a long list of methods that have global side effects are one of the common anti-patterns in the industry due to widespread misunderstanding of OO design that's divorced from practical concerns.

I'll add that the misunderstanding is so deep that most people don't even know what value objects are or why they should prefer them.

Does that make it a universal maxim, though - thou shalt not make data objects with methods? In this particular example you can say, maybe the save() method shouldn't live with user, but I'd imagine there are cases (or based on your exchange with candybar above, maybe not) where you would want to have objects with methods that get stored into a db.

I don't have the expose the database to the rest of my code, because the rest of my code doesn't care about it. It gets a user, it makes changes to it, it tells the user to save itself.

I do see the logic of the design you're proposing w/ a UserRepository, and if I were writing this in, say, C++ that's exactly what I would do. It feels like the language features of Javascript allow me to simplify things more though, where I can just have the user be like "yeah, I know how to forward this request to the database", and the rest of my code doesn't have to care. In C++ that would create some pretty ugly coupling, but in this environment I'm free from having to worry about typing everything and making sure this type knows the definition of that type etc etc. It's also possible I'm abusing this newfound freedom.

If you're adding a method to an object though (w/ the factory style, not via prototype), then you're implicitly capturing a different 'this' for each function, right?

I do feel like I learn a lot from these discussions and pushing back against things I don't quite understand, so I do appreciate the thoughts even if they're a bit advanced for my level of understanding of JS at this point.

It's more that you have to distinguish between behavior that is local to the object and behavior that has global side effects and requires external dependencies. An exaggerated version of this would be having a built-in Datetime class in some language having setAsSystemDatetime method that sets the system time to its value.

But you are exposing it - now any part of the application that has a copy of the user object is dependent on the database. You want to make dependency as explicit and as infrequent as possible - implicit dependency that's everywhere is much harder to deal with.

I'm not sure exactly what you mean here in terms of the difference between C++ and JavaScript - are you talking about the possibility of circular dependency in C++?

That's handled at the call site (it's just an additional argument and essentially syntactic transformation) so you don't have to worry about this. Generally you only have to worry about is the immediate function-level scope where the closure is made.

I'm not sure I know what you mean. It "depends" on it being there under the hood, but the database is abstracted away from any parts of the application that have a copy of the user. In particular, I can pass users around without passing the database around to every module that might make changes to a user.

More like, strong typing means that I need to define an interface for the database to inject into the user, and I guess the C++ part of my brain just tells me after this many years of working on it that doing that in C++ is blurring the lines of ownership to an uncomfortable degree. So in that sense, I suppose I am abusing this newfound JS freedom by using it for designs that I wouldn't consider to be very good in C++.

This makes all your modules difficult to reuse in another context and extremely difficult to test confidently.

For a more full treatment of the issues at least in regards to testing, the youtube videos linked here are pretty good:

http://forumserver.twoplustwo.com/sh...ostcount=17248

Do you mean like header files? If you're crossing module boundaries within JS, you also have to do "require" or whatever. I don't see any difference between JS and C++ in this regard other than that JS doesn't come with any module boundaries by default on the browser side. At some point you have to call whatever it is that does the real work and it has to be defined somewhere.

I guess where it really starts is:

https://en.wikipedia.org/wiki/Single...lity_principle

and

https://en.wikipedia.org/wiki/Law_of_Demeter

So, if I pass my 'user' to another module that doesn't require the module where 'user' is defined, does that mean it won't know about the user prototype?

Oh I see that case will work but it's even more problematic if your modules are silently depending on objects having certain magic properties without having that dependency documented.

as usual, candybar has saved me the trouble of answering many questions, and gave some good answers to this already, but i wanted to add that the general solution to the problem you're asking about is to use dependency injection and containers. containers have all the "global" variables (such as a DB object) inside of them, and your application code depends on these containers (or single one), which get injected into the parts that need it. that way, for your test code, for example, you simply setup a container with a local in memory database, and you don't have to touch the application code.

basically, the wiring up and configuration of all the external dependencies is "contained" in one place. and all you have to change up the wires to create a test version vs a production version, or to make other changes. it's really nice.

there are a couple good container gems for ruby. i'm not as familiar with the node ones, but i've been looking myself and recently found this: https://github.com/jeffijoe/awilix. i can't speak to the quality of it yet, but the examples show you the basic ideas.

Hello world!

Cliffs:

- I was taught C/C++ at uni but have largely forgotten it;
- I'm considering writing a GUI for interaction with a DB;
- I'm not going to program for a living;
- I'm not sure if old habits die hard or if learning Python (or what else, Java?) from 0 is a good idea.
__________________________

In the near future, I might want to write a couple of Windows programs for personal use and I have a doubt about which language to employ.

As the typical hourly salary of a junior / senior developer in Russia and Belarus is $5 / $10 (lol), a professional programming career is out of question imo - online poker is still going to be good for year a so and that's enough as I'm going to downshift shortly anyway.

I was taught C/C++ (not C#) at university but rather poorly and with focus on math and CS; I sometimes write in AutoHotKey nowadays, write primitive functional code in plain C from time to time but have forgotten the C++ OOP syntax (not principles) almost entirely, as OOP (incl. even a bit of Qt) was only in theoretical lectures which gave me basically zero knowledge as I was never forced to apply it in practice.

Another solid alternative that comes to mind is Python but I have zero practical knowledge of it (or any other mainstream programming language) and what worries me is that Python is interpreted, which might result in slow performance though I'm quite insensitive to it (see project descriptions below), and it's dynamically typed, which might make debugging harder as I generally code rather sloppily.

As far as I've seen on the Internet, pyQt is recommended as an easier GUI framework than wxPython, but they're wrappers around frameworks written in C++ (Qt and wxWidgets), and OpenCV 2.4 (for image pattern matching) has a Python binding but is a C++ API, so I thought it would be then more logical to code in C++ itself.

I'm not convinced that delegating the projects to someone else is a great solution because I'd ideally need to give them detailed specifications anyway which are already the most part of the programming job

Here are the pending tasks.
__________________________

Mini-project:

A parser extracting data from text files within a folder using regex match and updating an existing small PostgreSQL DB with the data, to be run once a day or even rarer.

Big project:

A GUI for interaction with its own small DB (structured in a custom way), displaying a single window with essentially text, forms and buttons only, reading keyboard input into the forms and/or mouse clicks on the forms and buttons.

An incremental update (v. 2.0) will scrape screenshots into several DB fields (every second or so) by means of kNN (k=1), which can still be corrected by manual keyboard / mouse input if pattern matching fails.
__________________________

Advice on libraries / modules is also welcome, TIA!

If your C++ is not very good, then I would go with python or a similar language. You'll have to work hard to bring your C++ up to something that will work well, imo, and learning python is not very hard. In my experience a top notch c++ dev can work as fast as a pretty good python dev, but mediocre c++ dev will lag way behind a mediocre python dev, in terms of Getting Things Done. Python probably contains fewer pitfalls also, for someone without a lot of experience in programming in general. It's standard library is also extremely large, with lots of additional modules that are very easy to find and install. In comparison, C++s stdlib is fairly spare, and you may have to find/compile/install libraries you want to use (this depends a little on what you're trying to do, and what operating system you're on. C++ on linux is way easier than C++ in windows, imo)

For opencv I guess I definitely prefer C++. Last I checked the python opencv library was heavily based on the "C" style library interface, not the C++ one. The C++ one, again in my opinion, is more natural to work in and I definitely prefer it over the C style one. However, a lot of the available tutorial info on the web is for the C style stuff. In any case, opencv has changed a lot over the last few years and much of the tutorial info you'll find on the web is out of date. Prepare yourself to learn from it, but don't expect to be able to copy/paste working code from tutorials.

Thanks for the assessment, the time needed to make something that works is the biggest issue indeed.

I'm well aware of how awesome Linux is , and I might as well eventually switch to working in Linux as I won't need to run desktop poker clients at the same time as my code; the use of Windows 7 is just a matter of habit as my poker sites aren't cross-platform (except browser poker which is useless), I want to use a HUD when I do play and I'm not sure if all the poker setup would work properly in a virtual box.

However, I'm certainly not tied to OpenCV, can use SciPy / scikit-learn or do without an image recognition library at all (the Euclidean distance between images is easy to compute directly and will likely be enough).

Python would be fine or you could learn C#, the C-style syntax might be more familiar. I have no experience with Python IDEs so idk what they're like, but it might be an advantage having Visual Studio with C#. Python being interpreted is definitely not a problem for your purposes.

Thanks for reminding me about C#, I was looking for its comparison with Python at some point and don't remember why I ruled it out.