OpenEuphoria

1. [phix] Ambiguity of 'object'

• Posted by GreenEuphorian Feb 21, 2021
• 1031 views
• Last edited Feb 22, 2021

This issue has been raised before on the forum. The word 'object' currently used to refer to a generic 'data container' is ambiguous, especially to those from outside our Eu/Phix community who would naturally assume 'object' to mean the same as an object in the OOP paradigm. IMHO, a better word could replace 'object', such as 'databox' (or even simply 'box'). Especially now that objects (in the proper OOP sense) have become a thing in Phix, it is all the more important to prevent the confusion from arising.

If we want to make Phix more appealing to the larger public, we really must pay special attention to all these (minor) details that could cause confusion or disapproval, and try to iron them out before the 1.0 release.

Just my two pennies worth...

3. Re: [phix] Ambiguity of 'object'

• Posted by petelomax Feb 22, 2021
• 1044 views

I object!

The weird thing is, cmiiw, there is no "object" in most programming languages: there are classes and instances and methods, but no objects.
(Ignoring theoretical yap, and type-less languages, reading wikipedia I get the feeling we nail object in a way few others could ever hope to.)
The closest thing to object I can think of is void* in C++, but even that's quite helpless as an entity without programmer-assisted casting.

This has made me think the "five core types" diagram we've seen regularly in the past two months is not quite right:

        <--------- object ---------> 
        |            |             | 
        +-number     +-sequence    +-class 
          |            |             | 
          +-integer    +-string      +-struct 
        |                                   | 
        <-------- user defined types -------> 

Technically a class (instance) is a special kind of sequence, but that's an implementation detail and if you perform any of the normal sequence operations on it (append, slice, etc) you'll hose it.
Sequences and classes can contain other objects, but with different access methods (integer subscript vs. dot notation and string subscripts), different semantics (copy on write vs reference), and integer standing in as a routine-id in classes.
A struct implies a simpler "class without methods" with fields public by default, but in reality it is just a pure alias (of class) and any such implied differences are not enforced, apart from the easily changed public vs private default.
User defined types simply attach a clarifying name along with (optionally nested) run-time validation and verification code to the builtin types, without otherwise fundamentally changing them.
Note that a class implicitly defines a perfectly sufficient user defined type of the same name, but there is no deliberate bar on further nested layers of type wrappers, which is what "class extends" effectively does.

I think the main objections in the past were that we had object without object oriented programming.

5. Re: [phix] Ambiguity of 'object'

• Posted by _tom (admin) Feb 22, 2021
• 984 views

The ancients had once organized spoken language to recognize 'quantities' as:

one | two | many

This was roughly: I am drinking, bro and I drink, the gang drinks.

The ancients were very wise!

From this we could learn:

atom | dictionary | sequence

(Python? Lua? have done a good job of integrating 'dictionary' into their languages.)

Could E\O/P have a better map|dictionary syntax?

---

Have you ever programmed an analog computer? Have you ever seen an analog computer? I have. In the world of calculus and analog computers the idea of ''value'' is important.

In conventional languages the emphasis in on the ''container''. Languages are designed around 1-bit (boolean) 8-bit (ascii) .... 64-bit (integer) ... Each container size gets a data-type. For a given size you can add more data-types if the usage can be different.

In E\O/P the ''containers'' are simplified and made universal. That means you can concentrate on the contents or ''value'' of your objects.

 
                 value 
     ---------------------------------- 
     |             |                  | 
     number      dictionary         list 
 

From this background I would say programming could be something like:

                 container 
                 (object) 
         --------------------- 
         |         |         | 
       atom      pair      collection 
    (number)  (dictionary) (sequence) 
    (integer)                (struct) 
                              (class) 

The idea of ''list'' somehow could be fit into this picture (even if LISP has a hold of this name.)(Maybe E\O/P can say we have "lists" done right.)

A ''value'' has to belong to something; a ''value'' belongs to an ''object''. In E\O/P an object could be very simple (integer), everyday (sequence), or complex (struc, class).

At its simplest, E\O/P lets you view an object as value. As a consumer of data, you care about the value, and not the container.

Conventional languages have decades of jargon behind them. People casually say "object", "oop", "Python is easy to learn", ... , without understanding (in the least) what they are talking about. (OOP was a monetization scam promoted by Microsoft et al. It was a way of selling binary ''objects'' without source-code.)

In E\O/P the challenge is to invent language to describe how things work.

???

An ''object''  is "a constituent that is acted upon." 
A ''vessel'' is "an object used as a container." 
A  ''container'' is "an object used to hold things." 

---

The advantage of E\O/P is that actions (operators, routines) are often generic to all objects. We have generic (simple) behavior.

In OOP, actions are associated, and limited to a specific class. That makes learning OOP more difficult. That is why they talk about ''methods'' instead of function|procedure.

---

We also have to clarify how objects are used. For this I say we distinguish between ''object-based'' and ''object-oriented''.

An "object-based" variable is the value (simple).

• number, sequence

An "object-oriented" variable points to its values. (not simple, but useful).

• struc, class

Phix is now both "object-based" and "object-oriented", something a conventional language can not claim.

This is separate from how E\O/P work. On a low-level an integer value is the variable, but a sequence value points to where the items are located. As a user, I do not see or care about how this magic happens.

---

If "everything is an OOP" (almost Python, very Ruby) you complicate things. You get overloading of operators. You get aliasing. You get a maze of inheritance. Some of this is useful, some is painful.

be well
_tom

Start with a cow.e file, this is the "object", it has variables and procedures.  
It shares some of them. 
 
Copy cow.e, append "cow1" to all the names of whatever is shared in that copy,  
and append "cow1" to the filename. 
 
##Include cow.cow1.e as cow_1## 

7. Re: [phix] Ambiguity of 'object'

• Posted by GreenEuphorian Feb 23, 2021
• 945 views

Thanks indeed, Pete, for your insightful comments. They are very interesting and informative for anyone who wants to understand the semantics and the concepts of the language beyond the facade of syntax . Please keep sharing them!