Re: [phix] Ambiguity of 'object'

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu