Sounds fine to me.
I'm still on vacation here, with a huge snow storm, so my day is going
to consist of moving snow and clearing driveways.
I might do that refactor later, but I'm not sure today. :)
Mike
Quoting Erik de Bruin <e...@ixsoftware.nl>:
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
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
