I would say that both workarounds are unacceptable.
Generating a Variant in a speed intensive Comparison for a Sort routine
is not a option.
And having a Global method for it, brakes the purpose of having a class
following a Comparision Interface to Implement a
Compare method. (and probably is also too expensive in speed)
I would say though that this huge design flaw in REALbasic is totally
unneeded because a Type cast is returning a value,
but a constructor method will never ever return a value. So there
should never be any collision there.
On Mánudagur, okt 28, 2002, at 16:11 Etc/GMT, John Balestrieri wrote:
I think this workaround is better than a global function:
1) Dim a local variant.
2) Assign the object you want to type cast to the variant
3) Assign the variant to the specific object type you want -- variants
will
do the appropriate type casting internally if your doing a valid type
cast
(but will throw an unhandled illegal cast exception if you provide the
wrong
data types, just as if you did the type cast the traditional way).
So instead of doing this:
dim x as Object
dim c1 as Class1
x = new Class1
c1 = Class1(x) //"To many parameters" or some such error
Do this instead:
dim x as Object
dim v as variant
dim c1 as Class1
x = new Class1
v = x
c1 = v
HTH,
John
Yep, that's a known serious flaw. You'll need to define a global
method
like:
---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>
Unsubscribe:
<mailto:realbasic-betas-off at lists dot realsoftware dot com>
Subscribe to the digest:
<mailto:realbasic-betas-digest at lists dot realsoftware dot com>
---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>
Unsubscribe:
<mailto:realbasic-betas-off at lists dot realsoftware dot com>
Subscribe to the digest:
<mailto:realbasic-betas-digest at lists dot realsoftware dot com>
.
|