On 17/7/10 20:27, Diederik van Lierop wrote:

On 07/17/2010 07:58 PM, bulia byak wrote:

...

I can probably fix it, but I wonder if it may be a sign of some other trouble. Anyone else seeing this?

That revision compiled just fine this afternoon on Fedora 12.

trunk r9618 compiled fine on OS X 10.5.8, too.

The error

sp-gradient.h: In function ‘void sp_gradient_pattern_common_setup(cairo_pattern_t*, SPGradient*, const NRRect*)’: sp-gradient.h:81: error: ‘SPGradientUnits SPGradient::units’ is private sp-gradient.cpp:2057: error: within this context sp-gradient.cpp: In function ‘cairo_pattern_t* sp_radialgradient_create_pattern(SPPaintServer*, const NRRect*)’: sp-gradient.cpp:2071: error: ‘sp_gradient_ensure_colors’ was not declared in this scope sp-gradient.cpp: In function ‘cairo_pattern_t* sp_lineargradient_create_pattern(SPPaintServer*, const NRRect*)’: sp-gradient.cpp:2089: error: ‘sp_gradient_ensure_colors’ was not declared in this scope

seems to happen in the gsoc-cairo branch (r9509 "Initial Cairo rendering commit: solid shapes, gradients, opacity and patterns") - 'sp_lineargradient_create_pattern()' does not exist in trunk (src/sp-gradient.cpp).

~suv

Is new code being added that is prefixed with sp?

On Jul 17, 2010 12:00 PM, "bulia byak" <buliabyak@...400...> wrote:

On Sat, Jul 17, 2010 at 3:57 PM, ~suv <suv-sf@...58...> wrote:

seems to happen in the...

Oops, indeed I had a local change from the gsoc project since long ago - and completely forgot about it. Thanks.

Quoting Krzysztof Kosinski <tweenk.pl@...400...>:

2010/7/17 Josh Andler <scislac@...400...>:

...

Is new code being added that is prefixed with sp?

I think it's OK to keep the sp_ prefix when adding functions to existing code for the sake of consistency.

Not really, at least not for new functions.

We've gone over this as a project a few times. First of all, we have an overall desire to get rid of the "Sodipodi" naming.

More importantly, though, is that we should not be targeting long bare C-style decorated names. We need to favor class static and member functions over bare C functions.

We also need to favor namespaces over extending c-style names. And favor classes over namespaces.

If we have existing *code* with existing names with "sp_" as a prefix, then for branches it might be beneficial to leave those existing names as-is. However, this would only be for the sake of reducing diffs and merge conflicts.

New functions should avoid the "sp_" prefix.

And finally keep in mind what Emerson said, "A foolish consistency is the hobgoblin of little minds".

For example, if one were to add a function to perform "foo" on SPStyle, instead of creating a function named

void sp_style_perform_foo(SPStyle *style, ...)

one should instead add a *method* to the SPStyle class itself as

void SPStyle::performFoo(...)

And of course if a function is not directly applicable to a specific class, it should be considered for a static method on a pertinent helper class. (But here we wonder off into the abstracts of OO design.)