Is purchase_price the new base_price?

Ahh, indeed, base_price was changed to purchase_price to more accurately reflect the end result of that field. For most stores, the value they put in there will be the price they intend the product to sell for. However, for others, the value they put in there may be just a default price that can be swapped for a different currency, discounted, etc. so that the final value is the purchase price (this happening through Rules and other means). Sorry for the confusion... not sure if I mentioned this change anywhere besides the commit message.

Ubercart will never be a professional application until it sticks to professional terminology.
Drupal Commerce is taking the same way.

Purchase price is the price that is paid for anything that is bought. Notice the past tense.

Compared to Ubercart, we are talking about "sell_price", which is more or less explanatory.
"Purchase price" = UC "cost".

Will review, but this is hardly critical, esp. at this point.

Mentioned UC because it looks like DC is going to become its clone. It is very sad, because people do not need another UC - there is one already.
The only chance for DC to beat UC and to take a piece of its market - is to be professional. Such things as "a woman I am married to" should never happen here. There is a term "wife". If we are going to please all the people who do not know basic business terms, we are going to be nowhere. I would target the real traders, not international one-day paypal super-sellers. I would sacrifice all the UC usage statistics for the sake of hundreds but real users.
I understand the need to use the UC development experience. But it is difficult to understand how a professional product can be built without professional terms and features. If we do not see all the picture, we can always have a look at other established e-commerce solutions, like IBM WebSphere, Oracle WebLogic, Microsoft Commerce, etc.
Sorry if I'm wrong.

esp. at this point

What point? Are there many DC consumers already? Are they big brands? Are there any contractual obligations?
Actually, there is plenty of time. D7 will not be released this year, and will not be usable for the whole next year.

You're misreading me and the direction of the project.

I said this is not a critical issue "at this point" because we are in alpha where everything is subject to change and the name of a variable (that no one sees - this is important, it still appears as "Price" to the end user) does not break the functionality of the code or horribly ruin the project. That's why it isn't critical "at this point".

Really, though, sell price and purchase price are nearly synonymous, two sides of the same coin. Both are going to be a misnomer for that field, though, so maybe I should've left it at base_price - but the point stands that "Price" is what any end user will see.

I left this issue open so it could be considered, but pointing this out as a reason we're becoming more like Ubercart is farcical. This decision had nothing to do with Ubercart at all, and I daresay the project as a whole differentiates itself enough for this to not be a problem in the least bit. For the record, I'm not competing against my prior work, we've made significant changes to learn from our mistakes and ease the use of the software for larger businesses, and I think you're overreacting. : P

I think you're overreacting

Guilty :)

I do not agree that variables' names are not important. I had to dig into UC, and my opinion was the following: UC was built without any initial feature set estimation. Features had being added chaotically. It is difficult to work with its internals.
One can see a mess of prices and totals in its code. Out of the box, the cart checkout says "Subtotal" and cart block says "Total". It is an intolerable distinction. It is ok for a 10 bucks sale but is embarrassing for a 10k sale.

"Base price" is even more bad choice, imo. Base to what? Actually, there is only one price - line item price per unit. That's all, we do not have any other prices (in basic install). So, there is no need for "base" prefix.

Could you please list all DC "price" and "total" variables together with their corresponding t() strings?

What you're missing is that the actual sell price of an object is not determined by that field alone. The contents of that field can be modified to arrive at the eventual sell price via Rules. That's why it was originally named base_price - it was a starting point, but the amount that it actually sells for would be derived otherwise.

Moving to the switch to purchase_price, my thought train was that base_price is (as you said) fairly meaningless and ambiguous. At the very least, it didn't seem to convey to you that the price was meant to be modified, and I'm not sure there's a good short variable name for that. Switching it to purchase_price, then, was more descriptive of the end result of that field. I cannot name it something useful from the backend side, so if I name it for its intended end (i.e. this is the field that will be transformed into the actual purchase price at the time of checkout), then it at least has some meaning.

Naturally, developer concerns must be taken into consideration. But at the same time, a variable with a name that isn't immediately obvious can be understood if it's used consistently. On the front end, the variable name will be visible in Views, which to me is where "normals" will be interacting with the code. So, I was trying to give it a name that might make sense to a non-dev - something that communicates to them that "where this price is displayed will be the customer's purchase price" or in Rules "what I'm modifying right now it the customer's purchase price". Perhaps sell_price is a better idea, with the "Purchase price" being the finally altered version of the sell_price. It's not set in stone. : )

What do you think, given the description of the field above?

Now I understand it better.

What you're missing is that the actual sell price of an object is not determined by that field alone. The contents of that field can be modified to arrive at the eventual sell price via Rules. That's why it was originally named base_price - it was a starting point, but the amount that it actually sells for would be derived otherwise.

Yes, it is possible, and quite common. Indeed, sometimes there are several prices in pricelists, and they are conditional.
But it looks like you are talking about calculations (conditional actions which affect price output) based on expense, not the price itself. If someone is going to sell a book for A + 20% = B (120$), here A is "expenses" and B is "price". You can not call A a price in no way, it is neither "base price", nor any other price. It is what you called in UC a "cost". So, to calculate the price itself, a user must enter "cost" then add a condition (for instance "+20%") and he'll get it. Or he can enter it manually, right away.

Regarding "purchase price" I would avoid it if possible. The only typical situation is: A man goes to shop > buys(purchases) a book for 100$ > brings it to his own shop and sells for 120$. Here we have purchase price = 100 and sell price = 120. But still, it is wrong to call those 100$ a purchase price. It is not "price", it is "expense/cost". It is a "purchase price" for a customer only, which is never viable without that "customer's" prefix.

So, to sum up, the problem is not in the prefix. The problem is in the wrong usage of the word "price". If we call any intermediate value a "price" we will end up with a dozen of prices pretty soon.

Pretty tricky situation...

(edit) Ok, you are right, a decision should be made. Maybe not the best decision but it should be compromising. I give up, let it be a set of various "prices".
Sorry for my really poor English :)

hehe Your English is perfectly understandable, and you raise a good point. I did not think about the connotation of "purchase_price" being the price you paid to acquire the item. In that regard, sell would be more accurate. I'd still feel comfortable calling the field some sort of price, because a lot of stores will not use any sort of Rule to alter the price. Others will also do what you've said and implement "Price lists" by having multiple price fields on a product. Drupal Commerce still needs to have a simple way to figure out the sell price even with multiple fields, so the first step would be swapping in the proper price value from the matching "price list" field.

All in all.. it's fairly awkward, and the problem is a result of trying to avoid two or three separate systems for deriving a price for a product. Will point Damien this direction and see if he has any input.

Ok, so field name prefixing came to the rescue... purchase_price was a misnomer, since this is more of a sell_price - but the field itself doesn't contain the final sell price for a product when using pricing rules. As such, I've just renamed the field to commerce_price as part of #1047078: Prefix Commerce module governed fields with commerce_.