1
edit
Changes
no edit summary
* In [https://processing-js.lighthouseapp.com/projects/41284/tickets/664-remove-this-from-parsed-class-variables-and-go-with-thisgettersetter 664] what I'm doing is taking what I learned from [https://processing-js.lighthouseapp.com/projects/41284/tickets/232-test-removal-of-with-p removing with] and improving what was done ages ago with the first with removal, which I hope can also solve my inheritance problems, which currently has three open tickets for inheritance [https://processing-js.lighthouseapp.com/projects/41284/tickets/554-override-not-working-as-expected 554] [https://processing-js.lighthouseapp.com/projects/41284/tickets/643-inheritance-problems-with-variables 643] and [https://processing-js.lighthouseapp.com/projects/41284/tickets/641-bug-in-the-handling-of-polymorphism-08-09 647] These all are very specific examples, but the problem is more general, and I hope by rewriting class parsing in this way, I can get inheritance just right, including super() and super. methods, which I'm going to solve by creating a super object within the scope of the sub class, and it'll be a copy of the base class, so by calling super.variableName, it will work without having to parse super., or without having to create a super function. Also static will need to be rewritten.
* I actually got very far on my class rewrite, and hope to have the first draft for peer review some time tomorrow after an evening of testing.
Saturday May 22nd<br />
* Continued work on [https://processing-js.lighthouseapp.com/projects/41284/tickets/664-remove-this-from-parsed-class-variables-and-go-with-thisgettersetter 664] and got quite far, removing about 90 lines of code, but there is a hude problem. I lose control of inheritance. I need to, at the time a function is created, control which class, child or parent, uses it. I do this by using this. for functions, and public. for variables. This will call the parent variable, as public is a frozen copy of this refering to the class that crated it, and this.'s meaning changes when it is called, refering to the current class that is calling it, most likely the child. No way I can remove this functionality and keep the specifics of inheritance. I have decided to better spend my time working on perfecting inheritance.
* Started work on [https://processing-js.lighthouseapp.com/projects/41284/tickets/643-inheritance-problems-with-variables inheritance].
* The main things I want to accomplish is super() constructor calls, super. variable calls, and functions and variables called from their proper parent/child.
* Got an initial trial patch, and got Pomax, a user from irc to break it, which he did, pointing out that inheritance can have infinite levels in the tree, and I only accounted for two. Back to the drawing board.
Sunday May 23rd<br />
* I created an inheritance tree. I already keep an array of objects, one for each class, and add classes to it as I go. The class contains a name property, a string of variables names, seperated by a | and an array of function names. In order for multiple inheritance to work, I must continue to add all parent properties to the list of the child, and keep adding as a new child is found. This is recursive and works wonders while testing the values, but the example Pomax sent me isn't quite right.
* super() constructors, I've decided to keep a local object inside the child called super, which will be an instance of the parent. allowing calls like super. to not need any parsing, as they will just refer to the super object. Perfect. One problem, super() is not how you call constructors in JavaScript. I need to parse that into "super = new className();" Passing in any possible parameters. I must do this inside the constructors, and if there is no constructors, a default super constructor call is implied.
* Filed [https://processing-js.lighthouseapp.com/projects/41284/tickets/614-syntax-parsing-error-with-void-setup ticket 614] as a duplicate.
* Resolved [https://processing-js.lighthouseapp.com/projects/41284/tickets/102-move-functions-outside-of-buildprocessing-so-they-can-be-re-used ticket 102].
* Resolved [https://processing-js.lighthouseapp.com/projects/41284/tickets/553-constructor-odd-behavior-mistakes-on-parsing-but-java-parser-is-fine ticket 553].
Monday May 24th<br />
Tuesday May 25th<br />
* Did some finishing touches to [https://processing-js.lighthouseapp.com/projects/41284/tickets/643-inheritance-problems-with-variables inheritance], and Pomax was not able to break my patch, submitted it for review that afternoon.
* Had a meeting with Dave about my progress.
* I did some further research on my tickets, to assess how possible, and difficult they would be, and started to think and test solutions for some of the more difficult ones, like [https://processing-js.lighthouseapp.com/projects/41284/tickets/671-using-this-for-constructors 671], [https://processing-js.lighthouseapp.com/projects/41284/tickets/642-name-of-parameters-in-constructor-cause-collisions-in-the-class-methods 642], [https://processing-js.lighthouseapp.com/projects/41284/tickets/648-using-class-variables-outside-ctor-and-functions-doesnt-exist 648] and [https://processing-js.lighthouseapp.com/projects/41284/tickets/648-using-class-variables-outside-ctor-and-functions-doesnt-exist 648].
Wednesday May 26th<br />
Thursday May 27th<br />
Friday May 28th<br />