[Gambas-user] Fixing bug tracker issue 78

Benoît Minisini gambas at ...1...
Thu Sep 1 14:49:33 CEST 2011


> On Wed, 2011-08-31 at 16:34 +0200, Benoît Minisini wrote:
> > This is one the design rule of Gambas : a method has to always return
> > the same
> > datatype, otherwise it must return a Variant.
> 
> Benoît,
> I think you may have missed the point of my, albeit "contrived", sample.
> On the other hand I may not have made it explicit enough to let you
> answer my fears. I'll try again:
> Emil gave an example where the result "a" of a loop construct was one of
> two closely related object references:
> "For i = 1 To 2
> 
>   If i = 1 Then
>     a = New Class1
>   Else If i = 2 Then
>     a = New Class2
>   End If
>   Print a.F() + i 'Will print the address in memory for "2" + i the second
> time Next"
> 
> There is a hidden artefact in this code in that a (an object reference)
> is of a particular inheritance sequence.  However, because both Class1
> and Class2 both have explicit and in the case of Class2 an overridding
> implementation of an attribute called F the interpreter has optimised
> that "any a.F will be an integer", which is not true in the case where a
> happens to be a Class2.
> 
> In resolving this issue you have spent a great deal of time and effort
> on introducing a "rule" that says, to me at least, "once F is declared
> in Class1, then any specialised class of Class1 "must" declare F of the
> same type,scope and signature as was declared in Class1. Please don't
> react yet.
> 
> Just consider the replacement of the original code with this:
> 
> "For i = 1 To infinty
> 
>    Select case Int(Random(i:infinty))
> 	Case 1
> 		a = new Class1
> 	Case 2
> 		a = new Class2
> 	Case 3
> 		a = Object.New("gorilla")
> ....
> 	Case 23165
> 		a= Object.New("blue_whale")
> 	Case 23166
> 		a=Object.New("bowl_of_petunias")
> ....
> 	Case 10^2134532 and falling
> 		a=Object.New("trillian")
> ....
> 	Case infinity-1
> 		a=Object.New("marvin")
> 	Case else
> 		' I'll leave THAT for the readers homework
>     End Select
> ' Now magically and against all levels of improbability all of these
> classes just "happen" to have a method ' called "F".  Strange, but not
> altogether improbable.
> 
>     Print a.F() + i 'Will succeed, somehow in some format, or not
> 
> Next"
> 
> 
> the original code, at an improbability level of 2^3498423432 just
> happened to include a situation where on the first invocation
> Int(Random(i:infinty)) was 1 and even more strangely on the second
> invocation Int(Random(i:infinty)) just happened to be 2.  Many pundits
> and philosophers have argued over exceedingly long lunches as to how
> this came about, but at the end of the day disagreed. Which only gave
> them the opportunity to have lunch again sometime, preferably before or
> at the end of the Universe.
> 
> OK, enough of my reminiscing of Doug Anderson.
> 
> 
> For i =1 to 2
>     a="something"
>     PRINT a.F()
> Next
> 
> Just because a happens to have a method called F, there should be no
> RULE that a.F(), which happened to be an integer the first time is an
> integer the second. It could be a small furry beast from Alpha
> Centauri.
> 
> Emil's example, in my opinion, has sent you off on a search for an
> explicit answer to the highly improbable sequence
> Int(Random(i:infinty)={1,2} where Class1 and Class2 are related through
> inheritance.  His "a" is an object reference which just happens to have
> a method "F" which returns an integer.  Your optimization rule seems to
> be "any a.F() is an integer".  I hope that through the above ramble, I
> have illustrated that such a supposition cannot be considered to be true
> in all instances.
> 
> Putting that another way, any expression that includes a reference to an
> object cannot EXPECT that an instance within a (subsequent) iteration IS
> going to return a SPECIFIC TYPE based on prior experience.
> 
> Benoit, I am Australian and therefore have a poor level of expressing
> myself objectively and unemotively, in the English language.
> 
> Please Consider.
> 
> regards
> Bruce

Maybe I should have talked about the difference between explicit and anonymous 
object references.

If a variable has a well-defined class datatype, then it is an "explict" 
object reference. Then, that reference can point at an object of its class or 
any inherited class only, and the inheritance constraints I described apply.

If a variable is "Object" or "Variant", then it is an "anonymous" object 
reference. In that case, the variable can be any object of any class. then the 
interpreter makes no optimization, and inheritance constraints do not apply. 
(But things are slower then!).

So, if the same method return different datatypes between all your inherited 
classes, then you must use the Variant or Object datatype instead of a 
specific class.

And I didn't know that Australian characteristic. :-)

Regards,

-- 
Benoît Minisini




More information about the User mailing list