Why no object models?

[Ross Lazerowitz]

This question is for the eve team. Why did you choose to not allow an OOP notion or at least some form of an Object model? I read about the comparison to Eve and other functional like environments like Excel and SQL. Was there some form of research done to come to the conclusion that this was better?

[da...@melax.ca]

Every record has flexibility that gives it OOP powers.  I can give any individual record any number of tags and values.  So, one can think of a record as being like an object.  Most of us are familiar with OOP languages that incorporate the idea of a class.  Well, if I want to use that in Eve, for example,  If I want to model a collection of, say, animal objects, then I could tag them #myAnimals and assign each record with the attributes and values I feel are necessary.  I can validate any record with #myAnimals to check that it contains all the necessary attributes, and also check those values fall within validation rules.  

I can continue this deep connection between Eve records and standard class objects.  Modelling set/get properties, methods, inheritance, prototypes are all possible.  A record can have an attribute that takes a record, or a set of records as a value.   This is in many ways like how an object can have a pointer to another object, or a collection of objects.

Binding records to each other is a very different way to think about a setter.  Let's say one record represents a data object, and another record represents its corresponding view object (say a label field on the screen).  Using BIND, one can cause the TextToDisplay attribute in the view record to respond to changes in the data record. 

Like OOP, Eve allows for mutation, and effects.  That is, one can change a value on #myInnocentLookingRecord which can be bound to #StrategicAirCommand LaunchMissiles=True.  The hope is that Eve will allow either a smart compiler, or a skilled programmer to realize the potential fallout, (pun intended) and prevent it before the code ships.

On Friday, May 19, 2017 at 11:15:59 AM UTC-6, Ross Lazerowitz wrote:

[co...@kodowa.com]

Ross,

We don't explicitly support the notion of an "object" because we want to minimize the number of concepts in the language. Keeping everything as records makes the language more uniform, and keeps it small. Also, as the other poster summarized very nicely, most of what you would want to do with objects can be achieved with records as-is.

> Was there some form of research done to come to the conclusion that this was better?

One of our primary goals was keeping the core language simple. We store data as records in a database, so the simplest interface to manipulating those is one that directly manipulates records, instead of indirectly manipulating records through objects. I don't think this necessarily means that the record interface is better than an object interface. It could turn out that it's hard to build really large applications this way, and OO programming is better suited for that.

Corey

[Josh Cole]

Just wanted to chime in to mention that David is right on the money. While our syntax might look a little foreign, OO concepts map very naturally to Eve's records. We've just made all the OO trappings like inheritance first class,  so rather than using special syntax they can be represented like everything else using blocks to manipulate data. In fact, this lets us avoid classic OO problems like the "Diamond of Death," since the user has the full power of the language available to determine how such conflicts should be resolved.

It's a really great feeling to see community members step forward and give answers about Eve better than I could have written myself. :)