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

[Jussi Lahtinen]

Thanks for the explanation. I was aware that type checking wouldn't
guarantee type safety, but it would allow faster way to catch some bugs. I
think it would have to be optional like in TypeScript, because as you
pointed out someone may want to use the automatic conversion (or casting).
And sometimes it really is useful, sometimes only confusing.


Jussi

On Thu, Feb 15, 2018 at 2:58 AM, Tobias Boege <taboege at gmail.com> wrote:

> 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
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
>
> --------------------------------------------------
>
> This is the Gambas Mailing List:
> https://lists.gambas-basic.org/listinfo/user
>
> Search the list:
> https://lists.gambas-basic.org/cgi-bin/search.cgi
>
> Hosted by https://www.hostsharing.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180215/a0d93044/attachment-0001.html>