Hello,

I've made a smaill binding to libsass - a C/C++ implementation of
popular CSS preprocessor SASS. Binding is dynamic and based on
Derelict Project.

You can find it here: https://github.com/Lodin/DerelictSASS

It is my first attempt to make something like this, so if I did
something wrong, please tell.

On Saturday, 22 November 2014 at 12:32:50 UTC, Lodin wrote:
> Hello,
>
> I've made a smaill binding to libsass - a C/C++ implementation of
> popular CSS preprocessor SASS. Binding is dynamic and based on
> Derelict Project.
>
> You can find it here: https://github.com/Lodin/DerelictSASS
>
> It is my first attempt to make something like this, so if I did
> something wrong, please tell.

Nothing bad jumps out on a cursory look. However, I do recommend
you combine all the files into one -- sass.d. When I first
started Derelict, I separated everything out into multiple
modules for every binding. Over time, I found it makes
maintenance easier to implement a binding in one module if it is
feasible. For large libraries like OpenGL and SDL, it's not going
to help. For something like SASS, with so few functions and
types, it should be the first choice. Granted, the real benefit
probably only shows when maintaining several bindings like I do,
but I still recommend it as I think it also improves readability.

On Saturday, 22 November 2014 at 13:15:47 UTC, Mike Parker wrote:
> Nothing bad jumps out on a cursory look. However, I do recommend
> you combine all the files into one -- sass.d. When I first
> started Derelict, I separated everything out into multiple
> modules for every binding. Over time, I found it makes
> maintenance easier to implement a binding in one module if it is
> feasible. For large libraries like OpenGL and SDL, it's not going
> to help. For something like SASS, with so few functions and
> types, it should be the first choice. Granted, the real benefit
> probably only shows when maintaining several bindings like I do,
> but I still recommend it as I think it also improves readability.

Thank you. I've combined it, and it really looks simpler now.

A tip to keep in mind when translating C/C++ headers:

---
enum Sass_Tag {
    SASS_BOOLEAN,
    SASS_NUMBER,
    SASS_COLOR
};
---

is best translated as

---

alias Sass_Tag = int;
enum : Sass_Tag {
    SASS_BOOLEAN,
    SASS_NUMBER,
    SASS_COLOR
}
---

That way your enum isn't namespaced.



On Saturday, 22 November 2014 at 13:15:47 UTC, Mike Parker wrote:
>
> However, I do recommend
> you combine all the files into one -- sass.d. When I first
> started Derelict, I separated everything out into multiple
> modules for every binding. Over time, I found it makes
> maintenance easier to implement a binding in one module if it is
> feasible.

Going to keep that in mind.

On 11/23/2014 1:44 AM, ponce wrote:
> A tip to keep in mind when translating C/C++ headers:
>
> ---
> enum Sass_Tag {
>      SASS_BOOLEAN,
>      SASS_NUMBER,
>      SASS_COLOR
> };
> ---
>
> is best translated as
>
> ---
>
> alias Sass_Tag = int;
> enum : Sass_Tag {
>      SASS_BOOLEAN,
>      SASS_NUMBER,
>      SASS_COLOR
> }
> ---
>
> That way your enum isn't namespaced.
>

I completely missed that.

@Lodin The reason ponce suggests this is that when using the binding in D, it's a good idea to for it to look as close to the C code as possible. That way, existing C code (especially examples from documentation and tutorials) can more easily be ported to D. Since C enums aren't namespaced, they shouldn't be in the binding, either.

Some people may prefer the bindings to include more D features, but IMO if you're going to put something out there for everyone and anyone to use, particularly if you want to be consistent with other Derelict bindings, it's better to avoid them.

On Saturday, 22 November 2014 at 16:44:11 UTC, ponce wrote:
> A tip to keep in mind when translating C/C++ headers:
>
> ---
> enum Sass_Tag {
>     SASS_BOOLEAN,
>     SASS_NUMBER,
>     SASS_COLOR
> };
> ---
>
> is best translated as
>
> ---
>
> alias Sass_Tag = int;
> enum : Sass_Tag {
>     SASS_BOOLEAN,
>     SASS_NUMBER,
>     SASS_COLOR
> }
> ---
>
> That way your enum isn't namespaced.
@ponce, @Mike Parker, thanks for information. Fixed it.

On 2014-11-23 01:26, Mike Parker wrote:

> Some people may prefer the bindings to include more D features, but IMO
> if you're going to put something out there for everyone and anyone to
> use, particularly if you want to be consistent with other Derelict
> bindings, it's better to avoid them.

For more D features I would add a thin layer on top of the raw bindings. Like creating wrappers for functions accepting C strings and have them accept D strings instead.

In this particular case I would probably have created the enum as one would do in D and the alias the enum members to make them accessible at module scope.

-- 
/Jacob Carlborg

On Sunday, 23 November 2014 at 19:36:16 UTC, Jacob Carlborg wrote:
> On 2014-11-23 01:26, Mike Parker wrote:
>
>> Some people may prefer the bindings to include more D features, but IMO
>> if you're going to put something out there for everyone and anyone to
>> use, particularly if you want to be consistent with other Derelict
>> bindings, it's better to avoid them.
>
> For more D features I would add a thin layer on top of the raw bindings. Like creating wrappers for functions accepting C strings and have them accept D strings instead.
>
> In this particular case I would probably have created the enum as one would do in D and the alias the enum members to make them accessible at module scope.

While I like language-friendly wrappers, they do tend to make some choices. They require additional documentation since new names and usage are introduced.

Sticking to the C API is choice-agnostic, existing documentation can be reused.

On Saturday, 22 November 2014 at 12:32:50 UTC, Lodin wrote:
> Hello,
>
> I've made a smaill binding to libsass - a C/C++ implementation of
> popular CSS preprocessor SASS. Binding is dynamic and based on
> Derelict Project.
>
> You can find it here: https://github.com/Lodin/DerelictSASS
>
> It is my first attempt to make something like this, so if I did
> something wrong, please tell.

This looks great! I plan on using it to build a diet plugin, just like Martin's coffee-script plugin[1]. Any chance you could register it on the Dub Registry[2] though? It would make using this a lot easier.

[1] https://github.com/MartinNowak/diet-coffee
[2] http://code.dlang.org/

On 11/24/2014 4:36 AM, Jacob Carlborg wrote:
>
> For more D features I would add a thin layer on top of the raw bindings.
> Like creating wrappers for functions accepting C strings and have them
> accept D strings instead.

Right, that's how a wrapper should be written. But I don't think it should be distributed with the binding.

>
> In this particular case I would probably have created the enum as one
> would do in D and the alias the enum members to make them accessible at
> module scope.
>

That's a valid approach, but I made the decision long ago not to do that in Derelict.