Re: [frogs] Changing subproperties with grob-set-property (working on bug #40)

[Neil Puttock <n.puttock@xxxxxxxxx>]

2009/11/2 Marc Hohl <marc@xxxxxxxxxx>:

> Ok, then:
>
> LY_DEFINE (ly_grob_set_nested_property_x, "ly:grob-set-nested-property!",
>    3, 0, 0, (SCM grob, SCM symlist, SCM val),
>    "Set nested property @var{symlist} in grob @var{grob} to value
> @var{val}.")
> {
> Grob *sc = unsmob_grob (grob);
>
> LY_ASSERT_SMOB (Grob, grob, 1);
> LY_ASSERT_TYPE (ly_cheap_is_list, symlist, 2);

Hmm, now I've had more time to think about this, I'm not sure this is
ideal, since there's no check that the elements of the list are
symbols.  It's probably safer to use SCM_ASSERT_TYPE to brew a custom
assertion for "list of symbols":

bool type_ok = ly_cheap_is_list (symlist);

  if (type_ok)
    for (SCM s = symlist; scm_is_pair (s); s = scm_cdr (s))
      type_ok &= ly_is_symbol (scm_car (s));

  SCM_ASSERT_TYPE (type_ok, symlist, SCM_ARG2, __FUNCTION__, "list of symbols");

>
> if (!ly_is_procedure (val)
>    && !type_check_assignment (symlist, val, ly_symbol2scm
> ("backend-type?")))
>  error ("typecheck failed");

I'm afraid you can't do this on a nested property, since
type_check_assignment () expects a symbol as the first arg.  Though
you could extract the main symbol (e.g., 'bound-details) using scm_car
(), the type check would still fail due to a mismatch between the
property type (list?) and the val (which would be a number in the case
of your snippet above).

> set_nested_property (sc, scm_list_n (symlist, SCM_UNDEFINED), val);

Since symlist is already a SCM list, you don't need to use scm_list_n here:

set_nested_property (sc, symlist, val);

> (Hm, it still feels like the time beginning with scheme where I stirred
> in the fog and put several pieces together in the hope they will work
> somehow...).

Don't worry, it'll soon make perfect sense, though if you're starting
to get cold feet, you could try implementing this in Scheme instead.

Regards,
Neil

---

----
Join the Frogs!