On Tuesday, 16 April 2013 at 21:14:16 UTC, Ali Çehreli wrote:
> On 04/16/2013 08:44 AM, Tofu Ninja wrote:
> When that happens, would you expect a and b also become handles to the new object? It could I guess, but it sounds impractical in a system language. The runtime does not maintain a record of what handles share the same object.


No, I wouldn't expect a to change. If I did b.replace() I would only expect b to be changed, a would still be pointing back at the original object.

On Tue, 16 Apr 2013 18:51:06 +0100, Tofu Ninja <emmons0@purdue.edu> wrote:

> On Tuesday, 16 April 2013 at 15:23:56 UTC, Regan Heath wrote:
>> I would question always question "fully intended" on a case by case basis:
>> http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
>>
>> I agree that grouping functions together that should be used together, or on the same type of object is a good idea from an organisational point of view but that shouldn't be the only reason for making them class member functions.
>>
>> R
>
> I think a lot of people give too much credit to encapsulation. I mean don't get me wrong its cool and all and it has its place, but it seems like some people make it seem a lot more important than it really is. I mean having lots of encapsulation really doesn't do anything for your program, it won't run faster or do more things. If any thing, more often than not, it makes things run slower, as you can't see what's in the black box.
>
> Thats just my opinion on the whole thing...

True, but this is what I'd call a short term view of encapsulation and code quality.

Thinking about encapsulation in the short term is important because it forces you to properly design things for the long term.  If you don't care at all about encapsulation (or orthogonality) you probably wont bother to actually define the interface between two potentially orthogonal pieces of code.

If there is no separation "designed in" to start with then code tends to tie itself together in sometimes surprising ways typically creating unintended dependencies or complexity.  Essentially the code becomes harder to reason about, harder to change and therefore harder to improve.

So, ultimately encapsulation (one aspect of good design) should lead to code which is better in every measurable way, including running faster.  Sure, there will be the odd case where encapsulation decreases performance, in those cases I would take the practical route of breaking encapsulation to solve the issue.  In short, encapsulation is important and useful but not paramount.

:)

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 17 Apr 2013 12:02:25 +0100, Regan Heath <regan@netmail.co.nz> wrote:
> So, ultimately encapsulation (one aspect of good design) should lead to code which is better in every measurable way, including running faster.

It may not have been 100% clear what I was implying here.  Because encapsulation makes the code easier to reason about, it makes it easier to change, and improve.  Therefore, it's easier to improve the performance of the code.

That, plus the idea that you can and should break encapsulation for a higher priority concern - which may be performance for example - mean that encapsulation should not negatively impact any code base.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wednesday, 17 April 2013 at 11:02:24 UTC, Regan Heath wrote:
> True, but this is what I'd call a short term view of encapsulation and code quality.
>
> Thinking about encapsulation in the short term is important because it forces you to properly design things for the long term.  If you don't care at all about encapsulation (or orthogonality) you probably wont bother to actually define the interface between two potentially orthogonal pieces of code.
>
> If there is no separation "designed in" to start with then code tends to tie itself together in sometimes surprising ways typically creating unintended dependencies or complexity.  Essentially the code becomes harder to reason about, harder to change and therefore harder to improve.
>
> So, ultimately encapsulation (one aspect of good design) should lead to code which is better in every measurable way, including running faster.  Sure, there will be the odd case where encapsulation decreases performance, in those cases I would take the practical route of breaking encapsulation to solve the issue.  In short, encapsulation is important and useful but not paramount.
>
> :)
>
> R

You misunderstand me, I think encapsulation is great and important, but just not as great and important as a lot of people seem to think. I agree that encapsulation has a lot of good qualities, but i also think it would be a little naive to say that it doesn't have some bad qualities as well. All i am going to say... really doesn't have much to do with the thread.

On Wed, 17 Apr 2013 12:17:03 +0100, Tofu Ninja <emmons0@purdue.edu> wrote:

> On Wednesday, 17 April 2013 at 11:02:24 UTC, Regan Heath wrote:
>> True, but this is what I'd call a short term view of encapsulation and code quality.
>>
>> Thinking about encapsulation in the short term is important because it forces you to properly design things for the long term.  If you don't care at all about encapsulation (or orthogonality) you probably wont bother to actually define the interface between two potentially orthogonal pieces of code.
>>
>> If there is no separation "designed in" to start with then code tends to tie itself together in sometimes surprising ways typically creating unintended dependencies or complexity.  Essentially the code becomes harder to reason about, harder to change and therefore harder to improve.
>>
>> So, ultimately encapsulation (one aspect of good design) should lead to code which is better in every measurable way, including running faster.  Sure, there will be the odd case where encapsulation decreases performance, in those cases I would take the practical route of breaking encapsulation to solve the issue.  In short, encapsulation is important and useful but not paramount.
>>
>> :)
>>
>> R
>
> You misunderstand me, I think encapsulation is great and important, but just not as great and important as a lot of people seem to think.

No, I got all that :)

My point was that it can in fact make your program run faster, indirectly. :P

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/