librelist archives

home // archives //

« back to archive

Pull request

Pull request

From:
Robert Plummer
Date:
2012-04-30 @ 14:42 
Hey Zach,
I updated the php port of jison to support the code modifications found in
jison 0.3.6 and updated the pull request to that.  I'm wondering, I haven't
had any email from you about the changes in Jison for extendibility using
the jQuery.extend method.  Did you have any objections to adding it?  In
short what it allows us to do is this:

if we create a jison parser called 'parser' a function is created called
parserFactory() but it immediately creates a parser variable called
'parser' just as it did before so there is no change to default behaviour.
But the parserFactory function now allows for extendibility if jQuery is
present.  This cuts down on complexity when integrating with the parser,
example:

{CODE()}
//jison parser already present before this line

var parserExtensions = {
  myParserMethod: function() {}
};

var lexerExtensions = {
  myLexerMethod: function() {}
};

var extendedParser = parserFactory(parserExtensions,lexerExtensions);

extendedParser.parse('');
{CODE}

Inside the parser you can access these methods using
parser.myParserMethod();, parser.lexer.myLexerMethod();, or (when present)
lexer.myLexerMethod();.


The php equivalent port allows you to extend using derived classes through
'extend' and because the php equivalent has both the parser and lexer in
the same class, you can proceed with basically the same code above and do
this (which is even easier):

{CODE()}
class extendedParser extends parser
{
  function myParserMethod() {}
  function myLexerMethod() {}
}

$extendedParser = new extendedParser();

$extendedParser->parse('');
{CODE}


Inside the parser the php allows you to access these methods using $this
rather than parser variable.  So:

{CODE()}
//javascript
parser.myParserMethod(); //js
parser.lexer.myLexerMethod(); //js
lexer.myLexerMethod(); //js
{CODE}

Becomes:
{CODE()}
$this->myParserMethod(); //php
$this->myLexerMethod(); //php
{CODE}

Anyway I just thought you'd like to see what I have been working on to make
jison better.  Let me know what you think.
-- 
Robert Plummer

Re: [jison] Pull request

From:
Zachary Carter
Date:
2012-04-30 @ 21:46 
Hey Robert,

There were a couple of objections I had with it. For traditional
script loading in the browser, I would rather not create more than one
global variable, so I'd prefer an additional method on the parser
object (e.g. parser.factory()) over a new global. For module loaders
it would be an additional method on the module.

Additionally, I'd prefer not to hardcode a jQuery dependency for a
function that could probably be inlined if necessary. But I'm not
convinced there's a need to include an extension method, since you
could easily do

    var extendedParser = jQuery.extend(parser.factory(),
parserExtensions, lexerExtensions));

if you really wanted to (once there is a factory method) without
losing much brevity. Or substitute jQuery.extend for your preferred
object extension method. The jison code remains smaller and the
developer retains flexibility. With PHP you have built-in classes, so
it's a bit different (technically and philosophically.)

I do agree there needs to be a factory-like method though, and have
been meaning to include one.

