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 3 of 3 — ← Prev page 1 2 [3]

#121747 — Re: What is OOP? --- The most important aspect of OOP

On Fri, 6 Dec 2024 21:45:19 -0500, Richard Damon
<richard@damon-family.org> wrote:

>On 12/6/24 9:40 PM, olcott wrote:
>> On 12/1/2024 10:34 PM, Tim Rentsch 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.  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.
>> 
>> The most important aspect of OOP is the ability to decompose
>> a problem into independent component parts. This can eliminate
>> the side effects in the structured programming model that
>> result from global data.
>> 
>
>
>Excpet that normally OOP is fully based on the operation resulting in 
>"side effects" as they mutate the state of the object the methods are 
>part of.
>
>What this does is not ELIMINATE the side effects, but limits their 
>scope. A given object type will tend to keep its own state "private" and 
>interact only with other object via "public" interfaces, allowing us to 
>limit the scope we need to think of when looking at interactions.
>
>This makes it very different from the "functional" model, where we do 
>not allow for side-effects.

It is a myth that FP has no side-effects: I/O is side-effects.

/Flibble

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

#121156 — Re: What is OOP? --- The most important aspect of OOP

On Fri, 2024-12-06 at 20:40 -0600, olcott wrote:
> On 12/1/2024 10:34 PM, Tim Rentsch 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.  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.
> 
> The most important aspect of OOP is the ability to decompose
> a problem into independent component parts. This can eliminate
> the side effects in the structured programming model that
> result from global data.

Most of problems are solved by decomposing to smaller ones, describing
the problem in more and more detail, or in different view.

A problem begins with the description of the problem.
Description of the natural language is basically the pattern Noun+Verb [+Noun],
which corresponds to object's function member call.
So, OOP is simulating natural sentences, making it 'objectively' executable by
machine. An unambiguous, efficient and machine-executable description is 
derived by repeated improvement of try-error.
So, OOP is 'just' a way to make our notion itself of the problem clear.

No matter how the programming problem is given, we do not start out having
a clear description of the problem. OOP is a method helps us understanding the
problem. Not strictly can a top-down process yield the program.

I just took a look of https://en.cppreference.com/w/cpp/filesystem (I am not
familiar with 'standard' things). It looks to me that the class (objects) are
actually 'string' (of special format), they are actually dealing with string
problems. The idea of that library is not much different from common 
C-programming. All the complexity pose more problems and solves little, very 
inefficient.

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

#121145

On Mon, 02 Dec 2024 01:17:49 +0800, 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.

oop
what is oo programming?
1 definition
object=memory layout and all the label to access to it, even that
layout apply to the pc memory in the machine
oop= programming way use objects and functions and operations on
objects 
with this definition even C would be oop, int and all operation with
that would be one object

change definition
2 definition
a object is a memory layout that have a routine for inizialize that
memory (constructor) and one routine for end the object (distructor)
and the programmer can define all the functions and operations to it
and othe objects or types in language

oop is the programming of objects in definition 2

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

#121146

On Wed, 2024-12-04 at 13:14 +0100, Rosario19 wrote:
> On Mon, 02 Dec 2024 01:17:49 +0800, 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.
> 
> oop
> what is oo programming?
> 1 definition
> object=memory layout and all the label to access to it, even that
> layout apply to the pc memory in the machine
> oop= programming way use objects and functions and operations on
> objects 
> with this definition even C would be oop, int and all operation with
> that would be one object
> 
> change definition
> 2 definition
> a object is a memory layout that have a routine for inizialize that
> memory (constructor) and one routine for end the object (distructor)
> and the programmer can define all the functions and operations to it
> and othe objects or types in language
> 
> oop is the programming of objects in definition 2

That (the beginning of OOP) is RAII. But, not C++ programs are automatically RAII. 
You still need to make it RAII.

[Snippet] Object life cycle view
+----------------------------------------------------------+
| Creating objects to program:                             |
| Sequence of acquisition incident: Object life cycle view |
+----------------------------------------------------------+
 1. Name binding
    (there might be anonymous object)
 2. Size binding
    Information to allocate memory
 3. Address binding
    Object in this stage is called in random state.
 4. Semantics binding
    Object is in responsible state of the occupied space and contents.
    (external resource may be associated in the semantics)
 5. Reversal is the object destruct process

    Note: Class of objects that can be randomly overwritten is referred to as
          discardable in this library. Often, such object has no user defined
          destructor.
-----

More to continue:

----- Result of the life cycle view is the basic rule of class members

 Constructor(..):
   Constructor forms are in basic the Cartesian product view of problem domain
   in tupple. IOW, the class (concept) is defined by the arguments of ctor.
   Constructor brings an object in random state to responsible state.

 Destructor:
   The destructed object is no longer considered existing in the C++ language
   (ref. [12.4.14]). Since destructing an object the second time results to
   undefined behavior, destructor must make sure destructing it once is enough.
   In another word, destructor must succeed to the language. Object destruction
   actually magnifies the effect of common ignorance of the implicitly created
   rollback function (or a design).... The program execution from return/throw/
   exit.. to its caller(e.g. main, init..) shall succeed.

   Note: C++ language had enforced the semantics that 'destructor must succeed'.

 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.

 Reset(..) members:
   Reset member brings the object from responsible state back to random state
   and then does whatever the argument corresponding constructor does.
   Therefore, If a reset member exists then the argument(s) corresponding
   constructor also exists.

   Construct/destruct/reset are implemented as composite operations of object
   initialization process of the life cycle view (and the symmetrical reverse).
   Implementation can optimize the theoretical sequence.

   Since this library adopts an implicit rule that object has to be in a 'valid'
   state, the reset() postcondition is thus required to be default. Default
   state is among the easiest check points to ensure object constructed, in
   whatever valid state, can always be successfully destructed. Note that reset
   members normally exist but not necessary. For instance, if the class
   contains const or reference data members, then the reset would be difficult
   to implement.

 Move Constructor:
   The motivation of devising is from the need to avoid costly and unnecessary
   copy operations found in classes that contain allocated resources and the
   objects movement in a dynamic array. It has been practiced that such
   motivation basically just need a *move constructor*. This library uses
   "enum ByMove_t { ByMove }" as the signature denoting a move constructor (for
   the moment), which is defined to move the source referenced object to 'this'
   pointed address (source object is treated non-existent). The reason is that
   such an operation is conceptually elementary, thus, it can enable the
   definition of a no-throw swap function template (note: implementation needs
   a buffer type, e.g. type_store<T>, but this is a different issue).

   Many other libraries do not contain the move constructor. Bit-wise copy
   (memcpy) may mostly do the job, e.g. QString of Qt library, so far. Just
   make sure that destructor of the moved object won't be called.

   Note: C++11 introduced rv-reference and defined another name 'std::move',
   a constructor taking a rv-reference argument is therefore called a move
   constructor. This library decided to continue the development using this now
   standard-confusing move constructor. Simply because ByMove is relatively
   more elementary. Many reasons can eventually be translated to being light
   weight, which in a way means it can transform easier. Again, This library's
   guide "No room should be left for lower-level implement". Another reason is
   the ratio of gain vs. cost does not appear good for the author to use it,
   hopefully this library can survive.
----

Programs written in C++ does not automatically make it qualify as OOP.
OOP is still a developing idea/theory, we need to make it more clear.

-------- Class member rules
   Accessible members give the object semantics. But this guideline can only
   address the general cases.
   The general rule: Semantics of class members should be consistently about
   one thing suggested by the ctor(s) and verifiable except not possible.

   Let T denote a given class, the following member names and associated
   functionalities are defined.

   T()     Default constructor. The object thus construted is referred
           to as in default state and so the default object.

           Postcondition of throw: object does not exist.

           Note: If object can mean 'no real contents', the default object is
                 better thus designed to guarantee safe destruction.

   T(const T&) Construct *this to the state as the source object.
          Note that copy constructed object should be 'identical' to the source
          object, this is implied by the language.
   T(T&, ByMove_t) Move the source object to 'this' pointed address.
           This member is not really a constructor since nothing is created.
           In practice, move ctor only needed in malloc'd array and for
           implementing swap.
   T(const &TT) Conversion ctor converts concept implicitly. If sizeof(T)!=
           sizeof(TT) or the sentence "T is TT and TT is T" does not read right,
           declare 'explicit'.

   Errno reset(..)
           Reconstruct the object to the state as constructed by the arguments
           corresponding constructor.

           Ex: reset members should ideally function identical to the argument
               corresponding ctors as demonstrated in the following example:

               Errno T::reset(Type1 a, Type2 b) try {
                 T obj(a,b);
                 swap(*this,obj);
                 return Ok;
               }
               catch(const Errno& e) { // could be many such catch clauses.
                 return e;             // This is simplied for demo.
               };

           Note: This rule is important. Real practice may want do things
                 slightly different in some cases. But no, hidden and hard to
                 find bugs may exist (maybe the concept or interface of the
                 class design or naming should be reconsidered).
           Note: For reset() (no argument), postcondition of the object is
                 always default regardless of the Errno returned or stack was
                 unwinded.

   ~T      Destruct object

   bool is_default() const
           return true iff object is equivalent to the default constructed
           object (i.e a.is_default() <==> a==T(), if operator== is defined).

   bool operator==(const T& rhs) const
           This function returns true iff *this and rhs are not distinguishable
           by using any non-private member on the same condition unless
           otherwise explicitly specified.

           Note: Object equivalence does not include equivalence of meta info.
                 and address of its own.

   T& operator=(const T&)
           Reconstruct object to the state as the copy constructor constructed
           (same as reset(const T&) except the return type and throwing error).

   void swap(&T)
           Exchange object state of *this and the argument indicated object.

           Take 'a.swap(b)' (commutative) for instance, the state of a is set
           to the state of b. The previous state of a becomes the state of b.
           The same applies for b.

           Note: No construct and destruct semantics is involved

   Reply   Class specific throw class inheriting Errno to help identify the
           throwing source.

   _..     Prefix for specific-implemented members, different rule,...etc.

   c_..    Prefix for C stuff. Rule of this member may be different.

   wy_..   Prefix for internal members (for testing, etc.).
------

Back to the begin:
Not all encapsulated is OOP.
OOP with class is about the complete set of concise and efficient class function
members. 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.
-----

Real class has various restrictions, but you get the idea. If the class cannot
explain by the above criteria, it is flawed, not a good class/idea/concept.

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

#121260

On Wed, 2024-12-18 at 19:42 +0000, Stefan Ram wrote:
> Rosario19 <Ros@invalid.invalid> wrote or quoted:
> > what is oo programming?
> 
>   Alan Kay coined the term, and, in 2003, I asked him:
> 
> What does "object-oriented [programming]" mean to you?
> 
>   . He answered in an e-mail:
> 
> > OOP to me means only messaging, local retention and protection and 
> > hiding of state-process, and extreme late-binding of all things.
> 
>   . My personal interpretation (taking the above source and my
>   own observations into account):
> 
> An object is an imaginary building block that contains states
> and procedures and can only be accessed from the outside by
> sending messages. The object decides how it reacts (within the
> scope of its specification) to a specific message. (runtime
> model)
> 
> In object-oriented programming, programs describe under which
> conditions which messages are sent to object expressions at
> runtime: For this purpose, there is a dispatch specification
> that defines the recipient object expression and the message
> to be sent. This dispatch definition can also be regarded as
> an expression whose value is then determined by the recipient
> object (as a type of response). (source code model) 
> 
> It must be possible to determine which object receives a
> particular message (late binding) as late as possible (i.e. at
> runtime during the evaluation of the dispatch determination):
> For this purpose, the recipient object can be specified again
> in the dispatch determination itself by means of an expression
> that is only evaluated at runtime as late as possible (runtime
> polymorphism).
> 
>   Yes, I really think it is better to say that we send messages
>   to expressions because which object the expression represents
>   is only determined shortly beforehand and can be different
>   each time the same code is run several times.
> 
>   But there's something else of equal importance! It's the
>   insight by Uncle Bob (Robert C. Martin) about when procedural
>   code is better and when object-oriented code is better.
> 
> > Procedural code (code using data structures) makes it easy to
> > add new functions without changing the existing data
> > structures. OO code, on the other hand, makes it easy to add
> > new classes without changing existing functions.
> Robert C. Martin
> 
> > Procedural code makes it hard to add new data structures
> > because all the functions must change. OO code makes it hard
> > to add new functions because all the classes must change.
> Robert C. Martin

Objects can be saied as variables (int,char,struct...class)
Class can encapsulate almost everything. From my view, it is 
(basically) about the rule of class's members, as in 
ClassGuidelines.txt.

The 'visible' effect is the amout of names are siginificantly 
reduced, this means a lots.

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

#121994

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Rosario19 <Ros@invalid.invalid> wrote or quoted:
>
>> what is oo programming?
>
>   Alan Kay coined the term, and, in 2003, I asked him:
>
> What does "object-oriented [programming]" mean to you?
>
>   . He answered in an e-mail:
>
> |OOP to me means only messaging, local retention and protection and
> |hiding of state-process, and extreme late-binding of all things.
>
>   . My personal interpretation (taking the above source and my
>   own observations into account):

I appreciate your efforts in pursuing this and in describing what
you think it all means.  I'm glad to see a discussion about OOP
that goes beyond the common misunderstandings of what is meant.

I would like to respond to your comments with my own understanding
of how Alan views these areas.  I should explain that I have talked
with (and also listened to) Alan enough so that I think I have a
pretty good understanding of what his views are here, but the
comments below are just my impression of his thoughts.

> An object is an imaginary building block that contains states
> and procedures and can only be accessed from the outside by
> sending messages.  The object decides how it reacts (within the
> scope of its specification) to a specific message.  (runtime
> model)

An object is a blob about which nothing is known except that it is
able to receive messages and act on them (which may include doing
nothing at all).

> In object-oriented programming, programs describe under which
> conditions which messages are sent to object expressions at
> runtime:  For this purpose, there is a dispatch specification
> that defines the recipient object expression and the message
> to be sent.  This dispatch definition can also be regarded as
> an expression whose value is then determined by the recipient
> object (as a type of response).  (source code model)

The key property of object-oriented programming is that sending a
message is the only way to accomplish anything.  Sending a
message may start an activity and never return, or it may finish
and return an object value, with the understanding that "object
value" always means using pointer semantics.  There are no data
values as such;  the only kinds of values in OOP are objects.

In addition to sending messages, Smalltalk has ways of using
identifiers to refer to an object, of combining or sequencing
message send constructs, and of assigning an object value (which
again uses pointer semantics) to a named object holder (some form
of identifier), but these capabilities are secondary to the key
property described in the previous paragraph.

> It must be possible to determine which object receives a
> particular message (late binding) as late as possible (i.e. at
> runtime during the evaluation of the dispatch determination):

The late binding that Alan is talking about is the binding of
messages to processing activity.  Note the contrast with calling
a function, where the binding of name to what processing is done
is static rather than deferred.

> For this purpose, the recipient object can be specified again
> in the dispatch determination itself by means of an expression
> that is only evaluated at runtime as late as possible (runtime
> polymorphism).

It's true that the returned object value of a sent message can be
used to send a further message, but that is not an occurrence of
binding.  Calling a function through a pointer-to-function relies
on information known only at runtime, but no binding is taking
place for that (except perhaps for the mapping of a variable name
to a location holding the pointer-to-function value).

>   Yes, I really think it is better to say that we send messages
>   to expressions because which object the expression represents
>   is only determined shortly beforehand and can be different
>   each time the same code is run several times.

Messages are always sent to objects, not to expressions.

Obviously determining an object value at runtime is useful, but it
isn't any different than determining any other value at runtime.
Calling a function in C that takes two arguments and returns their
sum depends on values determined at runtime, but that nothing to do
with late binding.

The key point is that, having gotten back an object, we can't do
anything with it except send it a message, and the binding of
message to what processing activity will occur always takes place
at the last possible moment.

