Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor/directive parsing #2001

Merged
merged 2 commits into from
Apr 23, 2016
Merged

Conversation

mgreter
Copy link
Contributor

@mgreter mgreter commented Apr 15, 2016

Spec test sass/sass-spec#764 (excerpt from #1900, fixes #1233)

  • libsass-todo-issues\issue_1233\expected.nested
  • libsass-todo-tests\scss-tests\127_test_moz_document_interpolation\expected.nested
  • libsass-todo-tests\libsass\moz-document\basic\expected.nested
  • libsass-todo-tests\libsass\moz-document\interpolated\expected.nested

@mgreter mgreter force-pushed the refactor/directive-parsing branch 3 times, most recently from e46ab12 to fd0f1c6 Compare April 17, 2016 04:37
@xzyfer
Copy link
Contributor

xzyfer commented Apr 23, 2016

If you're going to make this massive of a change I suggest doing your best to move more inline with Ruby Sass implementation like with cssize.

The closer our internal data flow and logic is to Ruby the easier it's going to be keep features in sync, and prevent weird edge cases.

@mgreter
Copy link
Contributor Author

mgreter commented Apr 23, 2016

If you check the commits this is exactly what is happening here (see prelexer)!

@xzyfer
Copy link
Contributor

xzyfer commented Apr 23, 2016

I wasn't insinuating it wasn't what you were doing. I just wanted to make sure we were on the same page.

@mgreter
Copy link
Contributor Author

mgreter commented Apr 23, 2016

Just assumed, because the main reason why this change is that massive is because it is following ruby sass closely in the first place 😉

@mgreter
Copy link
Contributor Author

mgreter commented Apr 23, 2016

Just to be clear, I agree to follow ruby sass closely when it comes to the parser and the internal ast in general. But we can (and should) do better in libsass with manipulation and processing. I guess ruby sass choose to do quite a few operations (I'm specially refering to extend) in a monolithic approach. This makes sense in a language with dynamic function dispatching, since adding to many method calls in tight loops (code hotspots) can lead to bad performance. We don't have this constraint in c++ and should embrace the possibility of micro functions for selector manipulations. Another reason for that is that writing big monolithic functions in C++ (or any strict types language for that matter) tends to get tiresome, specially when a lot of loops are involved. But so far extend works and I don't want to touch any of that directly ported Node class if possible. Which reminds me of #1392 ...

@xzyfer
Copy link
Contributor

xzyfer commented Apr 23, 2016

I agree. I tend to avoid the extend code this exact reason.

@mgreter mgreter added this to the 3.3.6 milestone Apr 23, 2016
@mgreter mgreter self-assigned this Apr 23, 2016
@xzyfer
Copy link
Contributor

xzyfer commented Apr 23, 2016

You'll probably have to rebase your sass-spec branch of master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.3%) to 78.949% when pulling 83d401b on mgreter:refactor/directive-parsing into 57fbfb9 on sass:master.

@mgreter mgreter merged commit eaf3413 into sass:master Apr 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Block comments should be preserved in "static" at rules
3 participants