How to deprecate PangoScript?

Hi,

I want to release Pango 1.18 early next week.  The only
pending item is
how to deprecate PangoScript in favor of the newly added
GUnicodeScript?
I'm particularly interested to hear what not to do from
binding people.

Possibilities I see:

  1. Do nothing: document that PangoScript and
GUnicodeScript are
interchangable and add values to both enums as new scripts
are encoded
in Unicode in the future.  The main problem with this
approach is that
as pango_script_for_unichar() will be just a wrapper around
g_unichar_get_script(), if you install newer GLib,
pango_script_for_unichar() may return values that are not in
the
PangoScript enum.  That's not good.

  2. Leave PangoScript as is, mark it deprecated, and change
all public
Pango API to use GUnicodeScript.  I assume this breaks at
least C++ code
using those API, so this probably is not an option.

  3. #define PangoScript GUnicodeScript and #define the
currently
defined PANGO_SCRIPT_ values to respective G_UNICODE_SCRIPT_
values.
Maybe add new ones in the future, maybe not.

  4. Like 3, but also go ahead and change PangoScript uses
to
GUnicodeScript in public Pango API (and internally too). 
This doesn't
have the C++ problem because PangoScript and GUnicodeScript
will be the
same thing as far as the compiler is concerned.  The gobject
type name
for PangoScript changes though as we should make
pango_script_get_type()
to just return g_unicode_script_get_type().  Right?

  5. ??


I'm particularly looking for a short-term solution to put in
1.18, and
possibly a longer-term solution for 1.20.  One safe
short-term solution
can be don't do anything for 1.18 (not even make
pango_script_for_unichar() use g_unichar_script()).  Given
that we are
in API/ABI freeze already, that may be the most reasonable
solution for
1.18.

Please discuss.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase
a little
 Temporary Safety, deserve neither Liberty nor
Safety."
        -- Benjamin Franklin, 1759



_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On Thu, 2007-08-02 at 15:48 -0400, Behdad Esfahbod wrote:
> I want to release Pango 1.18 early next week.  The only
pending item
> is
> how to deprecate PangoScript in favor of the newly
added
> GUnicodeScript?
> I'm particularly interested to hear what not to do from
binding
> people.
> 
> Possibilities I see:
> 
>   1. Do nothing: document that PangoScript and
GUnicodeScript are
> interchangable and add values to both enums as new
scripts are encoded
> in Unicode in the future.  The main problem with this
approach is that
> as pango_script_for_unichar() will be just a wrapper
around
> g_unichar_get_script(), if you install newer GLib,
> pango_script_for_unichar() may return values that are
not in the
> PangoScript enum.  That's not good.

How is that different from the case where you compile for a
particular
version, and you run with a newer one with added scripts ?

	Xav


_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On Fri, 2007-08-03 at 09:53 +0200, Xavier Bestel wrote:
> 
> >   1. Do nothing: document that PangoScript and
GUnicodeScript are
> > interchangable and add values to both enums as new
scripts are
> encoded
> > in Unicode in the future.  The main problem with
this approach is
> that
> > as pango_script_for_unichar() will be just a
wrapper around
> > g_unichar_get_script(), if you install newer
GLib,
> > pango_script_for_unichar() may return values that
are not in the
> > PangoScript enum.  That's not good.
> 
> How is that different from the case where you compile
for a particular
> version, and you run with a newer one with added
scripts ?

Good point.  Fortunately not that different. 

>         Xav



-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase
a little
 Temporary Safety, deserve neither Liberty nor
Safety."
        -- Benjamin Franklin, 1759



_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On Sat, 2007-08-04 at 09:38 -0400, Torsten Schoenfeld
wrote:
> On Thu, 2007-08-02 at 15:48 -0400, Behdad Esfahbod
wrote:
> 
> >   4. Like 3, but also go ahead and change
PangoScript uses to
> > GUnicodeScript in public Pango API (and internally
too).  This doesn't
> > have the C++ problem because PangoScript and
GUnicodeScript will be the
> > same thing as far as the compiler is concerned. 
The gobject type name
> > for PangoScript changes though as we should make
pango_script_get_type()
> > to just return g_unicode_script_get_type(). 
Right?
> 
> As far as I can tell, option four won't cause
insurmountable problems
> for language bindings.  And given that it appears to be
a clean solution
> from a C point of view, I think it's the winner.
> 
> I take it that pango_script_iter_* won't be changed
apart from
> pango_script_iter_get_range for which PangoScript is
replaced by
> GUnicodeScript?

Thanks for the comments.  After discussing the options with
Owen, and
given the fact that the enum is not expected to change much
in the
future, we decided to take the least-risky path of just
documenting the
equivalence and not changing the API at all.  In the end,
PangoScript is
rarely used outside of Pango, and GUnicodeScript is only
interesting
when not using Pango, so the whole thing should be a big
issue for
anyone.

I'll release 1.18.0 soonish.

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase
a little
 Temporary Safety, deserve neither Liberty nor
Safety."
        -- Benjamin Franklin, 1759



_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On Thu, 2007-08-02 at 15:48 -0400, Behdad Esfahbod wrote:

>   4. Like 3, but also go ahead and change PangoScript
uses to
> GUnicodeScript in public Pango API (and internally
too).  This doesn't
> have the C++ problem because PangoScript and
GUnicodeScript will be the
> same thing as far as the compiler is concerned.  The
gobject type name
> for PangoScript changes though as we should make
pango_script_get_type()
> to just return g_unicode_script_get_type().  Right?

As far as I can tell, option four won't cause insurmountable
problems
for language bindings.  And given that it appears to be a
clean solution
from a C point of view, I think it's the winner.

I take it that pango_script_iter_* won't be changed apart
from
pango_script_iter_get_range for which PangoScript is
replaced by
GUnicodeScript?

-- 
Bye,
-Torsten

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-listgnome.org

http://mail.gnome.org/mailman/listinfo/gtk-i18n-list