struct or class?

[Mr Flibble]

Hi!

Use struct instead of class if you don't have a class invariant.

/Flibble

[Chris M. Thomasson]

On 11/27/2022 3:19 AM, Mr Flibble wrote:
> Hi!
>
> Use struct instead of class if you don't have a class invariant.
>

Have you ever used a class and made everything private, then slowly made
aspects of it public on an as needed basis?

[Chris M. Thomasson]

On 11/27/2022 3:19 AM, Mr Flibble wrote:

> Hi!
>
> Use struct instead of class if you don't have a class invariant.

probably want to use a struct for a POD as well.

[Bonita Montero]

Am 27.11.2022 um 12:19 schrieb Mr Flibble:

> Hi!
> Use struct instead of class if you don't have a class invariant.

I use both interchangeable and I use a struct when the first
member is public, a class when the first member is private.

[Paul N]

On Sunday, November 27, 2022 at 11:19:47 AM UTC, Mr Flibble wrote:
> Use struct instead of class if you don't have a class invariant.

How about an example? If an object is a spreadsheet cell, having among other things a (potential) formula and a resulting value, does it have a class invariant? Would it be best as a struct or a class?

[JiiPee]

ye by default private

[Mut...@dastardlyhq.com]

I do the opposite. Make everything public then set things private if they
absolutely must be. I don't understand why you'd take away the ability of
something to access as much of your class data as possible, its not your
house that needs to be protected against theft, its code providing a service.

[Mr Flibble]

You need to learn what "encapsulation" means; only have a minimum of
public methods: the more public methods a class has the less encapsulated
it is. Any member variables that form part of the class's invarient MUST
be private.

/Flibble

[Mr Flibble]

If the resultant value is the result of executing the formula then you
could argue that both together form an invariant.

/Flibble

[Vir Campestris]

On 28/11/2022 18:10, Mr Flibble wrote:
> You need to learn what "encapsulation" means; only have a minimum of
> public methods: the more public methods a class has the less encapsulated
> it is. Any member variables that form part of the class's invarient MUST
> be private.

After the other thread I'm gobsmacked. This is exactly the point.

Andy

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> I do the opposite. Make everything public then set things private if they
> absolutely must be. I don't understand why you'd take away the ability of
> something to access as much of your class data as possible, its not your
> house that needs to be protected against theft, its code providing a service.

Because the more you expose the private implementation of a class, the
harder it becomes to refactor without breaking existing code.

You might think: "Sure, perhaps refactoring the implementation of this
class might cause me to have to change the five million places where
the class is being used, but so what? The compiler will help me with
that. I'll just use five hours to fix every place and I'll be fine."

However, that approach doesn't work if you are making a library that's
used by several projects, even ones you aren't developing yourself.
If you break the API or usage of your class, ie. break backwards
compatibility, you may be causing a lot of work to other people who
are using your class.

Just as a very small and simple example of how a private implementation
is hidden from a public interface: Do you know how std::vector::size()
is implemented? There is, in fact, more than one way to implement it.
For example, the number of elements could be a member variable, or the
function could calculate it as the difference of two pointers.
Which one is it? You don't need nor have to know! The implementation
can choose whichever way it wants. And if it wants to change the
implementation it won't break any code.

