[Gambas-user] [Git][gambas/gambas][master] Get rid of unitialized variables warnings in the IDE source code.

[Adrien Prokopowicz]

Le 15/02/2018 à 01:58, Tobias Boege a écrit :
> On Thu, 15 Feb 2018, Jussi Lahtinen wrote:
>> On Thu, Feb 15, 2018 at 12:16 AM, Adrien Prokopowicz <
>> adrien.prokopowicz at gmail.com> wrote:
>>
>>> Le 14/02/2018 à 22:37, Jussi Lahtinen a écrit :
>>>
>>>> Example if you declare function Test(x as integer) and call it Test("a"),
>>>> there could be *compile* time error message about wrong type. TypeScript
>>>> does that, even when it is otherwise dynamic language.
>>>>
>>>>
>>>> Jussi
>>>>
>>>> On Wed, Feb 14, 2018 at 11:24 PM, Benoît Minisini <g4mba5 at gmail.com
>>>> <mailto:g4mba5 at gmail.com>> wrote:
>>>>
>>>>      Le 14/02/2018 à 22:17, Jussi Lahtinen a écrit :
>>>>
>>>>          Btw, did you see my mail about type checking in dynamic
>>>>          languages, like in TypeScript? I was just curious whether that
>>>>          could be possible in some extend in Gambas.
>>>>
>>>>
>>>>          Jussi
>>>>
>>>>
>>>>      I saw the mail, but I have no idea what you were talking about.
>>>>
>>>>      --     Benoît Minisini
>>>>
>>>
>>> That would be very nice to have, but I'm not sure if this wouldn't clash
>>> with the fact that Gambas has Duck Typing ? (altough I haven't seen it used
>>> anywhere, let alone mentioned in the documentation)
>>>
>>> --
>>> Adrien Prokopowicz
>>>
>> I don't think so. I think it would be having the best of the two worlds. Of
>> course such static checking couldn't be done in a lot of cases in language
>> like Gambas, but in these simple cases, why not?
>> If the argument is "as object", then it could be checked against
>> non-objects like integer. If it is "as variant", then it would have to be
>> ignored for the check, unless you are going to check how the variant is
>> used in the function/sub.
>>
> 
> Gambas is very runtime-heavy. At the moment, the compiler doesn't even care
> to look for subs beyond the current compilation unit and defers all the
> checks to runtime. If you call a function, the compiler will only check if
> it exists to generate the calling code.
> 
> Calling a sub "f()" if it doesn't exist, results in an "Unknown identifier"
> error. Calling a declared sub "f(x As Integer)" just with "f()" is OK at
> compile-time because any kind of typechecking is still performed at run-
> time. I agree that /this/ is a place where static analysis can be done.
> 
> But the compiler already has no clue anymore as soon as you call into
> another compilation unit, like with "A.f()". It doesn't even look into
> class A even if it is part of the current project, since the compiler
> is very well aware that any class can be overridden at runtime, by loading
> components. The class A in the current project might be only a part of
> the class A that is assembled at runtime.
> 
> There is a silver lining though. Overriding classes in the global symbol
> table has some rules, namely it happens by inheritance. All subs that you
> override must have the same signature as in the class that is already there.
> If the compiler can get a hold of any method definition for A.f, it can
> assume that no further component loading can change it and perform type
> checking. You have to load and inspect the components your project uses to
> do this. What it really can't determine is if a method will exist at runtime,
> thanks to Component.Load().
> 
> All value containers in Gambas are precisely typed behind the scenes.
> Every object has a link to its parent class and the C structs that store
> Gambas Integers are well aware that they store an Integer. Gambas simply
> isn't duck typing. It will *coerce* native datatypes automatically if
> it can, and raise errors otherwise:
> 
>    Public Sub f(x As Integer)
>    ...
>    End
> 
>    f()     ' ERROR: not enough arguments
>    f(0, 1) ' ERROR: too many arguments
>    f(0)    ' obviously OK
>    f("12") ' OK: String is coerced to Integer
>    f("a")  ' ERROR: Type mismatch
>    ' Notice that this code still compiles cleanly.
> 
> But if you declare two identical classes (or Structs):
> 
>    Public Struct A
>      X As Integer
>    End Struct
> 
>    Public Struct B
>      X As Integer
>    End Struct
> 
>    Public Sub Main()
>      Dim h As A
>      h = New B
>    End
> 
> then you get an error. Gambas doesn't let you violate the "h As A"
> constraint just because B behaves like an A. You can achieve something
> like that with the methods of the Object class in gb though.
> 
> The bottom line is: Yes, I think static typechecking can be improved
> in Gambas but you can't get safety guarantees because the checker has
> to *ignore* cases where it can't find a symbol, which may be patched
> in later via Component.Load() and overriding the global symbol table,
> as dirty as that is.
> 
> Regards,
> Tobi

The second example you've shown is not duck typing, it would be 
transmutation I guess (and it's something i've only found possible in 
C/C++).

You can actually have duck typing in Gambas : since you can call any 
method on any object, and the existence of this method is only checked 
at runtime, you can make functions that work with any object, as long as 
they implement method X() (see this example[0]).

In the end though you are right, while we can improve compiler checks 
here and there, adding type safety would not only require quite an 
overhaul of the compiler, but it would be a breaking change to the 
language (between duck typing, dynamic symbol loading, or even the 
_unknown() special method which I completely forgot about).

Maybe in 10 years for Gambas 4 ? /s :-)

[0] 
https://gambas-playground.proko.eu/?gist=08f2c60469e876eeacc75d1d2ff935e8

-- 
Adrien Prokopowicz