On Mon, Apr 30, 2012 at 10:42 AM, Robert Plummer
<robertleeplummerjr@gmail.com> wrote:
> Hey Zach,
> I updated the php port of jison to support the code modifications found in
> jison 0.3.6 and updated the pull request to that.  I'm wondering, I haven't
> had any email from you about the changes in Jison for extendibility using
> the jQuery.extend method.  Did you have any objections to adding it?  In
> short what it allows us to do is this:
>
> if we create a jison parser called 'parser' a function is created called
> parserFactory() but it immediately creates a parser variable called 'parser'
> just as it did before so there is no change to default behaviour.  But the
> parserFactory function now allows for extendibility if jQuery is present.
> This cuts down on complexity when integrating with the parser, example:
>
> {CODE()}
> //jison parser already present before this line
>
> var parserExtensions = {
>   myParserMethod: function() {}
> };
>
> var lexerExtensions = {
>   myLexerMethod: function() {}
> };
>
> var extendedParser = parserFactory(parserExtensions,lexerExtensions);
>
> extendedParser.parse('');
> {CODE}
>
> Inside the parser you can access these methods using
> parser.myParserMethod();, parser.lexer.myLexerMethod();, or (when present)
> lexer.myLexerMethod();.
>
>
> The php equivalent port allows you to extend using derived classes through
> 'extend' and because the php equivalent has both the parser and lexer in the
> same class, you can proceed with basically the same code above and do this
> (which is even easier):
>
> {CODE()}
> class extendedParser extends parser
> {
>   function myParserMethod() {}
>   function myLexerMethod() {}
> }
>
> $extendedParser = new extendedParser();
>
> $extendedParser->parse('');
> {CODE}
>
>
> Inside the parser the php allows you to access these methods using $this
> rather than parser variable.  So:
>
> {CODE()}
> //javascript
> parser.myParserMethod(); //js
> parser.lexer.myLexerMethod(); //js
> lexer.myLexerMethod(); //js
> {CODE}
>
> Becomes:
> {CODE()}
> $this->myParserMethod(); //php
> $this->myLexerMethod(); //php
> {CODE}
>
> Anyway I just thought you'd like to see what I have been working on to make
> jison better.  Let me know what you think.
> --
> Robert Plummer



-- 
Zach Carter

Re: [jison] Pull request

From:
Robert Plummer
Date:
2012-04-30 @ 21:54 
The extending way you do doesn't work inside the parser because it is the
wrong scope, unless you can show me.

On Mon, Apr 30, 2012 at 5:46 PM, Zachary Carter <zack.carter@gmail.com>wrote:

> Hey Robert,
>
> There were a couple of objections I had with it. For traditional
> script loading in the browser, I would rather not create more than one
> global variable, so I'd prefer an additional method on the parser
> object (e.g. parser.factory()) over a new global. For module loaders
> it would be an additional method on the module.
>
> Additionally, I'd prefer not to hardcode a jQuery dependency for a
> function that could probably be inlined if necessary. But I'm not
> convinced there's a need to include an extension method, since you
> could easily do
>
>    var extendedParser = jQuery.extend(parser.factory(),
> parserExtensions, lexerExtensions));
>
> if you really wanted to (once there is a factory method) without
> losing much brevity. Or substitute jQuery.extend for your preferred
> object extension method. The jison code remains smaller and the
> developer retains flexibility. With PHP you have built-in classes, so
> it's a bit different (technically and philosophically.)
>
> I do agree there needs to be a factory-like method though, and have
> been meaning to include one.
>
> On Mon, Apr 30, 2012 at 10:42 AM, Robert Plummer
> <robertleeplummerjr@gmail.com> wrote:
> > Hey Zach,
> > I updated the php port of jison to support the code modifications found
> in
> > jison 0.3.6 and updated the pull request to that.  I'm wondering, I
> haven't
> > had any email from you about the changes in Jison for extendibility using
> > the jQuery.extend method.  Did you have any objections to adding it?  In
> > short what it allows us to do is this:
> >
> > if we create a jison parser called 'parser' a function is created called
> > parserFactory() but it immediately creates a parser variable called
> 'parser'
> > just as it did before so there is no change to default behaviour.  But
> the
> > parserFactory function now allows for extendibility if jQuery is present.
> > This cuts down on complexity when integrating with the parser, example:
> >
> > {CODE()}
> > //jison parser already present before this line
> >
> > var parserExtensions = {
> >   myParserMethod: function() {}
> > };
> >
> > var lexerExtensions = {
> >   myLexerMethod: function() {}
> > };
> >
> > var extendedParser = parserFactory(parserExtensions,lexerExtensions);
> >
> > extendedParser.parse('');
> > {CODE}
> >
> > Inside the parser you can access these methods using
> > parser.myParserMethod();, parser.lexer.myLexerMethod();, or (when
> present)
> > lexer.myLexerMethod();.
> >
> >
> > The php equivalent port allows you to extend using derived classes
> through
> > 'extend' and because the php equivalent has both the parser and lexer in
> the
> > same class, you can proceed with basically the same code above and do
> this
> > (which is even easier):
> >
> > {CODE()}
> > class extendedParser extends parser
> > {
> >   function myParserMethod() {}
> >   function myLexerMethod() {}
> > }
> >
> > $extendedParser = new extendedParser();
> >
> > $extendedParser->parse('');
> > {CODE}
> >
> >
> > Inside the parser the php allows you to access these methods using $this
> > rather than parser variable.  So:
> >
> > {CODE()}
> > //javascript
> > parser.myParserMethod(); //js
> > parser.lexer.myLexerMethod(); //js
> > lexer.myLexerMethod(); //js
> > {CODE}
> >
> > Becomes:
> > {CODE()}
> > $this->myParserMethod(); //php
> > $this->myLexerMethod(); //php
> > {CODE}
> >
> > Anyway I just thought you'd like to see what I have been working on to
> make
> > jison better.  Let me know what you think.
> > --
> > Robert Plummer
>
>
>
> --
> Zach Carter
>