(And if you think "that's a stupid example, nobody implements it
as the difference of two pointers", you'd be wrong.)

[JiiPee]

On 29/11/2022 09:27, Juha Nieminen wrote:
> Just as a very small and simple example of how a private implementation
> is hidden from a public interface: Do you know how std::vector::size()
> is implemented? There is, in fact, more than one way to implement it.
> For example, the number of elements could be a member variable, or the
> function could calculate it as the difference of two pointers.
> Which one is it? You don't need nor have to know! The implementation
> can choose whichever way it wants. And if it wants to change the
> implementation it won't break any code.

Ye good points. I have programmed long enough to know that this is real
benefit in a real code. I also think about this when I design a class:
easy to modify and change later. If it was:

int m_size;

it has many drawback: cant debug so easily, and cant easily change its
logic as you said.

[Mut...@dastardlyhq.com]

On Mon, 28 Nov 2022 18:10:24 +0000
Mr Flibble <fli...@reddwarf.jmc.corp> wrote:
>On Mon, 28 Nov 2022 16:11:18 +0000, Muttley wrote:
>
>> On Mon, 28 Nov 2022 18:07:25 +0200 JiiPee
>> <kerrttuPo...@gmail.com> wrote:
>>>On 28/11/2022 01:46, Chris M. Thomasson wrote:
>>>> On 11/27/2022 3:19 AM, Mr Flibble wrote:
>>>>> Hi!
>>>>>
>>>>> Use struct instead of class if you don't have a class invariant.
>>>>>
>>>>>
>>>> Have you ever used a class and made everything private, then slowly
>>>> made aspects of it public on an as needed basis?
>>>>
>>>>
>>>ye by default private
>>
>> I do the opposite. Make everything public then set things private if
>> they absolutely must be. I don't understand why you'd take away the
>> ability of something to access as much of your class data as possible,
>> its not your house that needs to be protected against theft, its code
>> providing a service.
>
>You need to learn what "encapsulation" means; only have a minimum of

I know what it means thanks.

>public methods: the more public methods a class has the less encapsulated
>it is. Any member variables that form part of the class's invarient MUST
>be private.

No they don't. Its simply personal choice. Code exists to perform functions and
the more access someone has to it the more power they have. You won't agree
with that, thats your choice.

[Mut...@dastardlyhq.com]

On Tue, 29 Nov 2022 07:27:09 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote:
>Mut...@dastardlyhq.com wrote:
>> I do the opposite. Make everything public then set things private if they
>> absolutely must be. I don't understand why you'd take away the ability of
>> something to access as much of your class data as possible, its not your
>> house that needs to be protected against theft, its code providing a service.
>
>
>Because the more you expose the private implementation of a class, the
>harder it becomes to refactor without breaking existing code.

Thats why you provide a "use at your own risk" clause.

>However, that approach doesn't work if you are making a library that's
>used by several projects, even ones you aren't developing yourself.
>If you break the API or usage of your class, ie. break backwards
>compatibility, you may be causing a lot of work to other people who
>are using your class.

You provide a public API but leave unofficial access with the proviso above.
Isn't it amazing how people managed before OO came along?

[Mr Flibble]

On Tue, 29 Nov 2022 16:34:27 +0000, Muttley wrote:

> On Mon, 28 Nov 2022 18:10:24 +0000 Mr Flibble
> <fli...@reddwarf.jmc.corp> wrote:
>>On Mon, 28 Nov 2022 16:11:18 +0000, Muttley wrote:
>>
>>> On Mon, 28 Nov 2022 18:07:25 +0200 JiiPee
>>> <kerrttuPo...@gmail.com> wrote:
>>>>On 28/11/2022 01:46, Chris M. Thomasson wrote:
>>>>> On 11/27/2022 3:19 AM, Mr Flibble wrote:
>>>>>> Hi!
>>>>>>
>>>>>> Use struct instead of class if you don't have a class invariant.
>>>>>>
>>>>>>
>>>>> Have you ever used a class and made everything private, then slowly
>>>>> made aspects of it public on an as needed basis?
>>>>>
>>>>>
>>>>ye by default private
>>>
>>> I do the opposite. Make everything public then set things private if
>>> they absolutely must be. I don't understand why you'd take away the
>>> ability of something to access as much of your class data as possible,
>>> its not your house that needs to be protected against theft, its code
>>> providing a service.
>>
>>You need to learn what "encapsulation" means; only have a minimum of
>
> I know what it means thanks.

It is obvious that you don't.

>
>>public methods: the more public methods a class has the less
>>encapsulated it is. Any member variables that form part of the class's
>>invarient MUST be private.
>
> No they don't. Its simply personal choice. Code exists to perform
> functions and the more access someone has to it the more power they
> have. You won't agree with that, thats your choice.

It is only a personal choice if you are a team of ONE. Do you even have a
day job? I would hate to work where you work if you do and they allow
such egregious behaviour.

/Flibble

[Mr Flibble]

On Tue, 29 Nov 2022 16:36:56 +0000, Muttley wrote:

> On Tue, 29 Nov 2022 07:27:09 -0000 (UTC)
> Juha Nieminen <nos...@thanks.invalid> wrote:
>>Mut...@dastardlyhq.com wrote:
>>> I do the opposite. Make everything public then set things private if
>>> they absolutely must be. I don't understand why you'd take away the
>>> ability of something to access as much of your class data as possible,
>>> its not your house that needs to be protected against theft, its code
>>> providing a service.
>>
>>
>>Because the more you expose the private implementation of a class, the
>>harder it becomes to refactor without breaking existing code.
>
> Thats why you provide a "use at your own risk" clause.

It isn't just your own risk, it is *everyone* who either uses or depends
on the code's risk.

>
>>However, that approach doesn't work if you are making a library that's
>>used by several projects, even ones you aren't developing yourself. If
>>you break the API or usage of your class, ie. break backwards
>>compatibility, you may be causing a lot of work to other people who are
>>using your class.
>
> You provide a public API but leave unofficial access with the proviso
> above.
> Isn't it amazing how people managed before OO came along?

"unofficial"? you must really crank out bags of shite on a daily basis.

/Flibble

[Öö Tiib]

On Tuesday, 29 November 2022 at 18:37:12 UTC+2, Mut...@dastardlyhq.com wrote:
>
> Isn't it amazing how people managed before OO came along?

In C they used pointers to opaque types for encapsulation. Kind of like that
FILE* of fopen(), fscanf(), fprintf() etc is used.

[Juha Nieminen]

Mut...@dastardlyhq.com wrote:
> Isn't it amazing how people managed before OO came along?

This sounds to me like a case of "why do we even need measles vaccines
anymore? There hasn't been a single case in decades."

The thing is, when it works, you don't even notice.

[Mut...@dastardlyhq.com]

On Tue, 29 Nov 2022 18:38:02 +0000

Mr Flibble <fli...@reddwarf.jmc.corp> wrote:
>On Tue, 29 Nov 2022 16:34:27 +0000, Muttley wrote:
>
>> On Mon, 28 Nov 2022 18:10:24 +0000 Mr Flibble
>> <fli...@reddwarf.jmc.corp> wrote:
>>>On Mon, 28 Nov 2022 16:11:18 +0000, Muttley wrote:
>>>
>>>> On Mon, 28 Nov 2022 18:07:25 +0200 JiiPee
>>>> <kerrttuPo...@gmail.com> wrote:
>>>>>On 28/11/2022 01:46, Chris M. Thomasson wrote:
>>>>>> On 11/27/2022 3:19 AM, Mr Flibble wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> Use struct instead of class if you don't have a class invariant.
>>>>>>>
>>>>>>>
>>>>>> Have you ever used a class and made everything private, then slowly
>>>>>> made aspects of it public on an as needed basis?
>>>>>>
>>>>>>
>>>>>ye by default private
>>>>
>>>> I do the opposite. Make everything public then set things private if
>>>> they absolutely must be. I don't understand why you'd take away the
>>>> ability of something to access as much of your class data as possible,
>>>> its not your house that needs to be protected against theft, its code
>>>> providing a service.
>>>
>>>You need to learn what "encapsulation" means; only have a minimum of
>>
>> I know what it means thanks.
>
>It is obvious that you don't.

Don't confuse understanding with not giving a toss.

>> No they don't. Its simply personal choice. Code exists to perform
>> functions and the more access someone has to it the more power they
>> have. You won't agree with that, thats your choice.
>
>It is only a personal choice if you are a team of ONE. Do you even have a
>day job? I would hate to work where you work if you do and they allow
>such egregious behaviour.

My day job doesn't involved C++ right now so thats irrelevant.

[Mut...@dastardlyhq.com]

On Tue, 29 Nov 2022 18:40:18 +0000
Mr Flibble <fli...@reddwarf.jmc.corp> wrote:
>On Tue, 29 Nov 2022 16:36:56 +0000, Muttley wrote:
>
>> On Tue, 29 Nov 2022 07:27:09 -0000 (UTC)
>> Juha Nieminen <nos...@thanks.invalid> wrote:
>>>Mut...@dastardlyhq.com wrote:
>>>> I do the opposite. Make everything public then set things private if
>>>> they absolutely must be. I don't understand why you'd take away the
>>>> ability of something to access as much of your class data as possible,
>>>> its not your house that needs to be protected against theft, its code
>>>> providing a service.
>>>
>>>
>>>Because the more you expose the private implementation of a class, the
>>>harder it becomes to refactor without breaking existing code.
>>
>> Thats why you provide a "use at your own risk" clause.
>
>It isn't just your own risk, it is *everyone* who either uses or depends
>on the code's risk.

How does that work then? Either the code works or it doesn't. Have you heard
of testing? Actually probably not, you probably think your code is perfect
and don't bother.

>> You provide a public API but leave unofficial access with the proviso
>> above.
>> Isn't it amazing how people managed before OO came along?
>
>"unofficial"? you must really crank out bags of shite on a daily basis.

Just like you on here you mean?

[Mut...@dastardlyhq.com]

But you can access their internals if you want to. You might never want to
but the option is there.

[Scott Lurndal]

For intentionally opaque objects like struct FILE, that would be an
egregiously bad thing to do. And for some impl., it is impossible because
the internals are one (implementation defined) object behind struct
FILE which simply contains a void* pointer to the real object