assets/developer-notes/stephanie-gawroriski/2017/09/04.mkd

   1 # 2017/09/04
   2
   3 ## 00:36
   4
   5 I do not believe anything has to be done at the end of an instruction within a
   6 basic block at all. Just need to parse the instructions. Only some
   7 instructions will require an actual check and handling be performed for stuff
   8 such as exceptions.
   9
  10 ## 00:48
  11
  12 Ok so `invokespecial` when a constructor is called will do some things since
  13 many different scenarios could occur. But I think the basic scenario would
  14 work the same for the most part. It can just set the specified object as
  15 initialized via its key and that is it for the most part.
  16
  17 ## 04:12
  18
  19 `invokespecial` will be a bit complex to handle because it is not known if the
  20 class is a super class of the current class. Basically it will be the same as
  21 a normal invoke but the target method (which could throw an exception). So due
  22 to this nature, my handling of whatever method that is invoked must be
  23 deferred. The thrown exception `AbstractMethodError` is not part of the
  24 generated code, it is a compile/link time failure. So I do not need to worry
  25 about that. If the conditions fail at link time then nothing can be linked.
  26
  27 ## 12:08
  28
  29 I think I will take a short break and work on JavaDoc. I am pretty sure I know
  30 of a better way to generate documentation and such. Basically I will just use
  31 the host build system that runs on JavaSE to do this with perhaps a bump for
  32 something SquirrelJME specific so it can run on itself. Maybe just allow for
  33 a JavaDoc option to exist also.
  34
  35 ## 12:14
  36
  37 `DocumentationTool` does not exist in Java 7 though, so it will need to be
  38 wrapped by a virtual interface so that it works properly.
  39
  40 ## 12:18
  41
  42 I think what is needed is a refactor of the documentation setup. But actually
  43 I could in reality just write my own Java source parser and have something
  44 that can describe anything in the source code. I could later use it with the
  45 compiler and such. I would not actually need to compile anything at all, it
  46 would just describe source code with JavaDoc comments and such. Then from the
  47 result of that parse I can have far better control as to how documentation
  48 is generated to something that I like with a more sane interface. Currently
  49 the Sun doclet API is really messy and a bit confusing for things. But the
  50 base structure parser could be used as a basis for a compiler in the future.
  51
  52 ## 12:23
  53
  54 It would definitely provide a much better result and would be much more
  55 inituitive. Also the documentation tool would work on SquirrelJME also so
  56 there is that bonus. I can build a system that is built into my package
  57 manager. Currently right now, implementing any kind of documentation tool
  58 would be ugly because the `DocumentationTool` seems to have been an
  59 afterthought, so a bit messy.
  60
  61 ## 12:55
  62
  63 The class structure will need a means to obtain dependent classes or source
  64 code files which may reside within different units. So for example, to
  65 generate the documentation properly, dependencies will need to be parsed
  66 and handled accordingly. However there may be cases where compilation fails
  67 at which point it is unknown how the documentation will be valid or invalid.
  68 One big thing is structure and how it all goes together. I could make the
  69 documentation tool I have work for the most part solely on source code files
  70 for now. But I think I should build a project first then if it compiles
  71 properly, I will then generate documentation for it. I could have a global
  72 link of structures though so that parsed source code can easily be referred
  73 to by other locations. So I would say that the documentation tool would
  74 depend on projects. But in reality I do not actually need to compile anything,
  75 just parse the code and build structure. I do however need to know
  76 dependencies because they could vary.
  77
  78 ## 13:13
  79
  80 Ok, a major problem I will have is with generics. Generics are context
  81 sensitive. But I think I can not worry about it at all. I will probably very
  82 much not have to worry about it because the operators before provide the
  83 context. I will know if I am inside of a method or not. If I am outside of
  84 anything that is code then there will never be operators used. If I am ever
  85 within code then generic method calls will always be preceded by a period. So
  86 this makes things easier.
  87
  88 ## 13:15
  89
  90 At least initially I will work on the tokenizer first to see how well it
  91 works. Then after that I will make a basic class structure which just
  92 describes what the class feels like without actually knowing anything about
  93 any other class. Then I will work my way from there.
  94
  95 ## 13:16
  96
  97 But the main thing I will need to consider are casts. Luckily in Java all
  98 casts are in parenthesis. So stuff like `short(12)` is not a possibility.
  99
 100 ## 13:22
 101
 102 Also unlike C, Java does not have swapped array handling like `12[boop]`. So
 103 I think from the surrounding context it is possible to determine what exactly
 104 a token represents. So as long as I know what I am tokenizing I can determine
 105 the rules used.
 106
 107 ## 13:55
 108
 109 Never knew about the multiple `u`s in the escape sequences. This means you can
 110 hide files within Java source code and still have it compile.
 111