My day is really nearly over, so I won't do anything but dig around a
bit more to get more 'into' the code. So you go ahead with your todo,
please.
Once I've figured out what I can do and how I should do it, I'll
notify you to see if we're in a state to receive my efforts.
Ok?
EdB
On Thu, Dec 27, 2012 at 3:09 PM, Michael Schmalle
<apa...@teotigraphix.com> wrote:
>
> Quoting Erik de Bruin <e...@ixsoftware.nl>:
>
>> Excellent.
>>
>> Mike, question: can we somehow separate out the 'goog' specific code
>> some more? Just wondering... If someone wants to start a different
>> parsing for JS, it might be less work to separate out 'goog' entirely
>> at this point than try and do that only when the need arises. I was
>> thinking about the JSDocEmitter, which can do with an extra layer of
>> abstraction, I think. And some code in JSEmitter is also 'goog'
>> specific. As this requires 'some' refactoring, I'm hesitant to start
>> without consulting with you first ;-)
>
>
> Actually, the intent was that the JSEmitter holds all code that is universal
> to JS.
>
> You are seeing reminiscence of goog because I haven't taken it all out yet
> with the refactors.
>
> So, goog needs to be completely ripped out of the JSEmitter. I really don't
> think we need another layer, since if you take out the goog stuff from
> JSEmitter like I was going to do, you already have that layer in the
> JSGoogEmitter.
>
> Does this make sense?
>
> The jsdoc emitter is the same, I need an injection point to give the emitter
> an instance of it from the backend implementation. Probably need an
> interface like IDocEmitter the IJSGoogEmitter extends.
>
> Anyway, what do you want to do, because that is to close of quarters for me
> to work today if you are refactoring the JSEmitter.
>
> Mike
>
>
>
>
>
>> EdB
>>
>>
>> On Thu, Dec 27, 2012 at 2:21 PM, Michael Schmalle
>> <apa...@teotigraphix.com> wrote:
>>>
>>> Looks good Erik!
>>>
>>> Welcome to the party. Like I said, lets try to communicate what we are
>>> working on so we aren't creating merge conflicts, I hate those.
>>>
>>> Not much I would have done differently. Just 1 thing;
>>>
>>> Pay special attention to indents a newlines.
>>>
>>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>>
>>> return p1 + p2 + p3 + p4;
>>> }
>>>
>>>
>>> should probably be;
>>>
>>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>> return p1 + p2 + p3 + p4;
>>> }
>>>
>>> Without the newline to keep the code generation consistent. How would I
>>> get
>>> it to work? ...svn update :)
>>>
>>> Check out my last commit 5 minutes ago. If you are confused why and what
>>> I
>>> did ask.
>>>
>>> PS For block headers, there is a special handling of indents with no body
>>> code AST.
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>> Quoting Erik de Bruin <e...@ixsoftware.nl>:
>>>
>>>> Mike,
>>>>
>>>> I've implemented and committed an alternative way of handling default
>>>> parameter values, including a test. Not particularly to make my point
>>>> with regard to which we should use (if we have to chose at all), but
>>>> mostly to see how I can contribute from my end.
>>>>
>>>> Please let me know how I did and what you would like me to do
>>>> differently. Thanks.
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
>>>> <apa...@teotigraphix.com> wrote:
>>>>>
>>>>>
>>>>> Hey,
>>>>>
>>>>> I have no plans other than to keep trudging away. There is still a lot
>>>>> of
>>>>> work to be done.
>>>>>
>>>>> As far as moving to the falcon repo, I don't want to do that yet. You
>>>>> are
>>>>> more than welcome to commit code where it is (just happens to be in my
>>>>> whiteboard).
>>>>>
>>>>> Did you notice what I did to implement the parameters? If you havn't,
>>>>> you
>>>>> might want to take a look at the commit and diffs.
>>>>>
>>>>> The object is to NOT comment out or override anything in the
>>>>> ASBlockWalker.
>>>>> I refactored that parameter code to the base ASEmitter, added API and
>>>>> then
>>>>> overrode the method in JSGoogEmitter. Get it?
>>>>>
>>>>> Also did a trick to allow a hook into the beginning of a function block
>>>>> to
>>>>> inject code. We can do that anywhere it's needed, I don't see a lot of
>>>>> situations like that though.
>>>>>
>>>>> Rules are, you change something before you commit ALL unit tests must
>>>>> pass,
>>>>> how ever you changed code.
>>>>>
>>>>> This is exactly why I want it in the whiteboard still, I don't want
>>>>> people
>>>>> looking at it in falcon "thinking" something that it is not yet.
>>>>>
>>>>> PS You should post a thread here what you are currently working on so I
>>>>> don't step on your feet.
>>>>>
>>>>> Oh yeah, I have had plenty of out of body experiences through the years
>>>>> gazing at parser and compiler code, so I know exactly what you are
>>>>> talking
>>>>> about, I guess in current times, it's the light bulb going off. :)
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> Quoting Erik de Bruin <e...@ixsoftware.nl>:
>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> I've spent some time with the js.codegen this week... Nietzsche was
>>>>>> right: "Battle not with monsters lest ye become a monster; and if you
>>>>>> gaze into the abyss the abyss gazes into you." Having said that, I
>>>>>> think I might be ready to contribute to that part of FalconJx.
>>>>>>
>>>>>> What are your plans (moving the project to the falcon/ repo so 'the
>>>>>> public' can commit; refactoring, etc.)?
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ix Multimedia Software
>>>>>>
>>>>>> Jan Luykenstraat 27
>>>>>> 3521 VB Utrecht
>>>>>>
>>>>>> T. 06-51952295
>>>>>> I. www.ixsoftware.nl
>>>>>>
>>>>>
>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
