Implementation rules

[metal3d]

Hi,
Working on Go implementation, I checked other languages implementation to follow rules.

This is difficult for us... To my side I switch in Cpp and Python implementation + yours (javascript, that is not in organization list) to understand what to implement.

For example, "multiple" method is not easy to understand reading JS and PHP implementations wich makes something very different.

BTW I guess multiple implementation is not "as it should be"...

Is it possible to create a repo where we can work on implementation doc ?

[mihai-vlc]

When an idea involves documentation it's always a good one.
i have made a repo here https://github.com/VerbalExpressions/implementation
i will try to help in the weekend.

[metal3d]

Good news :) thanks

[maurodec]

@metal3d I'm working (actually finished like a week ago) a Go implementation , but haven't got around to publishing it. Maybe we should compare what we came up with and merge them.

[metal3d]

UPDATE: I've found you implementation, I take a look
@maurodec That can be nice. But if you checked my implementation you'll see that it's 99% finished :) I only have to implement stopAtFirst method.
But, I'm interessed to read your implementation.
Another approach, you can create a fork of my repository and try to merge, fix, etc... Then send a pull request. That simpler for me. Anyway, send me your code in a gist, mail, MP... I'll check as soon as I get it.

[metal3d]

@maurodec I'm currently appending some of your code. Can you please fork repo and continue ? I will merge your pull requests. But keep in mind that I will modify code in 10 hours with your good methods. I will add contributors file to list authors too.

[maurodec]

@metal3d
While I think VerbalExpressions is an awesome library, I don't like how some of the stuff has been implemented. I will continue to develop my port but changing the functionality to what I think is better. When I ported the JS code I didn't just rewrite it, I actually made some improvements along the way as well as fixed what I felt were bugs. Some of the behavior in my repo is actually different from the original VerbalExpressions.

I encourage everyone to fork and modify what I did (and will continue doing) as well as merge come of my code into their own, but keep in mind that the expected behavior may be different.

Thinking about it, maybe I should rename my repository.

[crawfordcomeaux]

@maurodec
There's definitely room for improvement in the original, as well as expansion on it for languages with more robust regex libs. 

Can you discuss your implementation's behavior and maybe even how it differs from the original?

On Fri, Aug 9, 2013 at 7:17 PM, Mauro de Carvalho
notifications@github.com wrote:

@metal3d
While I think VerbalExpressions is an awesome library, I don't like how some of the stuff has been implemented. I will continue to develop my port but changing the functionality to what I think is better. When I ported the JS code I didn't just rewrite it, I actually made some improvements along the way as well as fixed what I felt were bugs. Some of the behavior in my repo is actually different from the original VerbalExpressions.
I encourage everyone to fork and modify what I did (and will continue doing) as well as merge come of my code into their own, but keep in mind that the expected behavior may be different.

Thinking about it, maybe I should rename my repository.

Reply to this email directly or view it on GitHub:
#39 (comment)

[metal3d]

@maurodec I did improvements too... As example the "Multiple" method I did as different implementation than JSlib and I've written "to discuss" in "implementation" repository.

Looking at your implementation, there was some bugs but you've got nice ideas (for example, the part I ported from your code to get Flags is very interessing). I really don't understand why you want to do your "port" externally of our. I have to test your implementation, and work a lot to integrate your parts... If you do a "new" fork, that will be simpler for us .

To encourage other to fork yours is just a pitty... instead of working together on a only one implementation, you let us working on a port, and other to work on yours... and both have to work on port integrations...

If you don't like some parts of VerbalExpression, you can participate on "implementation" repository to discuss about improvements... That's just why @ionutvmi did this repo.

The idea is that we work together...

And to be clear, check issues I've open on Go port... the whole issues say that I have to port your improvements in project.

You'd rather fork our repo, give pull request, and create branches for improvement we can discuss. That will be more efficient.

[maurodec]

I definitely think collaborating instead of forking is the way to go, the problem I have is with the word "port". IMHO, if the behavior is even slightly different, it should be considered a port.

I will fork your repo and make all my changes there and create pull requests, however, I think this is not the best way of working. I think if they are ports, then behavior must be consistent.

IMHO the best way of working would be to have a repo just with documentation specifying exactly what each function does and a bunch of test cases, then have all "ports" implement those operation the way they like, but keeping behavior consistent.

[metal3d]

I think you should look the "implementation" repo done to specify what
you're defining. I will continue my answer in 1h. I'm out at the moment.
Le 10 août 2013 15:16, "Mauro de Carvalho" notifications@github.com a
écrit :

I definitely think collaborating instead of forking is the way to go, the
problem I have is with the word "port". IMHO, if the behavior is even
slightly different, it should be considered a port.

I will fork your repo and make all my changes there and create pull
requests, however, I think this is not the best way of working. I think if
they are ports, then behavior must be consistent.

IMHO the best way of working would be to have a repo just with
documentation specifying exactly what each function does and a bunch of
test cases, then have all "ports" implement those operation the way they
like, but keeping behavior consistent.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-22439620
.

[metal3d]

Ok, I'm back.

I agree with you, if behavior is diffrent, it is a port... so it should be named differently. You said that you've made an implementation, and not a "different" system. But now you're speaking about changes.

And the name of the current issue we're talking is "Implementation rules". We needed a repo with rules, and now we have one. The best place to discuss about enhancements is on the "Implementation" repo.

If you make another "port", meaning that you want to change behaviour and implementation, this is not a fork, so my work will be to check your implementation and append what can be integrated following rules of the VerbalExpressions organisation.

Now, lets get a developper who works with PHP and Go... If he takes your repo and not our, he will have different behaviour using the same semantic... But if you give enhancements as "issues", we will talk about with others implementations authors (where I consider you are in), then every implementation will follow the new rules. We will be able to create versions, branches, fixes...

When you say "IMHO the best way of working would be to have a repo just with documentation specifying exactly what each function does" I'm forced to repeat, please check the repo made for this:
https://github.com/VerbalExpressions/implementation

And especially this page: https://github.com/VerbalExpressions/implementation/wiki/List-of-methods-to-implement