Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121103 > unrolled thread

What is OOP?

Back to article view | Back to comp.lang.c++

Contents

  What is OOP? wij <wyniijj5@gmail.com> - 2024-12-02 01:17 +0800
    Re: What is OOP? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-01 10:43 -0800
      Re: What is OOP? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-01 10:49 -0800
    Re: What is OOP? Lynn McGuire <lynnmcguire5@gmail.com> - 2024-12-01 15:07 -0600
      Re: What is OOP? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-01 13:36 -0800
      Re: What is OOP? Bonita Montero <Bonita.Montero@gmail.com> - 2024-12-02 08:45 +0100
    Re: What is OOP? Michael S <already5chosen@yahoo.com> - 2024-12-01 23:43 +0200
      Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-02 09:02 +0800
    Re: What is OOP? Richard Damon <richard@damon-family.org> - 2024-12-01 17:02 -0500
      Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-02 08:57 +0800
        Re: What is OOP? Richard Damon <richard@damon-family.org> - 2024-12-02 08:42 -0500
        Re: What is OOP? Isaac Ganoung <inventor500@vivaldi.net> - 2024-12-08 17:56 +0000
          Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-09 08:28 +0800
            Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-09 09:27 +0800
    Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-01 20:11 -0800
      Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-02 16:27 +0800
        Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-03 20:43 +0800
    Re: What is OOP? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-01 20:34 -0800
      Re: What is OOP? Michael S <already5chosen@yahoo.com> - 2024-12-02 10:47 +0200
        Re: What is OOP? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-15 04:24 -0800
          Re: What is OOP? Michael S <already5chosen@yahoo.com> - 2024-12-15 16:33 +0200
            Re: What is OOP? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-16 23:59 -0800
      Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-02 16:49 +0800
        Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-02 14:59 -0800
          Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-03 18:10 +0800
          Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-03 18:38 +0800
            Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-03 12:16 -0800
              Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-04 08:44 +0800
                Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-06 18:16 -0800
                  Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-08 01:01 +0800
                    Re: What is OOP? Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-07 10:46 -0800
                Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-19 21:15 -0800
                  Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-19 21:16 -0800
                    Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-19 21:17 -0800
                      Re: What is OOP? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-23 15:59 -0800
      Re: What is OOP? --- The most important aspect of OOP olcott <polcott333@gmail.com> - 2024-12-06 20:40 -0600
        Re: What is OOP? --- The most important aspect of OOP Richard Damon <richard@damon-family.org> - 2024-12-06 21:45 -0500
          Re: What is OOP? --- The most important aspect of OOP olcott <polcott333@gmail.com> - 2024-12-07 14:07 -0600
          Re: What is OOP? --- The most important aspect of OOP Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-09 09:51 -0800
            Re: What is OOP? --- The most important aspect of OOP Ross Finlayson <ross.a.finlayson@gmail.com> - 2024-12-09 17:43 -0800
          Re: What is OOP? --- The most important aspect of OOP Mr Flibble <leigh@i42.co.uk> - 2025-03-01 21:10 +0000
        Re: What is OOP? --- The most important aspect of OOP wij <wyniijj5@gmail.com> - 2024-12-08 00:32 +0800
    Re: What is OOP? Rosario19 <Ros@invalid.invalid> - 2024-12-04 13:14 +0100
      Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-04 22:31 +0800
      Re: What is OOP? wij <wyniijj5@gmail.com> - 2024-12-19 10:32 +0800
      Re: What is OOP? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-17 10:17 -0700
        Re: What is OOP? wij <wyniijj5@gmail.com> - 2025-03-19 04:58 +0800
          Re: What is OOP? wij <wyniijj5@gmail.com> - 2025-03-20 23:04 +0800
        Re: What is OOP? Michael S <already5chosen@yahoo.com> - 2025-03-20 17:37 +0200
          Re: What is OOP? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-29 13:33 -0700
        Re: What is OOP? Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-27 18:23 +0000
          Re: What is OOP? wij <wyniijj5@gmail.com> - 2025-03-29 11:12 +0800
            Re: What is OOP? Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-29 05:07 +0000
            Re: What is OOP? Michael S <already5chosen@yahoo.com> - 2025-03-29 20:39 +0300
              Re: What is OOP? Mr Flibble <flibble@reddwarf.jmc.corp> - 2025-03-29 19:03 +0000
          Re: What is OOP? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-29 13:36 -0700
    Re: What is OOP? wij <wyniijj5@gmail.com> - 2025-09-28 16:02 +0800

Page 1 of 3  [1] 2 3  Next page →

#121103 — What is OOP?

There are several understandings:
https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming

...
OO can have many meaning. I took OO to mean object, the basic entity of the
programming model and the operation of the object. The concept, as foundmental,
has to be solid, practical and easily usable. Otherwise, more codes and efforts
will be needed latter to fix it, making the original goal ,practically, a lie.
IOW, (nearly) a flawless model is all the basics. ...
https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download

From my view, programming language has to provide a model, so that programmers 
know what they are dealing with, to solve the problem (recent C++ seems solving
just syntax problems).
In (my) OOP, 'portability' (or reusable) is first achieved by making the 
probramming object compatible (form platform to platfrom or from time to time
in the same platform, but libwy only considers linux, but the idea should be
generally applicable), i.e. like pod types, structures, union may not be portable.

Programming object or 'concept' are 'better' represented/wrapped by class (keyword)
All should be simple, I don't know how to make the idea of 'object' more simpler.
See the guidelines.

OTOH, in C/C++, every memory objects/function has address, the language cannot
pretend it is not actually dealing with a large array of raw 'bytes' and its
restrictions (and restrict by Turing Machine). I think that is generally where 
many programming problems from. And, understanding C or assembly is nearly a must
before understanding C++, otherwise, no real meaning, simply put.

[toc] | [next] | [standalone]

#121104

On 12/01/2024 09:17 AM, wij wrote:
> There are several understandings:
> https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
>
> ...
> OO can have many meaning. I took OO to mean object, the basic entity of the
> programming model and the operation of the object. The concept, as foundmental,
> has to be solid, practical and easily usable. Otherwise, more codes and efforts
> will be needed latter to fix it, making the original goal ,practically, a lie.
> IOW, (nearly) a flawless model is all the basics. ...
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
>
>  From my view, programming language has to provide a model, so that programmers
> know what they are dealing with, to solve the problem (recent C++ seems solving
> just syntax problems).
> In (my) OOP, 'portability' (or reusable) is first achieved by making the
> probramming object compatible (form platform to platfrom or from time to time
> in the same platform, but libwy only considers linux, but the idea should be
> generally applicable), i.e. like pod types, structures, union may not be portable.
>
> Programming object or 'concept' are 'better' represented/wrapped by class (keyword)
> All should be simple, I don't know how to make the idea of 'object' more simpler.
> See the guidelines.
>
> OTOH, in C/C++, every memory objects/function has address, the language cannot
> pretend it is not actually dealing with a large array of raw 'bytes' and its
> restrictions (and restrict by Turing Machine). I think that is generally where
> many programming problems from. And, understanding C or assembly is nearly a must
> before understanding C++, otherwise, no real meaning, simply put.
>
>

An object is so abstract that it's sort of like that
it's just a thing.

Now, arrays and associative arrays, as after values
or value types, then with regards to union and layout,
start making for structured programming, then there's
types, about type and category theory, then about a
very usual description of has-a and is-a, and the
associated methods on objects, which are implemented
as static functions with always an implicit parameter
of the instance, vis-a-vis member functions and
statics and locals and thread-locals, according to
scope, then about namespacing, the names or structures
in structured programming, that "object-oriented
programming" is a great idea, with the above as rather
de facto bog-standard, then about mixins and friends
and otherwise about collaboration and interaction,
object models and models of object models.

Then, it's often that the routines as they may be,
where object-oriented usually also means procedural,
with regards to routines and functions and other
notions that differentiate digital-signal-processors
and event-based or functional programming, as they
may be, from "object-oriented programming as
class structs", make a "surface", that the API
as what's actually employed is sort of its
"contact surface", then with regards to ideas
in meta-programming like the "dynamic", with
regards to what usually otherwise is arrived
at the "static".


So, scope and statics has object-oriented programming
is just namespaces and names, according to conventions,
of the arguments what make parameters the calling conventions,
what most usually often describe the call stack or register
assignment the calling convention, resulting thinking
and writing code in the language of the objects,
not having to know anything about the runtime.


At some point in time after objects and inheritance,
for single inheritance, make perfect sense, then
there's multiple inheritance, and then there's mixins,
each at some point a great profound concept.

So, object-oriented programming is object-oriented programming,
then that "metaprogramming" is a usual idea of thinking about it.
And it's type theory and a process calculus together, then
getting into communicating-sequential-processes, what effect
making for what results eventually "system programming",
or "systems programming".

It's a surface concept of "structured programming".


There are quite a variety of models of computation,
then some things only mathematics can do.

[toc] | [prev] | [next] | [standalone]

#121105

On 12/01/2024 10:43 AM, Ross Finlayson wrote:
> On 12/01/2024 09:17 AM, wij wrote:
>> There are several understandings:
>> https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
>>
>>
>> ...
>> OO can have many meaning. I took OO to mean object, the basic entity
>> of the
>> programming model and the operation of the object. The concept, as
>> foundmental,
>> has to be solid, practical and easily usable. Otherwise, more codes
>> and efforts
>> will be needed latter to fix it, making the original goal
>> ,practically, a lie.
>> IOW, (nearly) a flawless model is all the basics. ...
>> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
>>
>>
>>  From my view, programming language has to provide a model, so that
>> programmers
>> know what they are dealing with, to solve the problem (recent C++
>> seems solving
>> just syntax problems).
>> In (my) OOP, 'portability' (or reusable) is first achieved by making the
>> probramming object compatible (form platform to platfrom or from time
>> to time
>> in the same platform, but libwy only considers linux, but the idea
>> should be
>> generally applicable), i.e. like pod types, structures, union may not
>> be portable.
>>
>> Programming object or 'concept' are 'better' represented/wrapped by
>> class (keyword)
>> All should be simple, I don't know how to make the idea of 'object'
>> more simpler.
>> See the guidelines.
>>
>> OTOH, in C/C++, every memory objects/function has address, the
>> language cannot
>> pretend it is not actually dealing with a large array of raw 'bytes'
>> and its
>> restrictions (and restrict by Turing Machine). I think that is
>> generally where
>> many programming problems from. And, understanding C or assembly is
>> nearly a must
>> before understanding C++, otherwise, no real meaning, simply put.
>>
>>
>
> An object is so abstract that it's sort of like that
> it's just a thing.
>
> Now, arrays and associative arrays, as after values
> or value types, then with regards to union and layout,
> start making for structured programming, then there's
> types, about type and category theory, then about a
> very usual description of has-a and is-a, and the
> associated methods on objects, which are implemented
> as static functions with always an implicit parameter
> of the instance, vis-a-vis member functions and
> statics and locals and thread-locals, according to
> scope, then about namespacing, the names or structures
> in structured programming, that "object-oriented
> programming" is a great idea, with the above as rather
> de facto bog-standard, then about mixins and friends
> and otherwise about collaboration and interaction,
> object models and models of object models.
>
> Then, it's often that the routines as they may be,
> where object-oriented usually also means procedural,
> with regards to routines and functions and other
> notions that differentiate digital-signal-processors
> and event-based or functional programming, as they
> may be, from "object-oriented programming as
> class structs", make a "surface", that the API
> as what's actually employed is sort of its
> "contact surface", then with regards to ideas
> in meta-programming like the "dynamic", with
> regards to what usually otherwise is arrived
> at the "static".
>
>
> So, scope and statics has object-oriented programming
> is just namespaces and names, according to conventions,
> of the arguments what make parameters the calling conventions,
> what most usually often describe the call stack or register
> assignment the calling convention, resulting thinking
> and writing code in the language of the objects,
> not having to know anything about the runtime.
>
>
> At some point in time after objects and inheritance,
> for single inheritance, make perfect sense, then
> there's multiple inheritance, and then there's mixins,
> each at some point a great profound concept.
>
> So, object-oriented programming is object-oriented programming,
> then that "metaprogramming" is a usual idea of thinking about it.
> And it's type theory and a process calculus together, then
> getting into communicating-sequential-processes, what effect
> making for what results eventually "system programming",
> or "systems programming".
>
> It's a surface concept of "structured programming".
>
>
> There are quite a variety of models of computation,
> then some things only mathematics can do.
>
>


(I don't "quora".)

[toc] | [prev] | [next] | [standalone]

#121106

On 12/1/2024 11:17 AM, wij wrote:
> There are several understandings:
> https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
> 
> ...
> OO can have many meaning. I took OO to mean object, the basic entity of the
> programming model and the operation of the object. The concept, as foundmental,
> has to be solid, practical and easily usable. Otherwise, more codes and efforts
> will be needed latter to fix it, making the original goal ,practically, a lie.
> IOW, (nearly) a flawless model is all the basics. ...
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> 
>  From my view, programming language has to provide a model, so that programmers
> know what they are dealing with, to solve the problem (recent C++ seems solving
> just syntax problems).
> In (my) OOP, 'portability' (or reusable) is first achieved by making the
> probramming object compatible (form platform to platfrom or from time to time
> in the same platform, but libwy only considers linux, but the idea should be
> generally applicable), i.e. like pod types, structures, union may not be portable.
> 
> Programming object or 'concept' are 'better' represented/wrapped by class (keyword)
> All should be simple, I don't know how to make the idea of 'object' more simpler.
> See the guidelines.
> 
> OTOH, in C/C++, every memory objects/function has address, the language cannot
> pretend it is not actually dealing with a large array of raw 'bytes' and its
> restrictions (and restrict by Turing Machine). I think that is generally where
> many programming problems from. And, understanding C or assembly is nearly a must
> before understanding C++, otherwise, no real meaning, simply put.

"Object-Oriented Analysis and Design with Applications 3rd Edition" by 
Grady Booch, etc
  
https://www.amazon.com/Object-Oriented-Analysis-Design-Applications-3rd/dp/020189551X/

Lynn

[toc] | [prev] | [next] | [standalone]

#121107

On 12/01/2024 01:07 PM, Lynn McGuire wrote:
> On 12/1/2024 11:17 AM, wij wrote:
>> There are several understandings:
>> https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
>>
>>
>> ...
>> OO can have many meaning. I took OO to mean object, the basic entity
>> of the
>> programming model and the operation of the object. The concept, as
>> foundmental,
>> has to be solid, practical and easily usable. Otherwise, more codes
>> and efforts
>> will be needed latter to fix it, making the original goal
>> ,practically, a lie.
>> IOW, (nearly) a flawless model is all the basics. ...
>> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
>>
>>
>>  From my view, programming language has to provide a model, so that
>> programmers
>> know what they are dealing with, to solve the problem (recent C++
>> seems solving
>> just syntax problems).
>> In (my) OOP, 'portability' (or reusable) is first achieved by making the
>> probramming object compatible (form platform to platfrom or from time
>> to time
>> in the same platform, but libwy only considers linux, but the idea
>> should be
>> generally applicable), i.e. like pod types, structures, union may not
>> be portable.
>>
>> Programming object or 'concept' are 'better' represented/wrapped by
>> class (keyword)
>> All should be simple, I don't know how to make the idea of 'object'
>> more simpler.
>> See the guidelines.
>>
>> OTOH, in C/C++, every memory objects/function has address, the
>> language cannot
>> pretend it is not actually dealing with a large array of raw 'bytes'
>> and its
>> restrictions (and restrict by Turing Machine). I think that is
>> generally where
>> many programming problems from. And, understanding C or assembly is
>> nearly a must
>> before understanding C++, otherwise, no real meaning, simply put.
>
> "Object-Oriented Analysis and Design with Applications 3rd Edition" by
> Grady Booch, etc
>
> https://www.amazon.com/Object-Oriented-Analysis-Design-Applications-3rd/dp/020189551X/
>
>
> Lynn
>

That nicely helps reflect on Booch-Rumbaugh, "Gang of Four",
after initiatives like CASE Computer Aided Software Engineering,
what was RAD Rapid Application Development, matters like
UML Unified Modeling Language and SysML a variety,
with regards to things like "Pattern Languages of
Program Design", PLoP as it were, of the divers kinds
of well-known "patterns", in OOA/OOD Object-Oriented Analysis
and Object Oriented Design, various patterns of integration
and abstraction, as with regards to type and category
and monadic programming and structured programming,
procedular and functional, these days for example
MBSE Model Based Software Engineering, which largely
intends to _derive_ software from schema, with regards
to exemplars in language like SmallTalk and Eiffel,
"object-oriented" and into "constraint-based programming",
after initiatives like BCPL and Algol, earlier initiatives
in structured programming, with regards to the great success
or ubiquity it may rather be like Java or C#/.Net/Mono after
the CLR and IL ASM layers, JavaScript and its ways that
implement classes after slots, for that something like
C++ has always been a rather premier object-oriented
target with regards to classes.

"Boxes and arrows", say.


The, "double diamond" or "dreaded diamond" of C++ with
regards to virtual and pure virtual functions, and then,
"inverting the tree" or "inverting the diamond", result
usually formalisms in type theory while as well category
theory has much to say, as with regards to the usual
expansion versus constriction, of subclasses, then as
with regards to usual mature schemas like XSD about
documents, having both expansion and constriction,
making for a usual idea that directed-acyclic-graphs
are much easier to reason than reference-resolution.

All usually "underneath the hood", in the metaphor
of the automobile, as with regards to "library designers"
and "library users", users.


The, "double diamond" is a usual marker on ski courses
as "un-ski-able". Yet, languages like C++ have carefully
proscribed the defined behavior of multiple concrete inheritance,
while other languages for example Java have "merely" signatures,
about duck-typing.

Here the GoF patterns mostly end at "singleton" and "factory",
pretty much with regards to scope, and "impl and pointer to impl",
while then much otherwise is "document schema".



https://en.wikipedia.org/wiki/Metadata_modeling


In the old days the CAD/CAM was a vector-screen
workstation with a keyboard and digitizer and
plotter, after learning how to draw in perspective,
back when #1 pencils were hard, these days there's
quite a bit involved in parts and assemblies.

Where everything is a flange or a jig, ....


If you like "object-oriented", maybe you'll like
"object-relational": it's totally ubiquitous.
So is pretty much "object-everything".

[toc] | [prev] | [next] | [standalone]

#121120

Am 01.12.2024 um 22:07 schrieb Lynn McGuire:

> "Object-Oriented Analysis and Design with Applications 3rd Edition" by 
> Grady Booch, etc
> 
> https://www.amazon.com/Object-Oriented-Analysis-Design-Applications-3rd/ 
> dp/020189551X/

https://annas-archive.org/md5/ae88fb6dd0f5e41ef64b902f03f7c8c4

[toc] | [prev] | [next] | [standalone]

#121108

On Mon, 02 Dec 2024 01:17:49 +0800
wij <wyniijj5@gmail.com> wrote:

> There are several understandings:
> https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
> 
> ...
> OO can have many meaning. I took OO to mean object, the basic entity
> of the programming model and the operation of the object. The
> concept, as foundmental, has to be solid, practical and easily
> usable. Otherwise, more codes and efforts will be needed latter to
> fix it, making the original goal ,practically, a lie. IOW, (nearly) a
> flawless model is all the basics. ...
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> 
> From my view, programming language has to provide a model, so that
> programmers know what they are dealing with, to solve the problem
> (recent C++ seems solving just syntax problems).
> In (my) OOP, 'portability' (or reusable) is first achieved by making
> the probramming object compatible (form platform to platfrom or from
> time to time in the same platform, but libwy only considers linux,
> but the idea should be generally applicable), i.e. like pod types,
> structures, union may not be portable.
> 
> Programming object or 'concept' are 'better' represented/wrapped by
> class (keyword) All should be simple, I don't know how to make the
> idea of 'object' more simpler. See the guidelines.
> 
> OTOH, in C/C++, every memory objects/function has address, the
> language cannot pretend it is not actually dealing with a large array
> of raw 'bytes' and its restrictions (and restrict by Turing Machine).
> I think that is generally where many programming problems from. And,
> understanding C or assembly is nearly a must before understanding
> C++, otherwise, no real meaning, simply put.
> 
> 

If you care about this sort of things it's a sure sign that you have
too much time and too little real (or non-real, but interesting) work to
do.

[toc] | [prev] | [next] | [standalone]

#121113

On Sun, 2024-12-01 at 23:43 +0200, Michael S wrote:
> On Mon, 02 Dec 2024 01:17:49 +0800
> wij <wyniijj5@gmail.com> wrote:
> 
> > There are several understandings:
> > https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
> > 
> > ...
> > OO can have many meaning. I took OO to mean object, the basic entity
> > of the programming model and the operation of the object. The
> > concept, as foundmental, has to be solid, practical and easily
> > usable. Otherwise, more codes and efforts will be needed latter to
> > fix it, making the original goal ,practically, a lie. IOW, (nearly) a
> > flawless model is all the basics. ...
> > https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> > 
> > From my view, programming language has to provide a model, so that
> > programmers know what they are dealing with, to solve the problem
> > (recent C++ seems solving just syntax problems).
> > In (my) OOP, 'portability' (or reusable) is first achieved by making
> > the probramming object compatible (form platform to platfrom or from
> > time to time in the same platform, but libwy only considers linux,
> > but the idea should be generally applicable), i.e. like pod types,
> > structures, union may not be portable.
> > 
> > Programming object or 'concept' are 'better' represented/wrapped by
> > class (keyword) All should be simple, I don't know how to make the
> > idea of 'object' more simpler. See the guidelines.
> > 
> > OTOH, in C/C++, every memory objects/function has address, the
> > language cannot pretend it is not actually dealing with a large array
> > of raw 'bytes' and its restrictions (and restrict by Turing Machine).
> > I think that is generally where many programming problems from. And,
> > understanding C or assembly is nearly a must before understanding
> > C++, otherwise, no real meaning, simply put.
> > 
> > 
> 
> If you care about this sort of things it's a sure sign that you have
> too much time and too little real (or non-real, but interesting) work to
> do.

Quite the opposite. I had to give up many real, interesting activities to talk.

[toc] | [prev] | [next] | [standalone]

#121109

On 12/1/24 12:17 PM, wij wrote:
> 
> OTOH, in C/C++, every memory objects/function has address, the language cannot
> pretend it is not actually dealing with a large array of raw 'bytes' and its
> restrictions (and restrict by Turing Machine). I think that is generally where
> many programming problems from. And, understanding C or assembly is nearly a must
> before understanding C++, otherwise, no real meaning, simply put.
> 

Except that by the rules of pointes in C (and C++) you can not convert a 
pointer to one object to a pointer to some other object that isn't 
within some defined larger object that the first object was also in.

While you can convert any pointer to some interger type, or into a char* 
pointer, there is nothing that gaurentes that these somehow correspond 
to "raw memory" address in some big raw memory array that you can go 
elsewhere with.

Yes, currently with most processors, it will just work, but nothing 
requires that to work, and in previous segmented architectures, it 
simply wasn't true.

[toc] | [prev] | [next] | [standalone]

#121112

On Sun, 2024-12-01 at 17:02 -0500, Richard Damon wrote:
> On 12/1/24 12:17 PM, wij wrote:
> > 
> > OTOH, in C/C++, every memory objects/function has address, the language cannot
> > pretend it is not actually dealing with a large array of raw 'bytes' and its
> > restrictions (and restrict by Turing Machine). I think that is generally where
> > many programming problems from. And, understanding C or assembly is nearly a must
> > before understanding C++, otherwise, no real meaning, simply put.
> > 
> 
> Except that by the rules of pointes in C (and C++) you can not convert a 
> pointer to one object to a pointer to some other object that isn't 
> within some defined larger object that the first object was also in.
> 
> While you can convert any pointer to some interger type, or into a char* 
> pointer, there is nothing that gaurentes that these somehow correspond 
> to "raw memory" address in some big raw memory array that you can go 
> elsewhere with.
> 
> Yes, currently with most processors, it will just work, but nothing 
> requires that to work, and in previous segmented architectures, it 
> simply wasn't true.

My point is that object is eventually a piece of consecutive 'raw' bytes in the
'big array'. We don't know how hardware might actully be, but C/C++ will make 
it like a big array (there might be gaps). Human recognition is makeup.  
Although we try hard to make the raw bytes recognizable, the dangerous thing is
pretending it is not or unaware what it is when programming in C/C++.
The easiest proof is using debugger. Sounds easy? but not, as it appears.

E.g. if the programer doesn't understand what the stack is (C++ pretty much
avoid talking about it), his/her C/C++ program would be suspicious because we 
don't know when 'Segmentation fault' would happen. How do you verify correctness
just by the program 'logic'?

[toc] | [prev] | [next] | [standalone]

#121124

On 12/1/24 7:57 PM, wij wrote:
> On Sun, 2024-12-01 at 17:02 -0500, Richard Damon wrote:
>> On 12/1/24 12:17 PM, wij wrote:
>>>
>>> OTOH, in C/C++, every memory objects/function has address, the language cannot
>>> pretend it is not actually dealing with a large array of raw 'bytes' and its
>>> restrictions (and restrict by Turing Machine). I think that is generally where
>>> many programming problems from. And, understanding C or assembly is nearly a must
>>> before understanding C++, otherwise, no real meaning, simply put.
>>>
>>
>> Except that by the rules of pointes in C (and C++) you can not convert a
>> pointer to one object to a pointer to some other object that isn't
>> within some defined larger object that the first object was also in.
>>
>> While you can convert any pointer to some interger type, or into a char*
>> pointer, there is nothing that gaurentes that these somehow correspond
>> to "raw memory" address in some big raw memory array that you can go
>> elsewhere with.
>>
>> Yes, currently with most processors, it will just work, but nothing
>> requires that to work, and in previous segmented architectures, it
>> simply wasn't true.
> 
> My point is that object is eventually a piece of consecutive 'raw' bytes in the
> 'big array'. We don't know how hardware might actully be, but C/C++ will make
> it like a big array (there might be gaps). Human recognition is makeup.
> Although we try hard to make the raw bytes recognizable, the dangerous thing is
> pretending it is not or unaware what it is when programming in C/C++.
> The easiest proof is using debugger. Sounds easy? but not, as it appears.
> 
> E.g. if the programer doesn't understand what the stack is (C++ pretty much
> avoid talking about it), his/her C/C++ program would be suspicious because we
> don't know when 'Segmentation fault' would happen. How do you verify correctness
> just by the program 'logic'?
> 

No, my point is that there need no be a "big array" that every object is 
part of. Yes, the most popular current architectures work that way, but 
there is no requirement in the language that it works that way.

Unless what you mean by a "big array of raw bytes" an array indexed by 
every possible representation of a pointer, many of which just looking 
at the value might abort your program with a fault, your concept is just 
incorrect.

[toc] | [prev] | [next] | [standalone]

#121164

[Multipart message — attachments visible in raw view] — view raw

On Mon, 02 Dec 2024 08:57:41 +0800, wij wrote:

> How do you verify correctness just by the program 'logic'?

You use a functional language like Haskell. You are probably looking for 
this: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

[toc] | [prev] | [next] | [standalone]

#121167

On Sun, 2024-12-08 at 17:56 +0000, Isaac Ganoung wrote:
> On Mon, 02 Dec 2024 08:57:41 +0800, wij wrote:
> 
> > How do you verify correctness just by the program 'logic'?
> 
> You use a functional language like Haskell. You are probably looking for 
> this: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence

I don't know what to look for, maybe this is from another olcott, knowing
nothing of what he quotes.
So far, I feel C++ is the best language to model general problems.

The following is in response to the example in the provided webpage (if the
problem is simple or from a selected set, there are generally various kind
of elegant solutions):

------------------------------------
#include <Wy.stdio.h>
#include <Sc/Search.h>

using namespace Wy;
using namespace Sc;
#include "Sc/TestRule.inc" // This file must be included after the above using...

const SubstiRule rule_fac0(fac(NatNum_0), NatNum_1); // fac(0) -> 1
const SubstiRule rule_fac1(fac(UVarN_n), UVarN_n*fac(UVarN_n-NatNum_1)); // fac(n) -> n*fac(n-1)

RuleSet rule;

// Make rule from "Sc/TestRule.inc" and add two rules
void make_rule() {
 Errno r;
 for(size_t ri=0; ri<sizeof(brule)/sizeof(brule[0]); ++ri) {
   if((r=rule.add_rule(brule[ri]))!=Ok) {
     WY_THROW(r);
   }
 }
 if((r=rule.add_rule(rule_fac0))!=Ok) {
   WY_THROW(r);
 }
 if((r=rule.add_rule(rule_fac1))!=Ok) {
   WY_THROW(r);
 }

 // dump the final rule
 cout << "-------- Rules ---------" << WY_ENDL;
 for(size_t i=0; i<rule.num_rules(); ++i) {
   cout << '(' << wrd(i) << ") "
        << wrd(rule.rule(i).match_pattern()) << " -> "
        << wrd(rule.rule(i).deduct_pattern()) << WY_ENDL;
 }
 cout << "-----------------" << WY_ENDL;
};

void t0() {
 Errno r;
 make_rule();
 Search sr0(rule);
 const DyExpr ini_expr=fac(NatNum_2);
 const DyExpr des_expr=NatNum_2;

 cout << "Compute: " << wrd(ini_expr) << " -> " << wrd(des_expr) << WY_ENDL;
 if((r=sr0.search(ini_expr,des_expr,10,Search::Mode::Shortest))!=Ok) {
   WY_THROW(r);
 }
 const Array<Step>& garr= sr0.gpath();
 if(garr.is_empty()) {
   cout << "goal is not found" WY_ENDL;
 } else {
   cout << garr.size() << " steps" WY_ENDL;
   for(size_t i=0; i<garr.size(); ++i) {
     cout << '(' << garr[i].rule_index() << ") " << wrd(garr[i].expr()) << WY_ENDL;
   }
 }
};

int main()
try {
 cout << "check " __FILE__ WY_ENDL;
 t0();
 cout << "OK" WY_ENDL;
 return 0;
}
catch(const Errno& e) {
 cerr << wrd(e) << WY_ENDL;
 return -1;
}
catch(...) {
 cerr << "main caught(...)" WY_ENDL;
 return -1;
};
-----------------------
[]$ g++ a_fac.cpp -lwy
[]$ ./a.out 

check a_fac.cpp
-------- Rules ---------
(0) (_a+_b) -> (_b+_a)
(1) (_a+(_b+_c)) -> ((_a+_b)+_c)
(2) ((_a+_b)+_c) -> (_a+(_b+_c))
(3) (_a+0) -> _a
(4) (_a-_b) -> (_a+(-_b))
(5) (_a+(-_b)) -> (_a-_b)
(6) (_a-_a) -> 0
(7) (-(_a+_b)) -> ((-_a)+(-_b))
(8) ((-_a)+(-_b)) -> (-(_a+_b))
(9) (-(-_a)) -> _a
(10) (-0) -> 0
(11) (_a*_b) -> (_b*_a)
(12) (_a*(_b*_c)) -> ((_a*_b)*_c)
(13) ((_a*_b)*_c) -> (_a*(_b*_c))
(14) (_a*(_b+_c)) -> ((_a*_b)+(_a*_c))
(15) ((_a*_b)+(_a*_c)) -> (_a*(_b+_c))
(16) (_a*1) -> _a
(17) (_a*0) -> 0
(18) (_a/_b) -> (_a*(1/_b))
(19) (_a*(1/_b)) -> (_a/_b)
(20) (_a/_a) -> 1
(21) (_a/0) -> $Und_D0
(22) (-(_a*_b)) -> ((-_a)*_b)
(23) ((-_a)*_b) -> (-(_a*_b))
(24) (_a*(-_b)) -> ((-_a)*_b)
(25) ((-_a)*_b) -> (_a*(-_b))
(26) ((-_a)*(-_b)) -> (_a*_b)
(27) (-(_a/_b)) -> ((-_a)/_b)
(28) ((-_a)/_b) -> (-(_a/_b))
(29) (_a/(-_b)) -> ((-_a)/_b)
(30) ((-_a)/_b) -> (_a/(-_b))
(31) ((-_a)/(-_b)) -> (_a/_b)
(32) (_a^0) -> 1
(33) (_a^1) -> _a
(34) (_a^_b) -> (_a*(_a^(_b-1)))
(35) ((_a*_b)^_c) -> ((_a^_c)*(_b^_c))
(36) (_a^(_b+_c)) -> ((_a^_b)*(_a^_c))
(37) (_a^(_b*_c)) -> ((_a^_b)^_c)
(38) (0^_a) -> $Und_B0
(39) (_a^(-_b)) -> (1/(_a^_b))
(40) (2-1) -> 1
(41) (_a*_a) -> (_a^2)
(42) (_a+_a) -> (2*_a)
(43) fac(0) -> 1
(44) fac(_n) -> (_n*fac((_n-1)))
-----------------
Compute: fac(2) -> 2
7 steps
(44) (2*fac((2-1)))
(40) (2*fac(1))
(44) (2*(1*fac((1-1))))
(6) (2*(1*fac(0)))
(43) (2*(1*1))
(16) (2*1)
(16) 2
OK

----------------
Common criticism of libwy is the many error check codes.
But I feel such codes are necessary in real programs, hiding
it is dishonest.

[toc] | [prev] | [next] | [standalone]

#121168

On Mon, 2024-12-09 at 08:28 +0800, wij wrote:
> On Sun, 2024-12-08 at 17:56 +0000, Isaac Ganoung wrote:
> > On Mon, 02 Dec 2024 08:57:41 +0800, wij wrote:
> > 
> > > How do you verify correctness just by the program 'logic'?
> > 
> > You use a functional language like Haskell. You are probably looking for 
> > this: https://en.wikipedia.org/wiki/Curry%E2%80%93Howard_correspondence
> 
> I don't know what to look for, maybe this is from another olcott, knowing
> nothing of what he quotes.
> So far, I feel C++ is the best language to model general problems.
> 
> The following is in response to the example in the provided webpage (if the
> problem is simple or from a selected set, there are generally various kind
> of elegant solutions):
> 
> ------------------------------------
> #include <Wy.stdio.h>
> #include <Sc/Search.h>
> 
> using namespace Wy;
> using namespace Sc;
> #include "Sc/TestRule.inc" // This file must be included after the above using...
> 
> const SubstiRule rule_fac0(fac(NatNum_0), NatNum_1); // fac(0) -> 1
> const SubstiRule rule_fac1(fac(UVarN_n), UVarN_n*fac(UVarN_n-NatNum_1)); // fac(n) -> n*fac(n-1)
> 
> RuleSet rule;
> 
> // Make rule from "Sc/TestRule.inc" and add two rules
> void make_rule() {
>  Errno r;
>  for(size_t ri=0; ri<sizeof(brule)/sizeof(brule[0]); ++ri) {
>    if((r=rule.add_rule(brule[ri]))!=Ok) {
>      WY_THROW(r);
>    }
>  }
>  if((r=rule.add_rule(rule_fac0))!=Ok) {
>    WY_THROW(r);
>  }
>  if((r=rule.add_rule(rule_fac1))!=Ok) {
>    WY_THROW(r);
>  }
> 
>  // dump the final rule
>  cout << "-------- Rules ---------" << WY_ENDL;
>  for(size_t i=0; i<rule.num_rules(); ++i) {
>    cout << '(' << wrd(i) << ") "
>         << wrd(rule.rule(i).match_pattern()) << " -> "
>         << wrd(rule.rule(i).deduct_pattern()) << WY_ENDL;
>  }
>  cout << "-----------------" << WY_ENDL;
> };
> 
> void t0() {
>  Errno r;
>  make_rule();
>  Search sr0(rule);
>  const DyExpr ini_expr=fac(NatNum_2);
>  const DyExpr des_expr=NatNum_2;
> 
>  cout << "Compute: " << wrd(ini_expr) << " -> " << wrd(des_expr) << WY_ENDL;
>  if((r=sr0.search(ini_expr,des_expr,10,Search::Mode::Shortest))!=Ok) {
>    WY_THROW(r);
>  }
>  const Array<Step>& garr= sr0.gpath();
>  if(garr.is_empty()) {
>    cout << "goal is not found" WY_ENDL;
>  } else {
>    cout << garr.size() << " steps" WY_ENDL;
>    for(size_t i=0; i<garr.size(); ++i) {
>      cout << '(' << garr[i].rule_index() << ") " << wrd(garr[i].expr()) << WY_ENDL;
>    }
>  }
> };
> 
> int main()
> try {
>  cout << "check " __FILE__ WY_ENDL;
>  t0();
>  cout << "OK" WY_ENDL;
>  return 0;
> }
> catch(const Errno& e) {
>  cerr << wrd(e) << WY_ENDL;
>  return -1;
> }
> catch(...) {
>  cerr << "main caught(...)" WY_ENDL;
>  return -1;
> };
> -----------------------
> []$ g++ a_fac.cpp -lwy
> []$ ./a.out 
> 
> check a_fac.cpp
> -------- Rules ---------
> (0) (_a+_b) -> (_b+_a)
> (1) (_a+(_b+_c)) -> ((_a+_b)+_c)
> (2) ((_a+_b)+_c) -> (_a+(_b+_c))
> (3) (_a+0) -> _a
> (4) (_a-_b) -> (_a+(-_b))
> (5) (_a+(-_b)) -> (_a-_b)
> (6) (_a-_a) -> 0
> (7) (-(_a+_b)) -> ((-_a)+(-_b))
> (8) ((-_a)+(-_b)) -> (-(_a+_b))
> (9) (-(-_a)) -> _a
> (10) (-0) -> 0
> (11) (_a*_b) -> (_b*_a)
> (12) (_a*(_b*_c)) -> ((_a*_b)*_c)
> (13) ((_a*_b)*_c) -> (_a*(_b*_c))
> (14) (_a*(_b+_c)) -> ((_a*_b)+(_a*_c))
> (15) ((_a*_b)+(_a*_c)) -> (_a*(_b+_c))
> (16) (_a*1) -> _a
> (17) (_a*0) -> 0
> (18) (_a/_b) -> (_a*(1/_b))
> (19) (_a*(1/_b)) -> (_a/_b)
> (20) (_a/_a) -> 1
> (21) (_a/0) -> $Und_D0
> (22) (-(_a*_b)) -> ((-_a)*_b)
> (23) ((-_a)*_b) -> (-(_a*_b))
> (24) (_a*(-_b)) -> ((-_a)*_b)
> (25) ((-_a)*_b) -> (_a*(-_b))
> (26) ((-_a)*(-_b)) -> (_a*_b)
> (27) (-(_a/_b)) -> ((-_a)/_b)
> (28) ((-_a)/_b) -> (-(_a/_b))
> (29) (_a/(-_b)) -> ((-_a)/_b)
> (30) ((-_a)/_b) -> (_a/(-_b))
> (31) ((-_a)/(-_b)) -> (_a/_b)
> (32) (_a^0) -> 1
> (33) (_a^1) -> _a
> (34) (_a^_b) -> (_a*(_a^(_b-1)))
> (35) ((_a*_b)^_c) -> ((_a^_c)*(_b^_c))
> (36) (_a^(_b+_c)) -> ((_a^_b)*(_a^_c))
> (37) (_a^(_b*_c)) -> ((_a^_b)^_c)
> (38) (0^_a) -> $Und_B0
> (39) (_a^(-_b)) -> (1/(_a^_b))
> (40) (2-1) -> 1
> (41) (_a*_a) -> (_a^2)
> (42) (_a+_a) -> (2*_a)
> (43) fac(0) -> 1
> (44) fac(_n) -> (_n*fac((_n-1)))
> -----------------
> Compute: fac(2) -> 2
> 7 steps
> (44) (2*fac((2-1)))
> (40) (2*fac(1))
> (44) (2*(1*fac((1-1))))
> (6) (2*(1*fac(0)))
> (43) (2*(1*1))
> (16) (2*1)
> (16) 2
> OK
> 
> ----------------
> Common criticism of libwy is the many error check codes.
> But I feel such codes are necessary in real programs, hiding
> it is dishonest.

Have you found that rule [40] is strange? From there, already, stories can be
told about math. and logic (and C++, but more abstract).

Note: I did not comment Haskell, sine I know nealy nothing of it and wish to
      understand what is really there.

[toc] | [prev] | [next] | [standalone]

#121115

On 12/1/2024 9:17 AM, wij wrote:
> There are several understandings:
> https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
> 
> ...
> OO can have many meaning. I took OO to mean object, the basic entity of the
> programming model and the operation of the object. The concept, as foundmental,
> has to be solid, practical and easily usable. Otherwise, more codes and efforts
> will be needed latter to fix it, making the original goal ,practically, a lie.
> IOW, (nearly) a flawless model is all the basics. ...
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
[...]

struct object
{
     // [...]

     void do_it();
     void wink();
     void laugh();
     void pose();
};


? OOP right there in a sense?

[toc] | [prev] | [next] | [standalone]

#121121

On Sun, 2024-12-01 at 20:11 -0800, Chris M. Thomasson wrote:
> On 12/1/2024 9:17 AM, wij wrote:
> > There are several understandings:
> > https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
> > 
> > ...
> > OO can have many meaning. I took OO to mean object, the basic entity of the
> > programming model and the operation of the object. The concept, as foundmental,
> > has to be solid, practical and easily usable. Otherwise, more codes and efforts
> > will be needed latter to fix it, making the original goal ,practically, a lie.
> > IOW, (nearly) a flawless model is all the basics. ...
> > https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> [...]
> 
> struct object
> {
>      // [...]
> 
>      void do_it();
>      void wink();
>      void laugh();
>      void pose();
> };
> 
> 
> ? OOP right there in a sense?

NOPE.

Snippet from the classguidelines of libwy:
...
 Const member functions:
   A set of const function members, often referred to as property or attribute
   members, defines whether or not two objects function 'identically'. In
   general, a minimum set of such members must exist. These members are often
   in complexity O(1), and provide the basic proofs that the class is properly
   designed.
...

If there is no attribute members (const function member), how do we know whether
the class is properly designed or not? So, bascially, as long as default ctor
exists, there is a member 'bool is_default() const' to confirm it. The 2nd
question is how do we know whether the copy constructor does its job? Then,
there is a series of setters and getters... basically, verifiable by each other.
If you can make the function of these sets of members concise, efficient and
consistent, the concept of the class in your brain is probably right, otherwise
not right. This is the key point of libwy's OOP.

With your example (lacks ctors, but important), what is 'do_it()' and
others? You need some attribute members (getters) to confirm what those
non-const members do are exactly what they claim doing. So you also need other
attributes e.g. is_wink(), is_laugh() and is_pose(). Then, what the copy ctor
should do is clear. Then, assignment operator...,etc.
Whenever you have an idea, concept, try make it a 'complete' class (sometimes 
the idea does not fit as a class). Follow the basic rule, then, class design,
the program, will be lots easier and fun.

[toc] | [prev] | [next] | [standalone]

#121136

On Mon, 2024-12-02 at 16:27 +0800, wij wrote:
> On Sun, 2024-12-01 at 20:11 -0800, Chris M. Thomasson wrote:
> > On 12/1/2024 9:17 AM, wij wrote:
> > > There are several understandings:
> > > https://www.quora.com/As-an-experienced-OOP-programmer-in-your-opinion-whats-the-biggest-problem-of-OOP-object-oriented-programming
> > > 
> > > ...
> > > OO can have many meaning. I took OO to mean object, the basic entity of the
> > > programming model and the operation of the object. The concept, as foundmental,
> > > has to be solid, practical and easily usable. Otherwise, more codes and efforts
> > > will be needed latter to fix it, making the original goal ,practically, a lie.
> > > IOW, (nearly) a flawless model is all the basics. ...
> > > https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> > [...]
> > 
> > struct object
> > {
> >      // [...]
> > 
> >      void do_it();
> >      void wink();
> >      void laugh();
> >      void pose();
> > };
> > 
> > 
> > ? OOP right there in a sense?
> 
> NOPE.
> 
> Snippet from the classguidelines of libwy:
> ...
>  Const member functions:
>    A set of const function members, often referred to as property or attribute
>    members, defines whether or not two objects function 'identically'. In
>    general, a minimum set of such members must exist. These members are often
>    in complexity O(1), and provide the basic proofs that the class is properly
>    designed.
> ...
> 
> If there is no attribute members (const function member), how do we know whether
> the class is properly designed or not? So, bascially, as long as default ctor
> exists, there is a member 'bool is_default() const' to confirm it. The 2nd
> question is how do we know whether the copy constructor does its job? Then,
> there is a series of setters and getters... basically, verifiable by each other.
> If you can make the function of these sets of members concise, efficient and
> consistent, the concept of the class in your brain is probably right, otherwise
> not right. This is the key point of libwy's OOP.
> 
> With your example (lacks ctors, but important), what is 'do_it()' and
> others? You need some attribute members (getters) to confirm what those
> non-const members do are exactly what they claim doing. So you also need other
> attributes e.g. is_wink(), is_laugh() and is_pose(). Then, what the copy ctor
> should do is clear. Then, assignment operator...,etc.
> Whenever you have an idea, concept, try make it a 'complete' class (sometimes 
> the idea does not fit as a class). Follow the basic rule, then, class design,
> the program, will be lots easier and fun.

Snippet from the classguidelines of libwy:
...
Not all encapsulated is OOP.
OOP with class is about the complete set of concise and efficient class functionmembers. The point is
about correctness, not only of the codes but more
importantly, of the concept and idea of the class. The idea is not right,
hardly can the class be. If this complete set of class function members is not
doable for no good reasons, such an idea of the class should be abandoned. OOP
in class is not form only, but also semantics...

Not all encapsulated is OOP.

[toc] | [prev] | [next] | [standalone]

#121117

wij <wyniijj5@gmail.com> writes:

In response to the question of the subject line...

Just because a program is being written in a language that has
functions doesn't mean that what is being done is functional
programming.

Just because a program is being written in a language that has
classes and objects doesn't mean that what is being done is
object-oriented programming.

More than anything else object-oriented programming is a mindset
or a programming methodology.  It helps if the language being
used supports classes, etc, but the methodology can be used even
in languages that don't have them.

A quote:

    My guess is that object-oriented programming will be in the
    1980s what structured programming was in the 1970s.
    Everyone will be in favor of it.  Every manufacturer will
    promote his products as supporting it.  Every manager will
    pay lip service to it.  Every programmer will practice it
    (differently).  And no one will know just what it is.

That paragraph is taken from a paper written more than 40 years
ago.  The prediction came true with a vengeance, even more than
the author expected.  Most of what has been written about object
oriented programming was done by people who didn't understand it.

Two more quotes, these from Alan Kay:

    I invented the term "Object Oriented Programming," and C++
    is not what I had in mind.

    Though Smalltalk's structure allows the technique now known
    as data abstraction to be easily (and more generally)
    employed, the entire thrust of its design has been to
    supersede the concept of data and procedures entirely;  to
    replace these with the more generally useful notions of
    activity, communication, and inheritance.

[toc] | [prev] | [next] | [standalone]

#121122

On Sun, 01 Dec 2024 20:34:34 -0800
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> wij <wyniijj5@gmail.com> writes:
> 
> In response to the question of the subject line...
> 
> Just because a program is being written in a language that has
> functions doesn't mean that what is being done is functional
> programming.
> 
> Just because a program is being written in a language that has
> classes and objects doesn't mean that what is being done is
> object-oriented programming.
> 
> More than anything else object-oriented programming is a mindset
> or a programming methodology.  It helps if the language being
> used supports classes, etc, but the methodology can be used even
> in languages that don't have them.
> 
> A quote:
> 
>     My guess is that object-oriented programming will be in the
>     1980s what structured programming was in the 1970s.
>     Everyone will be in favor of it.  Every manufacturer will
>     promote his products as supporting it.  Every manager will
>     pay lip service to it.  Every programmer will practice it
>     (differently).  And no one will know just what it is.
> 
> That paragraph is taken from a paper written more than 40 years
> ago.

Finding the author of the quote is left as an exercise to the reader :-)

> The prediction came true with a vengeance, even more than
> the author expected.  Most of what has been written about object
> oriented programming was done by people who didn't understand it.
> 
> Two more quotes, these from Alan Kay:
> 
>     I invented the term "Object Oriented Programming," and C++
>     is not what I had in mind.
> 
>     Though Smalltalk's structure allows the technique now known
>     as data abstraction to be easily (and more generally)
>     employed, the entire thrust of its design has been to
>     supersede the concept of data and procedures entirely;  to
>     replace these with the more generally useful notions of
>     activity, communication, and inheritance.

In the finishing part of the second quate Alan Key is wrong. 
"Notions of activity, communication and inheritance" are less rather
than more generally useful than algorithms (procedures) and their
accompanying data structures. But that does not answer original
question, so O.T.

[toc] | [prev] | [next] | [standalone]

#121207

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 01 Dec 2024 20:34:34 -0800
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> wij <wyniijj5@gmail.com> writes:
>>
>> In response to the question of the subject line...
>>
>> Just because a program is being written in a language that has
>> functions doesn't mean that what is being done is functional
>> programming.
>>
>> Just because a program is being written in a language that has
>> classes and objects doesn't mean that what is being done is
>> object-oriented programming.
>>
>> More than anything else object-oriented programming is a mindset
>> or a programming methodology.  It helps if the language being
>> used supports classes, etc, but the methodology can be used even
>> in languages that don't have them.
>>
>> A quote:
>>
>>     My guess is that object-oriented programming will be in the
>>     1980s what structured programming was in the 1970s.
>>     Everyone will be in favor of it.  Every manufacturer will
>>     promote his products as supporting it.  Every manager will
>>     pay lip service to it.  Every programmer will practice it
>>     (differently).  And no one will know just what it is.
>>
>> That paragraph is taken from a paper written more than 40 years
>> ago.
>
> Finding the author of the quote is left as an exercise to the
> reader :-)

The paper was widely cited, and many of the papers that cited
it quoted that paragraph.  It's disappointing that many of
those who quoted the paragraph didn't understand what the
paper was getting at.

>> The prediction came true with a vengeance, even more than
>> the author expected.  Most of what has been written about object
>> oriented programming was done by people who didn't understand it.
>>
>> Two more quotes, these from Alan Kay:
>>
>>     I invented the term "Object Oriented Programming," and C++
>>     is not what I had in mind.
>>
>>     Though Smalltalk's structure allows the technique now known
>>     as data abstraction to be easily (and more generally)
>>     employed, the entire thrust of its design has been to
>>     supersede the concept of data and procedures entirely;  to
>>     replace these with the more generally useful notions of
>>     activity, communication, and inheritance.
>
> In the finishing part of the second quate Alan Key is wrong.
> "Notions of activity, communication and inheritance" are less
> rather than more generally useful than algorithms (procedures)
> and their accompanying data structures.

I think the view being expressed is that "Notions of activity,
communication and inheritance" are more useful in large-scale
systems.  It is not that the concepts of data and procedures
are not useful at all, but that they don't scale up well.  Alan
Kay said this: there is not much difference between 10 lines of
Smalltalk and 10 lines of Pascal; but 20 pages of Smalltalk is
more like 50 pages of Pascal (approximate quote, taken from a
memory nearly 50 years old).

> But that does not answer original question, so O.T.

His comment about activity and so forth is very much relevant to
his view of what "object-oriented programming" means (to the
extent that I understand what he has said and was trying to say
in that comment).

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web