[jawsscripts] Re: New import compiler directive
- From: Andrew Hart <ahart@xxxxxxxxxxxxx>
- To: jawsscripts@xxxxxxxxxxxxx
- Date: Wed, 14 Mar 2012 15:01:15 -0300
Using variants for everything is one way to program. In some languages
(Visual Basic for example), it is even incouraged, but as a general
rule, it is usually better programming practice to avail oneself of the
type-checking facilities provided by a compiler. This can help with
tracking down subtle mistakes and the like. However, with the jsd files
in JAWS Script serving double duty as the documentation repository and
the store for function prototypes, it doesn't make it always convenient
to use.
Recently, I hacked up some scripts and I basically wrote 70% of the jsd
file by hand. When developing scripts for a new application, it's not
always clear what functions are going to be necessary because you don't
know ahead of time what technique is actually going to work. So you
don't want to waste time writing documentation for functions that may
end up just getting thrown away.
Consequently, I find myself writing the documentation for functions well
after the functions were written and because I frequently don't use
Ctrl+e to create the function, occasionally I get caught out by the
compiler assuming that the return or a function parameter is of type
Int, and then I have to go and make an entry in the .jsd file to keep it
happy. *frown*
Actually, I think the JAWS virtual machine uses variants internally--at
least it wouldn't surprise me to learn that it does--in which case using
Variants everywhere just by-passes the type-checking mechanism in the
compiler. Please be careful with that, because if you accidentally pass
a string instead of an Int or vice versa, it's not clear what the
virtual machine will do or how it would recover.
Cheerio,
Andrew.
On 14/03/2012 2:34 PM, John Martyn wrote:
> Gotcha, that explains a lot. Besides, I use the variant to get values from
> functions instead of using the blasted JSD file.
> John
>
> -----Original Message-----
> From: jawsscripts-bounce@xxxxxxxxxxxxx
> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Hart
> Sent: Wednesday, March 14, 2012 4:51 AM
> To: jawsscripts@xxxxxxxxxxxxx
> Subject: [jawsscripts] Re: New import compiler directive
>
> John,
>
> Let me try and give it a go.
>
> Suppose that myscripts.jss contains the line
>
> Include "b.jsb"
>
> and b.jss contains
>
> Include "a.jsb"
>
> and a.jsb includes a function declaration like
>
> String function GiveMeAString()
>
>
> Now, if myscripts.jss wants to make a call to GiveMeAString(), you're going
> to get a compiler error because, while the compiler has looked for and
> loaded jsd files corresponding to myscripts.jss and b.jsb, it has not done
> so for a.jsb.
> Consequently, it assumes that GiveMeAString returns an Int and this will
> result in a type mismatch error.
> This problem appears to be rectified by explicitly telling the compiler to
> load declarations for a.jsb with
>
> Import "a.jsd"
>
> Hth,
> Andrew.
>
> On 14/03/2012 4:11 AM, John Martyn wrote:
>> I don't get it. Could you explain a little more?
>> Thanks,
>> John
>>
>> -----Original Message-----
>> From: jawsscripts-bounce@xxxxxxxxxxxxx
>> [mailto:jawsscripts-bounce@xxxxxxxxxxxxx] On Behalf Of Doug Lee
>> Sent: Tuesday, March 13, 2012 8:42 PM
>> To: jawsscripts@xxxxxxxxxxxxx
>> Subject: [jawsscripts] Re: New import compiler directive
>>
>> A scan through jss files shows examples in several. I'd say the
>> directive would be useful if you're calling a function you know exists
>> among the jsb files you're loading but the compiler doesn't get it. An
>> example would be if a.jss Uses b.jss which calls a function from
>> a.jss. This directivve seems to be new in JAWS 13.
>>
>> Cool idea anyway.
>>
>> On Wed, Mar 14, 2012 at 12:13:09AM -0300, Andrew Hart wrote:
>> Hi folks,
>>
>> I stumbled across the following line of code in QuickSet.jsd recently,
>> and a rather terse explanation buried in FileIO.jss. However, it
>> seems to be undocumented in the FSDN. Grepping the all users
>> settings\enu directory, There are a pile of scripts that use the Import
> directive.
>>
>> I can't say I truely grok it, but it appears that the Import command
>> is used for getting the Script Manager to load up function
>> declarations (from jsd
>> files) that are deeply nested in the script binary load scope.
>> I always thought that the Script Manager automatically loaded the jsd
>> files associated with binaries referenced using the Use directive. I
>> am assuming that Import is needed because the compiler isn't actually
>> clever enough to recursively scan through "Used" jsb files to find all
>> the associated jsd files necessary to provide all the required
>> function declarations, in case the top level script file calls a
>> function buried
>> 2 or more levels down in the scope (excluding functions in default.jss
>> whose documentation one would expect the Script Manager to always have on
> hand).
>>
>> Is anyone else aware of this or have I just been living on another
>> planet for the last few years?
>>
>> Cheers,
>> Andrew.
>>
>>
>> __________???
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>> --
>> Doug Lee, Senior Accessibility Programmer SSB BART Group -
>> Accessibility-on-Demand mailto:doug.lee@xxxxxxxxxxxxxxxx
>> http://www.ssbbartgroup.com "While they were saying among themselves
>> it cannot be done, it was done." --Helen Keller __________o?=
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>> __________�
>>
>> View the list's information and change your settings at
>> //www.freelists.org/list/jawsscripts
>>
>>
>>
>
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
> __________�
>
> View the list's information and change your settings at
> //www.freelists.org/list/jawsscripts
>
>
>
__________�
View the list's information and change your settings at
//www.freelists.org/list/jawsscripts
Other related posts:
