Bitcoin Forum
December 11, 2016, 08:12:15 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Why class attributes are not encapsulated?  (Read 651 times)
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 14, 2011, 09:32:26 AM
 #1

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)?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
1481443935
Hero Member
*
Offline Offline

Posts: 1481443935

View Profile Personal Message (Offline)

Ignore
1481443935
Reply with quote  #2

1481443935
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
September 14, 2011, 09:47:54 AM
 #2

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.
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
September 14, 2011, 10:34:01 AM
 #3

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?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!