Thank you.
I'm not very familiarized with how free software communities work.
If I code the first patch, then it has to be voted if it's included in the main branch or something?
Topic: Why class attributes are not encapsulated? (Read 847 times)
In general there's an engineering tradeoff with encapsulation. If you encapsulate everything possible to the maximum extent, you end up with a bloated piece of software that's difficult to understand (simply because it's so much bigger).
On the other hand, failing to encapsulate certain things leads to software that's less malleable; harder to change without breaking things.
I think there's a lot to be said for adding encapsulation to those parts of the code that actually get worked on, and adding it at the time when the benefit becomes apparent (such as the example that you give).
So I suggest that you write two patches. The first patch, to encapsulate CTxOut::nValue, can be submitted to Bitcoin. The second patch will be for your own purposes, to implement demurrage or whatever it is you need to do.
On the other hand, failing to encapsulate certain things leads to software that's less malleable; harder to change without breaking things.
I think there's a lot to be said for adding encapsulation to those parts of the code that actually get worked on, and adding it at the time when the benefit becomes apparent (such as the example that you give).
So I suggest that you write two patches. The first patch, to encapsulate CTxOut::nValue, can be submitted to Bitcoin. The second patch will be for your own purposes, to implement demurrage or whatever it is you need to do.
Hi, I want to make a bitcoin fork with demurrage. If CTxOut::nValue where properly encapsulated (get/set), it would be much easier for me to add demurrrage and still have a code very similar to bitcoin's when technical changes are committed into the main repository.
[Kind of offtopic]
I mean, I don't see the point in developing technical improvements outside of the bitcoin project. If it is really an improvement, why not testing it and introduce it in bitcoin. I think the closer freicoin's code is to bitcoin's, the better. Being free software, there's no point in competing through technical enhancements. I believe that if another chain is going to be greater than bitcoin the cause will be an economic property of the currency (like freicoin's demurrage) or an embebed service (like namecoin's DNS), but a purely technical advantage can be applied to bitcoin. That's why I don't like solidcoin, i0coin, etc. They can be nice experiments, but I won't trade them. Most of my earlier proposals (for exchange between chains or for escrow) can be implemented through scripts/contracts, so the services that can be embebed in a chain (and are not feasible in bitcoin) are more limited than I first thought.
[/Kind of offtopic]
Is there a reason why class attributes are not encapsulated?
Is there plans to change the code without changing its functionality so that it gets more readable and robust (follow software engineering standarts and these kind of things)?
[Kind of offtopic]
I mean, I don't see the point in developing technical improvements outside of the bitcoin project. If it is really an improvement, why not testing it and introduce it in bitcoin. I think the closer freicoin's code is to bitcoin's, the better. Being free software, there's no point in competing through technical enhancements. I believe that if another chain is going to be greater than bitcoin the cause will be an economic property of the currency (like freicoin's demurrage) or an embebed service (like namecoin's DNS), but a purely technical advantage can be applied to bitcoin. That's why I don't like solidcoin, i0coin, etc. They can be nice experiments, but I won't trade them. Most of my earlier proposals (for exchange between chains or for escrow) can be implemented through scripts/contracts, so the services that can be embebed in a chain (and are not feasible in bitcoin) are more limited than I first thought.
[/Kind of offtopic]
Is there a reason why class attributes are not encapsulated?
Is there plans to change the code without changing its functionality so that it gets more readable and robust (follow software engineering standarts and these kind of things)?
Jump to: