Developer Annoyance #1

[Jim Ault]

>"transcript's ideosyncracies "

I guess the basic issue is that the messaging hierarchy is designed so that
there are several ways of building your functions/procedures into libraries,
script containers, and objects so that they are 'available' in the message
path and yet be dynamic.

You have chosen to put a function in one of the few places it is more
difficult to "call".  You could put this in a background group script or
stack script just as easily and not have the ugly.

 This is "idiosyncracy" is actually fundamental to the "on mouseup" handler
working.. imagine if the button and field objects did NOT have the current
message path... that would be ugly scripting indeed, requiring an id for
everything and no longer being a rapid development environment.

If you do not want to code according to the way
Revolution/Metacard/Supercard/Hypercard is set up, then I agree that you
will generate several instances of ugly code.

>" It also kinda obviates the entire strategy of invoking a method in
>another object."
Depends on the object, since you have many to choose from.  Putting a
function in a button or a field will have the advantage that it won't be
accidentally called by another handler.  This is very useful for user
interfaces, menus, etc.

It is this a dynamic nature of XTalk that gives it avenues of richness.
You can set the scripts of objects, reset them, move them in and out of the
hierarchy over to different stacks, into back or front script position and
more.  Move card to card and have different features and functions on each
one.

You could EVEN have most all of your scripts in text files and set the
script containers of flds, btns, cards, etc when the stack is opened.

Jim Ault
Las Vegas

On 3/17/06 12:09 AM, "Arthur Urban" <aturban at qwest.net> wrote:

> The problem with this solution is that varA and varB are not evaluated.
> In order to use your syntax it would need to be:
> 
> send "calc" && varA & comma & varB to btn "source"
> or
> send merge( "calc [[varA]], [[varB]]" ) to btn "source"
> 
> I find both inelegant readability wise. I think there is a great burden
> on language developers to create a language that goes as far as it can
> toward self-documentation. I feel that the message passing mechanisms
> are a sore spot in transcript. I do not understand why Rev would be
> unable to parse my proposed syntax.
> 
> Thank you for your suggestion, however!
> 
> Andre Garzia wrote:
>> Err...
>> 
>> can't you make it a Handler use send and check for the result???
>> 
>> send "calc VarA, VarB" to btn "source"
>> put the result into localResult
>> 
>> of course calc is not a function but a handler with a return statement.
>> 
>> Cheers
>> andre
>> 
>> 
>> 
>> On Mar 17, 2006, at 2:55 AM, Jim Ault wrote:
>> 
>>>> I'm not sure that this is the right direction for any language to be
>>>> headed. Please explain why we can't have the following syntax:
>>>> 
>>>>   put calc(varA,varB) of btn "source" into localResult
>>>> 
>> 
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
>> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution