Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 3 of 3 total
Thread Variant type
Tue, Mar 20 2012 10:16 AMPermanent Link

Robert Devine

Hi Tim

Is there something like a variant type in EWB? This would really be for
use with external JS code where a function parameter type can vary, but
where a type has to be specified in the EWB external declaration.

Cheers, Bob
Tue, Mar 20 2012 9:35 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Bob,

<< Is there something like a variant type in EWB? This would really be for
use with external JS code where a function parameter type can vary, but
where a type has to be specified in the EWB external declaration. >>

I keep going back and forth on adding variant support, and so far haven't
convinced myself that it's necessary.  The function parameter issue can be
resolved with overloaded declarations:

procedure MyFunction(Value: Integer);
procedure MyFunction(const Value: String);
procedure MyFunction(Value: Double);

The compiler will auto-magically figure out the correct procedure to call,
and you basically have function parameters that can accept multiple types.
This also applies to methods of external objects.

--
Tim Young
Elevate Software
www.elevatesoft.com
Wed, Mar 21 2012 5:21 AMPermanent Link

Robert Devine

Hi Tim

>I keep going back and forth on adding variant support

Thought you'd say something like that SmileIt's not been a problem so far
since I knew I could add stubs to the external JS. Didn't realise I
could do it in EWB - which is excellent. Given that, the need for
variants does seem weak.

Cheers, Bob


On 21/03/2012 01:35, Tim Young [Elevate Software] wrote:
> Bob,
>
> << Is there something like a variant type in EWB? This would really be
> for use with external JS code where a function parameter type can vary,
> but where a type has to be specified in the EWB external declaration. >>
>
> I keep going back and forth on adding variant support, and so far
> haven't convinced myself that it's necessary. The function parameter
> issue can be resolved with overloaded declarations:
>
> procedure MyFunction(Value: Integer);
> procedure MyFunction(const Value: String);
> procedure MyFunction(Value: Double);
>
> The compiler will auto-magically figure out the correct procedure to
> call, and you basically have function parameters that can accept
> multiple types. This also applies to methods of external objects.
>
Image