>   But there's something else of equal importance!  It's the
>   insight by Uncle Bob (Robert C. Martin) about when procedural
>   code is better and when object-oriented code is better.
>
> |Procedural code (code using data structures) makes it easy to
> |add new functions without changing the existing data
> |structures.  OO code, on the other hand, makes it easy to add
> |new classes without changing existing functions.
> Robert C. Martin
>
> |Procedural code makes it hard to add new data structures
> |because all the functions must change.  OO code makes it hard
> |to add new functions because all the classes must change.
> Robert C. Martin

Both of these comments make the mistake of conflating OOP with
programming in languages that have classes.  That isn't what Alan
meant by object-oriented programming.  That Smalltalk has classes
is incidental to what is meant by object-oriented programming;
classes in Smalltalk are simply a way of implementing the abstract
idea of "object-oriented programming" that had started in Alan's
thinking, and actually much earlier than Smalltalk or even Simula.

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

#121997

On Mon, 2025-03-17 at 10:17 -0700, Tim Rentsch wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
> > Rosario19 <Ros@invalid.invalid> wrote or quoted:
> > 
> > > what is oo programming?
> > 
> >   Alan Kay coined the term, and, in 2003, I asked him:
> > 
> > What does "object-oriented [programming]" mean to you?
> > 
> >   . He answered in an e-mail:
> > 
> > > OOP to me means only messaging, local retention and protection and
> > > hiding of state-process, and extreme late-binding of all things.
> > 
> >   . My personal interpretation (taking the above source and my
> >   own observations into account):
> 
> I appreciate your efforts in pursuing this and in describing what
> you think it all means.  I'm glad to see a discussion about OOP
> that goes beyond the common misunderstandings of what is meant.
> 
> I would like to respond to your comments with my own understanding
> of how Alan views these areas.  I should explain that I have talked
> with (and also listened to) Alan enough so that I think I have a
> pretty good understanding of what his views are here, but the
> comments below are just my impression of his thoughts.
> 
> > An object is an imaginary building block that contains states
> > and procedures and can only be accessed from the outside by
> > sending messages.  The object decides how it reacts (within the
> > scope of its specification) to a specific message.  (runtime
> > model)
> 
> An object is a blob about which nothing is known except that it is
> able to receive messages and act on them (which may include doing
> nothing at all).
> 
> > In object-oriented programming, programs describe under which
> > conditions which messages are sent to object expressions at
> > runtime:  For this purpose, there is a dispatch specification
> > that defines the recipient object expression and the message
> > to be sent.  This dispatch definition can also be regarded as
> > an expression whose value is then determined by the recipient
> > object (as a type of response).  (source code model)
> 
> The key property of object-oriented programming is that sending a
> message is the only way to accomplish anything.  Sending a
> message may start an activity and never return, or it may finish
> and return an object value, with the understanding that "object
> value" always means using pointer semantics.  There are no data
> values as such;  the only kinds of values in OOP are objects.
> 
> In addition to sending messages, Smalltalk has ways of using
> identifiers to refer to an object, of combining or sequencing
> message send constructs, and of assigning an object value (which
> again uses pointer semantics) to a named object holder (some form
> of identifier), but these capabilities are secondary to the key
> property described in the previous paragraph.
> 
> > It must be possible to determine which object receives a
> > particular message (late binding) as late as possible (i.e. at
> > runtime during the evaluation of the dispatch determination):
> 
> The late binding that Alan is talking about is the binding of
> messages to processing activity.  Note the contrast with calling
> a function, where the binding of name to what processing is done
> is static rather than deferred.
> 
> > For this purpose, the recipient object can be specified again
> > in the dispatch determination itself by means of an expression
> > that is only evaluated at runtime as late as possible (runtime
> > polymorphism).
> 
> It's true that the returned object value of a sent message can be
> used to send a further message, but that is not an occurrence of
> binding.  Calling a function through a pointer-to-function relies
> on information known only at runtime, but no binding is taking
> place for that (except perhaps for the mapping of a variable name
> to a location holding the pointer-to-function value).
> 
> >   Yes, I really think it is better to say that we send messages
> >   to expressions because which object the expression represents
> >   is only determined shortly beforehand and can be different
> >   each time the same code is run several times.
> 
> Messages are always sent to objects, not to expressions.
> 
> Obviously determining an object value at runtime is useful, but it
> isn't any different than determining any other value at runtime.
> Calling a function in C that takes two arguments and returns their
> sum depends on values determined at runtime, but that nothing to do
> with late binding.
> 
> The key point is that, having gotten back an object, we can't do
> anything with it except send it a message, and the binding of
> message to what processing activity will occur always takes place
> at the last possible moment.
> 
> >   But there's something else of equal importance!  It's the
> >   insight by Uncle Bob (Robert C. Martin) about when procedural
> >   code is better and when object-oriented code is better.
> > 
> > > Procedural code (code using data structures) makes it easy to
> > > add new functions without changing the existing data
> > > structures.  OO code, on the other hand, makes it easy to add
> > > new classes without changing existing functions.
> > Robert C. Martin
> > 
> > > Procedural code makes it hard to add new data structures
> > > because all the functions must change.  OO code makes it hard
> > > to add new functions because all the classes must change.
> > Robert C. Martin
> 
> Both of these comments make the mistake of conflating OOP with
> programming in languages that have classes.  That isn't what Alan
> meant by object-oriented programming.  That Smalltalk has classes
> is incidental to what is meant by object-oriented programming;
> classes in Smalltalk are simply a way of implementing the abstract
> idea of "object-oriented programming" that had started in Alan's
> thinking, and actually much earlier than Smalltalk or even Simula.

Agreed.
From the view of Spu (revised Turing Machine model), 'OOP' is the result of
ctor/dtor, associated with it is the instruction being called as 'access method'.
-------
Wy.Sct.Spu(3wy)                                                 Wy.Sct.Spu(3wy)

NAME
       Spu - Class of general purpose Soft-CPU

SYNOPSIS
       Except POD types, C structures, all types are declared in namespace Wy.

       #include <CSCall/Sct.h>

       Spu  (Soft  CPU)  is  a revised model of Turing Machine and a class that
       acts like a general purpose CPU-based computing machine to  provide  se‐
       mantics for computing language and for remote program communication.

       The  main differences of Spu and general purpose CPU (or TM) is that Spu
       has no ´register´ nor ´flag´, Spu has only a tape. The tape is initially
       empty. Every object (referred to as tape variable) in the tape is  allo‐
       cated via instruction Alloc and identified by a continuous index number.
       Tape variable can be any C++ type, including Spu.

       The  instruction  of Spu is application definable. Except necessary few,
       about  >30  instructions  are  defined  for  convenience,  see   manpage
       Wy.Sct(3wy).

       Documentation following omits the scope name Wy::Sct for each occurrence
       of Spu for clearity.

PUBLIC MEMBERS
        class Reply
        typedef ssize_t IndexType
        Spu()
        ~Spu()

        InstrIdx next_instr
        Array<InstrIdx> istack
        Array<unsign char> tape
        PtrArray<InstrBase> program

        template<T> const T& get_data(IndexType) const
        template<T> T& get_data(IndexType)
        void set_instr_base(Spu&)
        Errno run(InstrIdx)
        Errno step()
        void add_instr(InstrBase*)

AUXILIARY FUNCTIONS
        SPU_INSTR(x)
        Errno fix_label(Spu&)
        constexpr InstrIdx Label(void*)
...[cut]

As seen, OOP in the view of TM is about the concept of analysis and processing
of programming problems (centered around 'object' created and destructed), less
about the prgramming language being used.
libwy's OOP (ClassGuidelines.txt
https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
) made it preciser as written guidelines rather than 'philosophical talk'.

 Follow the guidelines, so that:
 1. the 'programmable concept' can be much universal and solid.
 2. It makes the programmer know whether its concept of programming idea is
    proper or not in as early as it is used, significantly reducing the workload
    of software development (design+implement+maintenence+development).

Note: class Spu itself is one of the few cases not fit ClassGuidelines well (for reasons).

Talk of the OOP concept is not easy, ClassGuidelines has been practiced for
>20 years and still valid, and the applicability is still growing.

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

#122013

On Wed, 2025-03-19 at 04:58 +0800, wij wrote:
> On Mon, 2025-03-17 at 10:17 -0700, Tim Rentsch wrote:
> > ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > 
> > > Rosario19 <Ros@invalid.invalid> wrote or quoted:
> > > 
> > > > what is oo programming?
> > > 
> > >   Alan Kay coined the term, and, in 2003, I asked him:
> > > 
> > > What does "object-oriented [programming]" mean to you?
> > > 
> > >   . He answered in an e-mail:
> > > 
> > > > OOP to me means only messaging, local retention and protection and
> > > > hiding of state-process, and extreme late-binding of all things.
> > > 
> > >   . My personal interpretation (taking the above source and my
> > >   own observations into account):
> > 
> > I appreciate your efforts in pursuing this and in describing what
> > you think it all means.  I'm glad to see a discussion about OOP
> > that goes beyond the common misunderstandings of what is meant.
> > 
> > I would like to respond to your comments with my own understanding
> > of how Alan views these areas.  I should explain that I have talked
> > with (and also listened to) Alan enough so that I think I have a
> > pretty good understanding of what his views are here, but the
> > comments below are just my impression of his thoughts.
> > 
> > > An object is an imaginary building block that contains states
> > > and procedures and can only be accessed from the outside by
> > > sending messages.  The object decides how it reacts (within the
> > > scope of its specification) to a specific message.  (runtime
> > > model)
> > 
> > An object is a blob about which nothing is known except that it is
> > able to receive messages and act on them (which may include doing
> > nothing at all).
> > 
> > > In object-oriented programming, programs describe under which
> > > conditions which messages are sent to object expressions at
> > > runtime:  For this purpose, there is a dispatch specification
> > > that defines the recipient object expression and the message
> > > to be sent.  This dispatch definition can also be regarded as
> > > an expression whose value is then determined by the recipient
> > > object (as a type of response).  (source code model)
> > 
> > The key property of object-oriented programming is that sending a
> > message is the only way to accomplish anything.  Sending a
> > message may start an activity and never return, or it may finish
> > and return an object value, with the understanding that "object
> > value" always means using pointer semantics.  There are no data
> > values as such;  the only kinds of values in OOP are objects.
> > 
> > In addition to sending messages, Smalltalk has ways of using
> > identifiers to refer to an object, of combining or sequencing
> > message send constructs, and of assigning an object value (which
> > again uses pointer semantics) to a named object holder (some form
> > of identifier), but these capabilities are secondary to the key
> > property described in the previous paragraph.
> > 
> > > It must be possible to determine which object receives a
> > > particular message (late binding) as late as possible (i.e. at
> > > runtime during the evaluation of the dispatch determination):
> > 
> > The late binding that Alan is talking about is the binding of
> > messages to processing activity.  Note the contrast with calling
> > a function, where the binding of name to what processing is done
> > is static rather than deferred.
> > 
> > > For this purpose, the recipient object can be specified again
> > > in the dispatch determination itself by means of an expression
> > > that is only evaluated at runtime as late as possible (runtime
> > > polymorphism).
> > 
> > It's true that the returned object value of a sent message can be
> > used to send a further message, but that is not an occurrence of
> > binding.  Calling a function through a pointer-to-function relies
> > on information known only at runtime, but no binding is taking
> > place for that (except perhaps for the mapping of a variable name
> > to a location holding the pointer-to-function value).
> > 
> > >   Yes, I really think it is better to say that we send messages
> > >   to expressions because which object the expression represents
> > >   is only determined shortly beforehand and can be different
> > >   each time the same code is run several times.
> > 
> > Messages are always sent to objects, not to expressions.
> > 
> > Obviously determining an object value at runtime is useful, but it
> > isn't any different than determining any other value at runtime.
> > Calling a function in C that takes two arguments and returns their
> > sum depends on values determined at runtime, but that nothing to do
> > with late binding.
> > 
> > The key point is that, having gotten back an object, we can't do
> > anything with it except send it a message, and the binding of
> > message to what processing activity will occur always takes place
> > at the last possible moment.
> > 
> > >   But there's something else of equal importance!  It's the
> > >   insight by Uncle Bob (Robert C. Martin) about when procedural
> > >   code is better and when object-oriented code is better.
> > > 
> > > > Procedural code (code using data structures) makes it easy to
> > > > add new functions without changing the existing data
> > > > structures.  OO code, on the other hand, makes it easy to add
> > > > new classes without changing existing functions.
> > > Robert C. Martin
> > > 
> > > > Procedural code makes it hard to add new data structures
> > > > because all the functions must change.  OO code makes it hard
> > > > to add new functions because all the classes must change.
> > > Robert C. Martin
> > 
> > Both of these comments make the mistake of conflating OOP with
> > programming in languages that have classes.  That isn't what Alan
> > meant by object-oriented programming.  That Smalltalk has classes
> > is incidental to what is meant by object-oriented programming;
> > classes in Smalltalk are simply a way of implementing the abstract
> > idea of "object-oriented programming" that had started in Alan's
> > thinking, and actually much earlier than Smalltalk or even Simula.
> 
> Agreed.
> From the view of Spu (revised Turing Machine model), 'OOP' is the result of
> ctor/dtor, associated with it is the instruction being called as 'access method'.
> -------
> Wy.Sct.Spu(3wy)                                                 Wy.Sct.Spu(3wy)
> 
> NAME
>        Spu - Class of general purpose Soft-CPU
> 
> SYNOPSIS
>        Except POD types, C structures, all types are declared in namespace Wy.
> 
>        #include <CSCall/Sct.h>
> 
>        Spu  (Soft  CPU)  is  a revised model of Turing Machine and a class that
>        acts like a general purpose CPU-based computing machine to  provide  se‐
>        mantics for computing language and for remote program communication.
> 
>        The  main differences of Spu and general purpose CPU (or TM) is that Spu
>        has no ´register´ nor ´flag´, Spu has only a tape. The tape is initially
>        empty. Every object (referred to as tape variable) in the tape is  allo‐
>        cated via instruction Alloc and identified by a continuous index number.
>        Tape variable can be any C++ type, including Spu.
> 
>        The  instruction  of Spu is application definable. Except necessary few,
>        about  >30  instructions  are  defined  for  convenience,  see   manpage
>        Wy.Sct(3wy).
> 
>        Documentation following omits the scope name Wy::Sct for each occurrence
>        of Spu for clearity.
> 
> PUBLIC MEMBERS
>         class Reply
>         typedef ssize_t IndexType
>         Spu()
>         ~Spu()
> 
>         InstrIdx next_instr
>         Array<InstrIdx> istack
>         Array<unsign char> tape
>         PtrArray<InstrBase> program
> 
>         template<T> const T& get_data(IndexType) const
>         template<T> T& get_data(IndexType)
>         void set_instr_base(Spu&)
>         Errno run(InstrIdx)
>         Errno step()
>         void add_instr(InstrBase*)
> 
> AUXILIARY FUNCTIONS
>         SPU_INSTR(x)
>         Errno fix_label(Spu&)
>         constexpr InstrIdx Label(void*)
> ...[cut]
> 
> As seen, OOP in the view of TM is about the concept of analysis and processing
> of programming problems (centered around 'object' created and destructed), less
> about the prgramming language being used.
> libwy's OOP (ClassGuidelines.txt
> https://sourceforge.net/projects/cscall/files/MisFiles/ClassGuidelines.txt/download
> ) made it preciser as written guidelines rather than 'philosophical talk'.
> 
>  Follow the guidelines, so that:
>  1. the 'programmable concept' can be much universal and solid.
>  2. It makes the programmer know whether its concept of programming idea is
>     proper or not in as early as it is used, significantly reducing the workload
>     of software development (design+implement+maintenence+development).
> 
> Note: class Spu itself is one of the few cases not fit ClassGuidelines well (for reasons).
> 
> Talk of the OOP concept is not easy, ClassGuidelines has been practiced for
> > 20 years and still valid, and the applicability is still growing.
> 

So, the basics of OO is the very concept of object, which is particularily
realized in C++ by ctor (equivalent to init/open(..), close(..) in C).
libwy defines the semantics and several other access functions
 1。ctor,and associated reset functions.
 2. const member functions identify the 'attribute' of the created object.
    (Most attribute functions are class specific. libwy defines one: is_default)
 3. non-constmemers modifies attributes. In principle, what is modified must be
    'visible' or test-able.

Looks not much different, too simple? 
Every new class (and written class) will encounter the same problems above again
and again: What the role or class member should be? 
Most problems found (in libwy's view) are: 1. Attributes of class are not clear.
What follow are inconsistent functionality of access members. If this is not clear
'correctness' is difficult to talk about. 2. the function of assignment and copy 
ctor are not quite the same.

Many software problems are from these simple basics (semantics of concept/class).
If not correctly solved, further development won't go far.

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

#122014

On Mon, 17 Mar 2025 10:17:51 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> 
> The late binding that Alan is talking about is the binding of
> messages to processing activity.  Note the contrast with calling
> a function, where the binding of name to what processing is done
> is static rather than deferred.
> 

It sounds like very flexible paradigm that I very certainly don't want
to use.
I like majority of my mistakes caught in compile/link/load time rather
than in run time.

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

#122046

Michael S <already5chosen@yahoo.com> writes:

> On Mon, 17 Mar 2025 10:17:51 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> The late binding that Alan is talking about is the binding of
>> messages to processing activity.  Note the contrast with calling
>> a function, where the binding of name to what processing is done
>> is static rather than deferred.
>
> It sounds like very flexible paradigm that I very certainly don't want
> to use.
> I like majority of my mistakes caught in compile/link/load time rather
> than in run time.

It's important to understand that object-oriented programming is
more about mindset than it is about any particular set of language
features.  In particular, OOP is not incompatible with strong type
checking, especially under the "majority" criterion.  There are
languages with classes and inheritance that also impose strict type
checking (OCaml is one example), which I think would get you the
property you want of catching most mistakes before run time.  I
don't mean to suggest that a combination "ideal OOP" and perfect
type checking is a solved problem, it isn't.  My sense though is
that languages that are available now can supply between 80 and 90
percent of both.  You might want to try looking into whether that
could do what you want.

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

#122037

On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
>> Rosario19 <Ros@invalid.invalid> wrote or quoted:
>>
>>> what is oo programming?
>>
>>   Alan Kay coined the term, and, in 2003, I asked him:
>>
>> What does "object-oriented [programming]" mean to you?
>>
>>   . He answered in an e-mail:
>>
>> |OOP to me means only messaging, local retention and protection and
>> |hiding of state-process, and extreme late-binding of all things.
>>
>>   . My personal interpretation (taking the above source and my own
>>   observations into account):
> 
> I appreciate your efforts in pursuing this and in describing what you
> think it all means.  I'm glad to see a discussion about OOP that goes
> beyond the common misunderstandings of what is meant.
> 
> I would like to respond to your comments with my own understanding of
> how Alan views these areas.  I should explain that I have talked with
> (and also listened to) Alan enough so that I think I have a pretty good
> understanding of what his views are here, but the comments below are
> just my impression of his thoughts.
> 
>> An object is an imaginary building block that contains states and
>> procedures and can only be accessed from the outside by sending
>> messages.  The object decides how it reacts (within the scope of its
>> specification) to a specific message.  (runtime model)
> 
> An object is a blob about which nothing is known except that it is able
> to receive messages and act on them (which may include doing nothing at
> all).
> 
>> In object-oriented programming, programs describe under which
>> conditions which messages are sent to object expressions at runtime: 
>> For this purpose, there is a dispatch specification that defines the
>> recipient object expression and the message to be sent.  This dispatch
>> definition can also be regarded as an expression whose value is then
>> determined by the recipient object (as a type of response).  (source
>> code model)
> 
> The key property of object-oriented programming is that sending a
> message is the only way to accomplish anything.  Sending a message may
> start an activity and never return, or it may finish and return an
> object value, with the understanding that "object value" always means
> using pointer semantics.  There are no data values as such;  the only
> kinds of values in OOP are objects.
> 
> In addition to sending messages, Smalltalk has ways of using identifiers
> to refer to an object, of combining or sequencing message send
> constructs, and of assigning an object value (which again uses pointer
> semantics) to a named object holder (some form of identifier), but these
> capabilities are secondary to the key property described in the previous
> paragraph.
> 
>> It must be possible to determine which object receives a particular
>> message (late binding) as late as possible (i.e. at runtime during the
>> evaluation of the dispatch determination):
> 
> The late binding that Alan is talking about is the binding of messages
> to processing activity.  Note the contrast with calling a function,
> where the binding of name to what processing is done is static rather
> than deferred.
> 
>> For this purpose, the recipient object can be specified again in the
>> dispatch determination itself by means of an expression that is only
>> evaluated at runtime as late as possible (runtime polymorphism).
> 
> It's true that the returned object value of a sent message can be used
> to send a further message, but that is not an occurrence of binding. 
> Calling a function through a pointer-to-function relies on information
> known only at runtime, but no binding is taking place for that (except
> perhaps for the mapping of a variable name to a location holding the
> pointer-to-function value).
> 
>>   Yes, I really think it is better to say that we send messages to
>>   expressions because which object the expression represents is only
>>   determined shortly beforehand and can be different each time the same
>>   code is run several times.
> 
> Messages are always sent to objects, not to expressions.
> 
> Obviously determining an object value at runtime is useful, but it isn't
> any different than determining any other value at runtime. Calling a
> function in C that takes two arguments and returns their sum depends on
> values determined at runtime, but that nothing to do with late binding.
> 
> The key point is that, having gotten back an object, we can't do
> anything with it except send it a message, and the binding of message to
> what processing activity will occur always takes place at the last
> possible moment.
> 
>>   But there's something else of equal importance!  It's the insight by
>>   Uncle Bob (Robert C. Martin) about when procedural code is better and
>>   when object-oriented code is better.
>>
>> |Procedural code (code using data structures) makes it easy to |add new
>> functions without changing the existing data |structures.  OO code, on
>> the other hand, makes it easy to add |new classes without changing
>> existing functions.
>> Robert C. Martin
>>
>> |Procedural code makes it hard to add new data structures |because all
>> the functions must change.  OO code makes it hard |to add new functions
>> because all the classes must change.
>> Robert C. Martin
> 
> Both of these comments make the mistake of conflating OOP with
> programming in languages that have classes.  That isn't what Alan meant
> by object-oriented programming.  That Smalltalk has classes is
> incidental to what is meant by object-oriented programming; classes in
> Smalltalk are simply a way of implementing the abstract idea of
> "object-oriented programming" that had started in Alan's thinking, and
> actually much earlier than Smalltalk or even Simula.

Wrong. OOP is:

* Encapsulation
* Inheritance
* Polymorphism (including LSP)
* Abstractions

The above necessitates the need for classes or similar.

/Flibble

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

#122042

On Thu, 2025-03-27 at 18:23 +0000, Mr Flibble wrote:
> On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
> 
> > ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > 
> > > Rosario19 <Ros@invalid.invalid> wrote or quoted:
> > > 
> > > > what is oo programming?
> > > 
> > >   Alan Kay coined the term, and, in 2003, I asked him:
> > > 
> > > What does "object-oriented [programming]" mean to you?
> > > 
> > >   . He answered in an e-mail:
> > > 
> > > > OOP to me means only messaging, local retention and protection and
> > > > hiding of state-process, and extreme late-binding of all things.
> > > 
> > >   . My personal interpretation (taking the above source and my own
> > >   observations into account):
> > 
> > I appreciate your efforts in pursuing this and in describing what you
> > think it all means.  I'm glad to see a discussion about OOP that goes
> > beyond the common misunderstandings of what is meant.
> > 
> > I would like to respond to your comments with my own understanding of
> > how Alan views these areas.  I should explain that I have talked with
> > (and also listened to) Alan enough so that I think I have a pretty good
> > understanding of what his views are here, but the comments below are
> > just my impression of his thoughts.
> > 
> > > An object is an imaginary building block that contains states and
> > > procedures and can only be accessed from the outside by sending
> > > messages.  The object decides how it reacts (within the scope of its
> > > specification) to a specific message.  (runtime model)
> > 
> > An object is a blob about which nothing is known except that it is able
> > to receive messages and act on them (which may include doing nothing at
> > all).
> > 
> > > In object-oriented programming, programs describe under which
> > > conditions which messages are sent to object expressions at runtime: 
> > > For this purpose, there is a dispatch specification that defines the
> > > recipient object expression and the message to be sent.  This dispatch
> > > definition can also be regarded as an expression whose value is then
> > > determined by the recipient object (as a type of response).  (source
> > > code model)
> > 
> > The key property of object-oriented programming is that sending a
> > message is the only way to accomplish anything.  Sending a message may
> > start an activity and never return, or it may finish and return an
> > object value, with the understanding that "object value" always means
> > using pointer semantics.  There are no data values as such;  the only
> > kinds of values in OOP are objects.
> > 
> > In addition to sending messages, Smalltalk has ways of using identifiers
> > to refer to an object, of combining or sequencing message send
> > constructs, and of assigning an object value (which again uses pointer
> > semantics) to a named object holder (some form of identifier), but these
> > capabilities are secondary to the key property described in the previous
> > paragraph.
> > 
> > > It must be possible to determine which object receives a particular
> > > message (late binding) as late as possible (i.e. at runtime during the
> > > evaluation of the dispatch determination):
> > 
> > The late binding that Alan is talking about is the binding of messages
> > to processing activity.  Note the contrast with calling a function,
> > where the binding of name to what processing is done is static rather
> > than deferred.
> > 
> > > For this purpose, the recipient object can be specified again in the
> > > dispatch determination itself by means of an expression that is only
> > > evaluated at runtime as late as possible (runtime polymorphism).
> > 
> > It's true that the returned object value of a sent message can be used
> > to send a further message, but that is not an occurrence of binding. 
> > Calling a function through a pointer-to-function relies on information
> > known only at runtime, but no binding is taking place for that (except
> > perhaps for the mapping of a variable name to a location holding the
> > pointer-to-function value).
> > 
> > >   Yes, I really think it is better to say that we send messages to
> > >   expressions because which object the expression represents is only
> > >   determined shortly beforehand and can be different each time the same
> > >   code is run several times.
> > 
> > Messages are always sent to objects, not to expressions.
> > 
> > Obviously determining an object value at runtime is useful, but it isn't
> > any different than determining any other value at runtime. Calling a
> > function in C that takes two arguments and returns their sum depends on
> > values determined at runtime, but that nothing to do with late binding.
> > 
> > The key point is that, having gotten back an object, we can't do
> > anything with it except send it a message, and the binding of message to
> > what processing activity will occur always takes place at the last
> > possible moment.
> > 
> > >   But there's something else of equal importance!  It's the insight by
> > >   Uncle Bob (Robert C. Martin) about when procedural code is better and
> > >   when object-oriented code is better.
> > > 
> > > > Procedural code (code using data structures) makes it easy to |add new
> > > functions without changing the existing data |structures.  OO code, on
> > > the other hand, makes it easy to add |new classes without changing
> > > existing functions.
> > > Robert C. Martin
> > > 
> > > > Procedural code makes it hard to add new data structures |because all
> > > the functions must change.  OO code makes it hard |to add new functions
> > > because all the classes must change.
> > > Robert C. Martin
> > 
> > Both of these comments make the mistake of conflating OOP with
> > programming in languages that have classes.  That isn't what Alan meant
> > by object-oriented programming.  That Smalltalk has classes is
> > incidental to what is meant by object-oriented programming; classes in
> > Smalltalk are simply a way of implementing the abstract idea of
> > "object-oriented programming" that had started in Alan's thinking, and
> > actually much earlier than Smalltalk or even Simula.
> 
> Wrong. OOP is:
> 
> * Encapsulation
> * Inheritance
> * Polymorphism (including LSP)
> * Abstractions
> 
> The above necessitates the need for classes or similar.
> 
> /Flibble

Blind reciting! Or, useless (worse than none, garbage definition).

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

#122043

On Sat, 29 Mar 2025 11:12:08 +0800, wij wrote:

> On Thu, 2025-03-27 at 18:23 +0000, Mr Flibble wrote:
>> On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
>> 
>> > ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> > 
>> > > Rosario19 <Ros@invalid.invalid> wrote or quoted:
>> > > 
>> > > > what is oo programming?
>> > > 
>> > >   Alan Kay coined the term, and, in 2003, I asked him:
>> > > 
>> > > What does "object-oriented [programming]" mean to you?
>> > > 
>> > >   . He answered in an e-mail:
>> > > 
>> > > > OOP to me means only messaging, local retention and protection
>> > > > and hiding of state-process, and extreme late-binding of all
>> > > > things.
>> > > 
>> > >   . My personal interpretation (taking the above source and my own
>> > >   observations into account):
>> > 
>> > I appreciate your efforts in pursuing this and in describing what you
>> > think it all means.  I'm glad to see a discussion about OOP that goes
>> > beyond the common misunderstandings of what is meant.
>> > 
>> > I would like to respond to your comments with my own understanding of
>> > how Alan views these areas.  I should explain that I have talked with
>> > (and also listened to) Alan enough so that I think I have a pretty
>> > good understanding of what his views are here, but the comments below
>> > are just my impression of his thoughts.
>> > 
>> > > An object is an imaginary building block that contains states and
>> > > procedures and can only be accessed from the outside by sending
>> > > messages.  The object decides how it reacts (within the scope of
>> > > its specification) to a specific message.  (runtime model)
>> > 
>> > An object is a blob about which nothing is known except that it is
>> > able to receive messages and act on them (which may include doing
>> > nothing at all).
>> > 
>> > > In object-oriented programming, programs describe under which
>> > > conditions which messages are sent to object expressions at
>> > > runtime: For this purpose, there is a dispatch specification that
>> > > defines the recipient object expression and the message to be
>> > > sent.  This dispatch definition can also be regarded as an
>> > > expression whose value is then determined by the recipient object
>> > > (as a type of response).  (source code model)
>> > 
>> > The key property of object-oriented programming is that sending a
>> > message is the only way to accomplish anything.  Sending a message
>> > may start an activity and never return, or it may finish and return
>> > an object value, with the understanding that "object value" always
>> > means using pointer semantics.  There are no data values as such; 
>> > the only kinds of values in OOP are objects.
>> > 
>> > In addition to sending messages, Smalltalk has ways of using
>> > identifiers to refer to an object, of combining or sequencing message
>> > send constructs, and of assigning an object value (which again uses
>> > pointer semantics) to a named object holder (some form of
>> > identifier), but these capabilities are secondary to the key property
>> > described in the previous paragraph.
>> > 
>> > > It must be possible to determine which object receives a particular
>> > > message (late binding) as late as possible (i.e. at runtime during
>> > > the evaluation of the dispatch determination):
>> > 
>> > The late binding that Alan is talking about is the binding of
>> > messages to processing activity.  Note the contrast with calling a
>> > function, where the binding of name to what processing is done is
>> > static rather than deferred.
>> > 
>> > > For this purpose, the recipient object can be specified again in
>> > > the dispatch determination itself by means of an expression that is
>> > > only evaluated at runtime as late as possible (runtime
>> > > polymorphism).
>> > 
>> > It's true that the returned object value of a sent message can be
>> > used to send a further message, but that is not an occurrence of
>> > binding. Calling a function through a pointer-to-function relies on
>> > information known only at runtime, but no binding is taking place for
>> > that (except perhaps for the mapping of a variable name to a location
>> > holding the pointer-to-function value).
>> > 
>> > >   Yes, I really think it is better to say that we send messages to
>> > >   expressions because which object the expression represents is
>> > >   only determined shortly beforehand and can be different each
>> > >   time the same code is run several times.
>> > 
>> > Messages are always sent to objects, not to expressions.
>> > 
>> > Obviously determining an object value at runtime is useful, but it
>> > isn't any different than determining any other value at runtime.
>> > Calling a function in C that takes two arguments and returns their
>> > sum depends on values determined at runtime, but that nothing to do
>> > with late binding.
>> > 
>> > The key point is that, having gotten back an object, we can't do
>> > anything with it except send it a message, and the binding of message
>> > to what processing activity will occur always takes place at the last
>> > possible moment.
>> > 
>> > >   But there's something else of equal importance!  It's the
>> > >   insight by Uncle Bob (Robert C. Martin) about when procedural
>> > >   code is better and when object-oriented code is better.
>> > > 
>> > > > Procedural code (code using data structures) makes it easy to
>> > > > |add new
>> > > functions without changing the existing data |structures.  OO code,
>> > > on the other hand, makes it easy to add |new classes without
>> > > changing existing functions.
>> > > Robert C. Martin
>> > > 
>> > > > Procedural code makes it hard to add new data structures |because
>> > > > all
>> > > the functions must change.  OO code makes it hard |to add new
>> > > functions because all the classes must change.
>> > > Robert C. Martin
>> > 
>> > Both of these comments make the mistake of conflating OOP with
>> > programming in languages that have classes.  That isn't what Alan
>> > meant by object-oriented programming.  That Smalltalk has classes is
>> > incidental to what is meant by object-oriented programming; classes
>> > in Smalltalk are simply a way of implementing the abstract idea of
>> > "object-oriented programming" that had started in Alan's thinking,
>> > and actually much earlier than Smalltalk or even Simula.
>> 
>> Wrong. OOP is:
>> 
>> * Encapsulation * Inheritance * Polymorphism (including LSP)
>> * Abstractions
>> 
>> The above necessitates the need for classes or similar.
>> 
>> /Flibble
> 
> Blind reciting! Or, useless (worse than none, garbage definition).

You are wrong and fractally so.

/Flibble

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

#122044

On Sat, 29 Mar 2025 11:12:08 +0800
wij <wyniijj5@gmail.com> wrote:

> On Thu, 2025-03-27 at 18:23 +0000, Mr Flibble wrote:
> > On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
> >   
> > > ram@zedat.fu-berlin.de (Stefan Ram) writes:
> > >   
> > > > Rosario19 <Ros@invalid.invalid> wrote or quoted:
> > > >   
> > > > > what is oo programming?  
> > > > 
> > > >   Alan Kay coined the term, and, in 2003, I asked him:
> > > > 
> > > > What does "object-oriented [programming]" mean to you?
> > > > 
> > > >   . He answered in an e-mail:
> > > >   
> > > > > OOP to me means only messaging, local retention and
> > > > > protection and hiding of state-process, and extreme
> > > > > late-binding of all things.  
> > > > 
> > > >   . My personal interpretation (taking the above source and my
> > > > own observations into account):  
> > > 
> > > I appreciate your efforts in pursuing this and in describing what
> > > you think it all means.  I'm glad to see a discussion about OOP
> > > that goes beyond the common misunderstandings of what is meant.
> > > 
> > > I would like to respond to your comments with my own
> > > understanding of how Alan views these areas.  I should explain
> > > that I have talked with (and also listened to) Alan enough so
> > > that I think I have a pretty good understanding of what his views
> > > are here, but the comments below are just my impression of his
> > > thoughts. 
> > > > An object is an imaginary building block that contains states
> > > > and procedures and can only be accessed from the outside by
> > > > sending messages.  The object decides how it reacts (within the
> > > > scope of its specification) to a specific message.  (runtime
> > > > model)  
> > > 
> > > An object is a blob about which nothing is known except that it
> > > is able to receive messages and act on them (which may include
> > > doing nothing at all).
> > >   
> > > > In object-oriented programming, programs describe under which
> > > > conditions which messages are sent to object expressions at
> > > > runtime: For this purpose, there is a dispatch specification
> > > > that defines the recipient object expression and the message to
> > > > be sent.  This dispatch definition can also be regarded as an
> > > > expression whose value is then determined by the recipient
> > > > object (as a type of response).  (source code model)  
> > > 
> > > The key property of object-oriented programming is that sending a
> > > message is the only way to accomplish anything.  Sending a
> > > message may start an activity and never return, or it may finish
> > > and return an object value, with the understanding that "object
> > > value" always means using pointer semantics.  There are no data
> > > values as such;  the only kinds of values in OOP are objects.
> > > 
> > > In addition to sending messages, Smalltalk has ways of using
> > > identifiers to refer to an object, of combining or sequencing
> > > message send constructs, and of assigning an object value (which
> > > again uses pointer semantics) to a named object holder (some form
> > > of identifier), but these capabilities are secondary to the key
> > > property described in the previous paragraph.
> > >   
> > > > It must be possible to determine which object receives a
> > > > particular message (late binding) as late as possible (i.e. at
> > > > runtime during the evaluation of the dispatch determination):  
> > > 
> > > The late binding that Alan is talking about is the binding of
> > > messages to processing activity.  Note the contrast with calling
> > > a function, where the binding of name to what processing is done
> > > is static rather than deferred.
> > >   
> > > > For this purpose, the recipient object can be specified again
> > > > in the dispatch determination itself by means of an expression
> > > > that is only evaluated at runtime as late as possible (runtime
> > > > polymorphism).  
> > > 
> > > It's true that the returned object value of a sent message can be
> > > used to send a further message, but that is not an occurrence of
> > > binding. Calling a function through a pointer-to-function relies
> > > on information known only at runtime, but no binding is taking
> > > place for that (except perhaps for the mapping of a variable name
> > > to a location holding the pointer-to-function value).
> > >   
> > > >   Yes, I really think it is better to say that we send messages
> > > > to expressions because which object the expression represents
> > > > is only determined shortly beforehand and can be different each
> > > > time the same code is run several times.  
> > > 
> > > Messages are always sent to objects, not to expressions.
> > > 
> > > Obviously determining an object value at runtime is useful, but
> > > it isn't any different than determining any other value at
> > > runtime. Calling a function in C that takes two arguments and
> > > returns their sum depends on values determined at runtime, but
> > > that nothing to do with late binding.
> > > 
> > > The key point is that, having gotten back an object, we can't do
> > > anything with it except send it a message, and the binding of
> > > message to what processing activity will occur always takes place
> > > at the last possible moment.
> > >   
> > > >   But there's something else of equal importance!  It's the
> > > > insight by Uncle Bob (Robert C. Martin) about when procedural
> > > > code is better and when object-oriented code is better.
> > > >   
> > > > > Procedural code (code using data structures) makes it easy to
> > > > > |add new  
> > > > functions without changing the existing data |structures.  OO
> > > > code, on the other hand, makes it easy to add |new classes
> > > > without changing existing functions.
> > > > Robert C. Martin
> > > >   
> > > > > Procedural code makes it hard to add new data structures
> > > > > |because all  
> > > > the functions must change.  OO code makes it hard |to add new
> > > > functions because all the classes must change.
> > > > Robert C. Martin  
> > > 
> > > Both of these comments make the mistake of conflating OOP with
> > > programming in languages that have classes.  That isn't what Alan
> > > meant by object-oriented programming.  That Smalltalk has classes
> > > is incidental to what is meant by object-oriented programming;
> > > classes in Smalltalk are simply a way of implementing the
> > > abstract idea of "object-oriented programming" that had started
> > > in Alan's thinking, and actually much earlier than Smalltalk or
> > > even Simula.  
> > 
> > Wrong. OOP is:
> > 
> > * Encapsulation
> > * Inheritance
> > * Polymorphism (including LSP)
> > * Abstractions
> > 
> > The above necessitates the need for classes or similar.
> > 
> > /Flibble  
> 
> Blind reciting! Or, useless (worse than none, garbage definition).
> 

Correct.

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

#122045

On Sat, 29 Mar 2025 20:39:51 +0300, Michael S wrote:

> On Sat, 29 Mar 2025 11:12:08 +0800 wij <wyniijj5@gmail.com> wrote:
> 
>> On Thu, 2025-03-27 at 18:23 +0000, Mr Flibble wrote:
>> > On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
>> >   
>> > > ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> > >   
>> > > > Rosario19 <Ros@invalid.invalid> wrote or quoted:
>> > > >   
>> > > > > what is oo programming?
>> > > > 
>> > > >   Alan Kay coined the term, and, in 2003, I asked him:
>> > > > 
>> > > > What does "object-oriented [programming]" mean to you?
>> > > > 
>> > > >   . He answered in an e-mail:
>> > > >   
>> > > > > OOP to me means only messaging, local retention and protection
>> > > > > and hiding of state-process, and extreme late-binding of all
>> > > > > things.
>> > > > 
>> > > >   . My personal interpretation (taking the above source and my
>> > > > own observations into account):
>> > > 
>> > > I appreciate your efforts in pursuing this and in describing what
>> > > you think it all means.  I'm glad to see a discussion about OOP
>> > > that goes beyond the common misunderstandings of what is meant.
>> > > 
>> > > I would like to respond to your comments with my own understanding
>> > > of how Alan views these areas.  I should explain that I have talked
>> > > with (and also listened to) Alan enough so that I think I have a
>> > > pretty good understanding of what his views are here, but the
>> > > comments below are just my impression of his thoughts.
>> > > > An object is an imaginary building block that contains states and
>> > > > procedures and can only be accessed from the outside by sending
>> > > > messages.  The object decides how it reacts (within the scope of
>> > > > its specification) to a specific message.  (runtime model)
>> > > 
>> > > An object is a blob about which nothing is known except that it is
>> > > able to receive messages and act on them (which may include doing
>> > > nothing at all).
>> > >   
>> > > > In object-oriented programming, programs describe under which
>> > > > conditions which messages are sent to object expressions at
>> > > > runtime: For this purpose, there is a dispatch specification that
>> > > > defines the recipient object expression and the message to be
>> > > > sent.  This dispatch definition can also be regarded as an
>> > > > expression whose value is then determined by the recipient object
>> > > > (as a type of response).  (source code model)
>> > > 
>> > > The key property of object-oriented programming is that sending a
>> > > message is the only way to accomplish anything.  Sending a message
>> > > may start an activity and never return, or it may finish and return
>> > > an object value, with the understanding that "object value" always
>> > > means using pointer semantics.  There are no data values as such; 
>> > > the only kinds of values in OOP are objects.
>> > > 
>> > > In addition to sending messages, Smalltalk has ways of using
>> > > identifiers to refer to an object, of combining or sequencing
>> > > message send constructs, and of assigning an object value (which
>> > > again uses pointer semantics) to a named object holder (some form
>> > > of identifier), but these capabilities are secondary to the key
>> > > property described in the previous paragraph.
>> > >   
>> > > > It must be possible to determine which object receives a
>> > > > particular message (late binding) as late as possible (i.e. at
>> > > > runtime during the evaluation of the dispatch determination):
>> > > 
>> > > The late binding that Alan is talking about is the binding of
>> > > messages to processing activity.  Note the contrast with calling a
>> > > function, where the binding of name to what processing is done is
>> > > static rather than deferred.
>> > >   
>> > > > For this purpose, the recipient object can be specified again in
>> > > > the dispatch determination itself by means of an expression that
>> > > > is only evaluated at runtime as late as possible (runtime
>> > > > polymorphism).
>> > > 
>> > > It's true that the returned object value of a sent message can be
>> > > used to send a further message, but that is not an occurrence of
>> > > binding. Calling a function through a pointer-to-function relies on
>> > > information known only at runtime, but no binding is taking place
>> > > for that (except perhaps for the mapping of a variable name to a
>> > > location holding the pointer-to-function value).
>> > >   
>> > > >   Yes, I really think it is better to say that we send messages
>> > > > to expressions because which object the expression represents is
>> > > > only determined shortly beforehand and can be different each time
>> > > > the same code is run several times.
>> > > 
>> > > Messages are always sent to objects, not to expressions.
>> > > 
>> > > Obviously determining an object value at runtime is useful, but it
>> > > isn't any different than determining any other value at runtime.
>> > > Calling a function in C that takes two arguments and returns their
>> > > sum depends on values determined at runtime, but that nothing to do
>> > > with late binding.
>> > > 
>> > > The key point is that, having gotten back an object, we can't do
>> > > anything with it except send it a message, and the binding of
>> > > message to what processing activity will occur always takes place
>> > > at the last possible moment.
>> > >   
>> > > >   But there's something else of equal importance!  It's the
>> > > > insight by Uncle Bob (Robert C. Martin) about when procedural
>> > > > code is better and when object-oriented code is better.
>> > > >   
>> > > > > Procedural code (code using data structures) makes it easy to
>> > > > > |add new
>> > > > functions without changing the existing data |structures.  OO
>> > > > code, on the other hand, makes it easy to add |new classes
>> > > > without changing existing functions.
>> > > > Robert C. Martin
>> > > >   
>> > > > > Procedural code makes it hard to add new data structures
>> > > > > |because all
>> > > > the functions must change.  OO code makes it hard |to add new
>> > > > functions because all the classes must change.
>> > > > Robert C. Martin
>> > > 
>> > > Both of these comments make the mistake of conflating OOP with
>> > > programming in languages that have classes.  That isn't what Alan
>> > > meant by object-oriented programming.  That Smalltalk has classes
>> > > is incidental to what is meant by object-oriented programming;
>> > > classes in Smalltalk are simply a way of implementing the abstract
>> > > idea of "object-oriented programming" that had started in Alan's
>> > > thinking, and actually much earlier than Smalltalk or even Simula.
>> > 
>> > Wrong. OOP is:
>> > 
>> > * Encapsulation * Inheritance * Polymorphism (including LSP)
>> > * Abstractions
>> > 
>> > The above necessitates the need for classes or similar.
>> > 
>> > /Flibble
>> 
>> Blind reciting! Or, useless (worse than none, garbage definition).
>> 
>> 
> Correct.

Incorrect and fractally so.

/Flibble

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

#122047

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Mon, 17 Mar 2025 10:17:51 -0700, Tim Rentsch wrote:
>
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
>>> |Procedural code (code using data structures) makes it easy to |add new
>>> functions without changing the existing data |structures.  OO code, on
>>> the other hand, makes it easy to add |new classes without changing
>>> existing functions.
>>> Robert C. Martin
>>>
>>> |Procedural code makes it hard to add new data structures |because all
>>> the functions must change.  OO code makes it hard |to add new functions
>>> because all the classes must change.
>>> Robert C. Martin
>>
>> Both of these comments make the mistake of conflating OOP with
>> programming in languages that have classes.  That isn't what Alan meant
>> by object-oriented programming.  That Smalltalk has classes is
>> incidental to what is meant by object-oriented programming;  classes in
>> Smalltalk are simply a way of implementing the abstract idea of
>> "object-oriented programming" that had started in Alan's thinking, and
>> actually much earlier than Smalltalk or even Simula.
>
> Wrong.  OOP is:
>
> * Encapsulation
> * Inheritance
> * Polymorphism (including LSP)
> * Abstractions
>
> The above necessitates the need for classes or similar.

Your view of object-oriented programs is different from Alan Kay's view
of object-oriented programming.

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

#122789

On Mon, 2024-12-02 at 01:17 +0800, 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.
> 

Axiom 2 should explain why C++ can be powerful over other languages, esp. if
it strictly follows Axiom 2 as the essence of 'OOP' (the development of C++ is nowhere
near Axiom 2). See also link of ClassGuidelines.txt (it may look trivial, but don't
be fooled. Try follow it every time you design a class).
Many idea about 'program' should have been demonstrated in RealNumber2-en.txt:
Procedural language itself is more expressive (and more real) than any
other formal language in various math/logic theories.

---- Snippet from https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
(about real number and infinity)
... 
Axiom 2: An object (e.g., number, form) and its (operational) properties exist
         simultaneously through definition.

'='::= a=b iff a-b=0
  The meaning of the equality sign '=' can sometimes be ambiguous. This
  definition is intended only as a reference when its meaning is in doubt or
  undefined. According to Axiom 2, a number and its +/- operation must be
  defined simultaneously in order to use this definition to determine "equality".
-----

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web