Well, I was sort of designing on the back of a napkin there, but my
idea was that the first entry in each line is a command, the second
line is the name of the function that command calls, everything else
on the line is a parameter to that function/method call.
On Aug 11, 2005, at 4:04 PM, Rodney Somerstein wrote:
Can you tell me a little more about the table driven approach you
were mentioning? Are doplay and playTheGame two different commands,
both of which take the same arguments? Or is doplay the user
command and playTheGame is the script that I would call after
determining which command was issued? I'm guessing the latter is
what you were explaining to me.
RBScript sounds interesting, but I have been led to believe that
REALBasic doesn't work as well for non-Mac programs. Have they
gotten to the point of producing great code running on Mac and
Windows without having to jump through a lot of hoops? For that
matter, has Rev really gotten to that point? What about Linux?
Well, there are a couple of answers here. RB appears to have made
significant strides in the Windows and Linux departments with RB2005.
Windows support is pretty native and now allows debugging on Windows,
a big improvement over the older model. I haven't read much about the
quality of Windows support and apps but what I have read has been
quite positive. A fairly large number of VB refugees is making its
way to RB if that means anything.
As for Linux, RB is in beta on Linux and apparently plans to give it
away on that platform. Reports I've read have been very favorable.
OTOH, it is still beta. Rev, by comparison, has been running on Linux
for quite a while and its implementation is apparently pretty good.
I've run three compiled Rev apps on Linux (Debian via Linspire) and
they ran just right. The IDE isn't updated for Linux yet and the
engine is a revision behind as I recall. So the Linux reviews are,
I'd say, mixed on both Rev and RB.
What do you think of the approach that I mentioned in another
message of making the scripting language pretty much be composed of
just methods/scripts in whatever language I choose?
As you point out, this approach has some distinct advantages. I
certainly wouldn't allow it to rule out Rev; Kevin is open to
discussing reducing or removing the limitation on scripts at runtime
on a case by case basis and yours sounds at least potentially
sufficiently restrictive that it might pass their test.
Unfortunately neither Python or Ruby seem to offer any easy way to
write standalone applications with a GUI and make the application
easily deployable for non-developers.
Yeah, that's the rub with them alright. If Python had that, I
probably wouldn't even have looked at Rev. So on one level at least I
guess I'm glad Python is deficient in that way. :-)
I suspect I would end up needing to switch to embedding Python or
Ruby in Java to allow for this. Since both languages already offer
Java implementations, this would be easy. I'm not sure whether Ruby
is really viable, but I've heard it mentioned a lot so I have just
started looking.
Yech. Hope you don't have to do that. Java (as I suspect you know) is
so ugly and has such immense overhead. See my earlier note on Ruby. I
don't know your programming background but Ruby was certainly not
elegant and beautiful to these old Revolutionary eyes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer, Revolution Consultant and Author
http://www.shafermedia.com
Get my book, "Revolution: Software at the Speed of Thought"
From http://www.revolutionpros.com, Click "My Stuff"
_______________________________________________
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