-- 
Robert Plummer

Re: [jison] Pull request

From:
Zachary Carter
Date:
2012-04-30 @ 22:21 
On Mon, Apr 30, 2012 at 5:54 PM, Robert Plummer
<robertleeplummerjr@gmail.com> wrote:
> The extending way you do doesn't work inside the parser because it is the
> wrong scope, unless you can show me.
>

Ah, if you just want to expose methods to your semantic actions you
can extend the `parser.yy` property and they will be available within
parser and lexer actions on the `yy` local variable, e.g.
`yy.myParserMethod` or `yy.myLexerMethod`.

-- 
Zach Carter

Re: [jison] Pull request

From:
Robert Plummer
Date:
2012-04-30 @ 23:36 
What if we just iterate through the object sent from the extending
variables and drop the need for jQuery, would you be open to that?

On Mon, Apr 30, 2012 at 6:21 PM, Zachary Carter <zack.carter@gmail.com>wrote:

> On Mon, Apr 30, 2012 at 5:54 PM, Robert Plummer
> <robertleeplummerjr@gmail.com> wrote:
> > The extending way you do doesn't work inside the parser because it is the
> > wrong scope, unless you can show me.
> >
>
> Ah, if you just want to expose methods to your semantic actions you
> can extend the `parser.yy` property and they will be available within
> parser and lexer actions on the `yy` local variable, e.g.
> `yy.myParserMethod` or `yy.myLexerMethod`.
>
> --
> Zach Carter
>



-- 
Robert Plummer

Re: [jison] Pull request

From:
Robert Plummer
Date:
2012-05-01 @ 19:13 
I went ahead and tested, committed, and updated the pull request to remove
jQuery extend and use a simple for(){}.  I think this is a good mix of
having a factory and being able to extend easily.  What do you think?

On Mon, Apr 30, 2012 at 7:36 PM, Robert Plummer <
robertleeplummerjr@gmail.com> wrote:

> What if we just iterate through the object sent from the extending
> variables and drop the need for jQuery, would you be open to that?
>
>
> On Mon, Apr 30, 2012 at 6:21 PM, Zachary Carter <zack.carter@gmail.com>wrote:
>
>> On Mon, Apr 30, 2012 at 5:54 PM, Robert Plummer
>> <robertleeplummerjr@gmail.com> wrote:
>> > The extending way you do doesn't work inside the parser because it is
>> the
>> > wrong scope, unless you can show me.
>> >
>>
>> Ah, if you just want to expose methods to your semantic actions you
>> can extend the `parser.yy` property and they will be available within
>> parser and lexer actions on the `yy` local variable, e.g.
>> `yy.myParserMethod` or `yy.myLexerMethod`.
>>
>> --
>> Zach Carter
>>
>
>
>
> --
> Robert Plummer
>



-- 
Robert Plummer

Archives based on code by Armin Ronacher //