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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
