{"id":122,"date":"2009-02-23T22:30:48","date_gmt":"2009-02-23T20:30:48","guid":{"rendered":"http:\/\/www.coolbasic.com\/blog\/?p=122"},"modified":"2009-02-23T22:30:48","modified_gmt":"2009-02-23T20:30:48","slug":"name-resolution","status":"publish","type":"post","link":"https:\/\/www.coolbasic.com\/blog\/2009\/02\/23\/name-resolution\/","title":{"rendered":"Name Resolution"},"content":{"rendered":"<p>So I thought that I&#8217;d get an easy start to Pass#2 by first developing the constant value pre-calculator. It seemed like a logical thing to do for starters because those pre-evaluated values will be needed in the actual compilation of executing code. So I started writing a procedure that iterates all constants from the symbol table, and then calculates their values. I had all these circular reference algorithms planned out and so on. But of course surprises do happen (actually I should have seen this coming from a mile away), and I figured that before I can implement this fancy stuff, there are a few other things to take care of.<\/p>\n<p>Wait, isn&#8217;t that the same precise thing I experienced in the beginning of Pass#1&#8230; oh, umm.. Yes it is! Back in Pass#1, I was hoping to get an easy start with simple statements such as Repeat&#8230;Until. But there&#8217;s no such thing as free lunch; I had to write the containing elements first (d&#8217;oh, of course!). Those being classes, functions and so on. On top of that, those statements just happened to be the most complicated ones, so plenty of general-purpose parsers needed to be written, too. So Pass#1 was quite frontloaded instead of backloaded a burden to chew on. As I&#8217;ve written in previous blog entries, the ending of Pass#1 went relatively quickly, and was just a copy-paste fest for the most part.<\/p>\n<p>So what&#8217;s the frontload here in Pass#2? Well, even though you now got your pretty symbol table and the source code on a silver platter, you will still need to solve the identifier name references correctly because constant expressions can have constant identifiers in them. These references couldn&#8217;t be made in Pass#1 because identifiers can be declared in random order. Sooo&#8230; now you find yourself together with Mr. Name Resolution. Oh, and also, please meet his brother Mr. Overload Resolver. Oh, and don&#8217;t forget their sister, Ms. Template Expander. Whoah, so I suddenly have these 3, mean looking procedures on my face &#8211; right from the start. I&#8217;m not kidding, these are probably THE 3 <em>most<\/em> difficult entities for Pass#2. And again, they <em>must<\/em> be almost completely implemented before proceeding onto further tasks. Okey, the Template Expander can wait a little bit. I can probably get this pre-calculator to work correctly on *simple code* with just the Name Resolution algorithm implemented, but the 2 remaining villains need to be taken care of soon after. <\/p>\n<p>Name Resolution is essentially the process of matching source code identifier names to their actual declaration. An identifier can be located in some of the upper levels or in a completely different branch within the program hierarchy. When the identifier reference is being resolved, also the access modifiers are taken into account. All this follows a specific rule-set of the OOP member accessing. Basically, an entity always has access to upper levels, but requires Public access for branches. Inherited class-based reference to base classes can also have Protected access. Combine these to overloading, shadowing (hiding by name) and procedure overriding (hiding by name and signature), and you got yourself a nice little soup. But these are my problems anyways \ud83d\ude42<\/p>\n<p>I have formulated algorithms for both constant expression calculation and name resolution, and I expect to carry them out during the up-coming weeks. The pre-calculator will be a big chunk of code. At this point in development, things get really interesting (and challenging).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>So I thought that I&#8217;d get an easy start to Pass#2 by first developing the constant value pre-calculator. It seemed like a logical thing to do for starters because those pre-evaluated values will be needed in the actual compilation of executing code. So I started writing a procedure that iterates all constants from the symbol [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[5,8],"_links":{"self":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts\/122"}],"collection":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/comments?post=122"}],"version-history":[{"count":0,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts\/122\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/categories?post=122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/tags?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}