Is this mad?

[Richard Gaskin]

Rob Beynon wrote:
 >> I'd really like this to look like this, defining a new function
 >> 'synonym'
 >>
 >> make protein a synonym of line
 >> make aminoAcid a synonym of char
 >>
 >> Repeat for each protein in allProteins
 >> Repeat for each aminoAcid in protein
 >>
 >> Etc etc
 >>
 >> Does the extensibility/flexibility make code easier or harder to
 >> read/use?

And Eric Chatonet replied:

 > Not mad at all :-)
 > More, it's 'perfect' English like xTalk, surely more understandable.
 > When you use tLine you think as an 'almost abstract' programmer;
 > using tProtein you rely on a biological process you want to set.
 >
 > Just have a look at 
<http://www.fourthworld.com/embassy/articles/scriptstyle.html>
 > to mix names that make sense and some good habits
 > listed by Richard that will enforce understandability :-)
...
 > I just wanted to say that repeat for each line tProtein in
 > tAllProteins sounds better than repeat for each line tLine in
 > tAllProteins.
 > As for the rest, the engine has to understand what you want :-)

I'm with Eric: I think your suggestion is brilliant, and I've wanted 
something like it for some time.

In fact, I'm crafting 5GLs for two of my products in which it's 
important that those scripters be able to stay focused on the objects 
and concepts relevant to their work, and not get hung up on whatever 
syntax the engine might need to pull it off.  So I've begun 
experimenting with ways to allow simple scripts to be written which look 
rather like what you've written, and then those get translated in 
Transcript for running through the engine.

Much nicer to have some sort of declaration to let the engine do this 
itself. :)

Perhaps if/when we get OOP extensions to the language (IMNSHO an 
essential for long-term viability), it would allow expressions like what 
you wrote. It seems a good blend of xTalk traditions with 
object-oriented thinking.

Thinking about this over the last year, it occured to me that "objects" 
are really just database records, a collection of things that have 
certain properties which correlate rather cleanly with database fields.

We don't have structs in Transcript per se, but it's not hard to craft a 
modest set of handlers to emulate them effectively enough, allowing you 
to refer to items in a delimited list by name.  A simple list of field 
names and a handler using lineoffset will take care of that.

The harder part is making it Rev-like in syntax.

For example, saying:

    put FieldNameToItemNum("age") of tEmployees["Richard"]

...just doesn't flow off the tongue like:

    put the age of employee "Richard"

One could make it feel more OOP-like to use clever names:

   put ObjectAttribute(tEmployees, "Richard", "age")

...but it still doesn't feel xTalk-like.


It might be ideal to have something akin to property sets, which work as 
arrays in memory or as persistent data bound to an object with similar 
syntax, but extended to allow us to apply names for specified 
fields/items within an element.  I guess this is just a 
three-dimensional array, but they key here would be syntax to allow us 
to address these structures as gracefully as you've written above.


Of course the other side of this, in addition to properties, is behavior.

I had thought there was a request in the RQQC for parentScripts, but I 
couldn't find one so I just added it:

<http://quality.runrev.com/qacenter/show_bug.cgi?id=6404>

Feel free to refine the suggestions there, and add your votes to it as 
you see fit.

If property inheritance also seems attractive, maybe it could be refined 
to be parentObject.  I'll leave that for you folks.


And if you can come up with some nifty ways to allow us to address 
nested hierarchies of object properties for virtual objects, let's 
discuss them here to craft a good request for the RQQC.  That may have 
to wait for a full OOP implementation, but perhaps there's some clever 
way to do that for non-physical objects as we can with physical controls 
that we just haven't thought of yet....

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com