Yes, for a longer explanation of EXACTLY what you're talking about, look at
my long example earlier in this thread.
But you're talking about (a) prepending stuff to the script, and (b)
somewhat hack-like methods in your context object.
And a & b are precisely the two things which I said (in the very post that
you quoted in your post) it would be nice to not have to resort to.
So... I don't really understand how you're offering anything different
here...
-Walter
-----Original Message-----
From: realbasic-nug-bounces at lists dot realsoftware dot com
[mailto:realbasic-nug-bounces at lists dot realsoftware dot com] On Behalf Of
Nick
Lockwood
Sent: Wednesday, September 29, 2004 5:30 PM
To: REALbasic NUG
Subject: Re: A better RBScript
You can provide your users with any kind of interface you like, all you need
to do is prepend declarations for wrapper objects on to the beginning of
your script before compiling.
Say that your context object has the methods
classADoX(properties)
classADoY(properties)
classBDoX(properties)
classBDoY(properties)
and you want your users to be able to call these functions in an elegant,
properly scoped way, e.g:
dim myobj as classA
myobj.DoX
dim myobj2 as classB
myobj2.DoX
then you just create some classes *in the script itself* that call the
appropriate functions. E.g. at the beginning of the script insert:
Class classA
dim properties as whatever
Sub DoX
classADoX(properties)
End Sub
Sub DoY
classADoY(properties)
End Sub
End Class
Now the user can create instances of these objects and they will call the
external functions. In effect you can mirror external objects internally
within the RBscript and have them call the external functions transparently
- the user need not even know about the external functions because in your
api ref you only document the object syntax for calling them. And the user
will not ever know you are inserting code into the script because you do it
after they have written their code - you needn't include before compile
time.
I haven't explained this very well, but perhaps someone who gets what I'm
talking about can do a better job. The key point is, by inserting some
standard header code into every script, consisting of interface functions,
you can give the user whatever kind of api to your external functions that
you like.
Nick
On 29 Sep 2004, at 22:14, Walter Purvis wrote:
> Well, not really. While I mostly agree with your previous statement
> that RBScript is only limited by your imagination, and I pointed out
> that you could develop object tables and dispatching mechanisms, etc,
> on your own, there are limits to what you can do in terms of making
> your API nice and clean, which was the other part of the discussion.
>
> You can't really provide your users with a nice object-oriented syntax
> if all you have are Print() and Input(). When RBScript first came out,
> it didn't even have classes. Now with classes and a single context
> object, you have pretty much all you need to build a nice API.
>
> But, that nice API will be calling some not-quite-so-nice hacks in the
> internals of your RBScript subclass. And it means you have to prepend
> all of your set-up (all the class definitions, etc) to every script
> that the user writes. Extensions like context classes or multiple
> context objects would reduce the level of hacking, prepending, and so
> on that is necessary.
>
> Which is all I was trying to say...
>
> -Walter
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://www.realsoftware.com/listarchives/lists.html>
|