Comprobando el tipo de variables al crear DSLs

Extracto de la transcripción automática del vídeo realizada por YouTube.

so today we are going to talk again about static type checking yesterday we sing then groovy too we introduced type checking which is optional but we also saw that there were limitations to type checking limitations because the language the groovy language

is a dynamic language you can have scripts you can extend for example discrete class just to have default variables in your scripts or use the binding to have variables in your scripts and groovy is a platform of choice for thai checking from sorry phone dsl's

and a lot of people use groovy as a dsl development platform more than just a language because it's really easy to have a DSL which runs without having to deal with the custom parser for example okay so here we will see that in which one so to just brand

new version of groovy you have tools that will allow you to plug into the type checker and add your custom type checking rules or I would say you can do more than just type checking you can add custom checks and you can somehow hot groovy used as a tool to

have static code analysis directly into the compliation system so because the the rest of the talk is really technical I'm going to skip this spot really fast so this is just what we saw yesterday but basically what's the problem with type checking

dsl's the problem is that a dsl is specific so it's focused readable this is really important to know that a dsl is meant to be readable by humans machines we don't care about machines we can have passes okay readable and battle and just let me

know how many people use on thing they use groovy as a platform of 4G assaults in that room okay how many of you use gradall okay so you use these cells how many people use sequel queries everybody use sequel sequel is an example of a DSL which is really focused

and we could want to have type checking on sequel why not the problem with type-checking dsl's is that the implementation of gsl is very different from one project to another you have many choices in groovy to implement your dsl you can use runtime metaprogramming

compile-time metaprogramming you can have groovy shell running shell scripts you can extend the script you can do really a lot of things to infinity dsl and the type checker is really not aware about the implementation of your script another point is why it's

really important question because this cut this talk is about that why would you want to type check deserts anyone has an idea what you would want to do that okay so you don't know why you're in this session in fact i can give you hints in the past

i was working for another company and we were using ruby as a platform for dsl the problem is that the users of the dsl were not programmers there are people who used computers as tools and we gave them a DSL the roads dsl they were indeed writing code but

they didn't know they were using code and you can't really ask those people to write unit tests if you look at you like this you need what they don't know what the unit test is and you don't want to have that code in projection with something

that can break a prediction you want it to fail earlier so the idea behind diesel type checking is to fail early for the SS to we can fail early this static type checking for programmer code this is comfort zone you won't fail early at compile time and

for users of these cells you want to fail early to protect yourself from having bad code introduction ok so this is an example of a DSL please show me the code in Ruby this is equivalent to having this construct and now I want to type check this so I can do

this like that i can write my dsl like that I'm using for example get code to use the dots code probably notation I'm returning an instance of dsl I have an enum okay and if i run my dsl it works the question behind this is is this a good way to implement

the dsl i don't think so you don't want to implement your dsl in a way that allows the type checker to type check it it's a bit bizarre to do that okay you don't have to be forced to use an implementation just because you want it to pass type

checking just not the way to do that so type checking should not drive your implementation you should not have to use custom brothers to your scripts for example to be able to I load actually my wrappers I mean you can have scripts that just modify the dsl

at run time before it is compiled for example you know something that would add some lines in your code or change some tokens the problem with that is that when you have a user error the line numbers for example that correspond to what you have in the code

so you wouldn't be able to debug your code and last an important thing is that it should be easy it's not as easy as I would like it to be yet it's easier now to do that because just before it was an impossible task so the first option we have

to a low type checking in the dsl is to use delegates to give this for example the market builder in groovy everyone uses a buildin groovy at some point a builder is some kind of dsl we have new market builder and use HTML p div etc and this is a dsl if you

[ ... ]

Nota: se han omitido las otras 2.470 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.