[PilRC] Re: ANN: pilrc 2.8p7 in patch zone

[John M. <jma...@ac...>]

On Mon, Aug 13, 2001 at 10:17:42AM +0100, Regis Nicolas wrote:
> Hi John,

Salut Regis.

> The changes we were working on included support for PalmOS 4.0 in PilRC as
> well as support for upcoming ARM versions of PalmOS. As you can easily
> understand, these are relatively big changes, thus creating the potential
> for some bugs. We also think that this adds significant value to PilRC for
> developers.

Let's talk about these new -Loc and -StripLoc options for a moment
(which are what's implemented by all those new gotos).

I don't think that these options add significant value to PilRC for
developers, because PilRC has had equivalent functionality for close to
a year (since 2.6, 2000-10-30).

Consider just one way of expressing this idea:

	#ifdef enUS
	form id mainForm ... begin ... end
	#endif
	
	#ifdef frFR
	form id mainForm ... begin ... end
	#endif

	#ifdef NONLOCALISABLE
	alert id otherAlert ... begin ... end
	#endif

Setting enUS and NONLOCALISABLE is equivalent to the proposed "-Loc enUS".
Setting just enUS is equivalent to "-Loc enUS -StripLoc".  Setting all of
enUS, frFR, ..., NONLOCALISABLE is equivalent to no localisation options.
(There are various ways to automate the setting of all these macros.)

If this doesn't have the same effect as these new locale options, then
I guess I don't understand the documentation of those options :-).  (If
PilRC's #ifdef/#endif functionality doesn't actually work as the
documentation suggests, then that is a bug to be fixed.)

I am sorry if it seems that I am denigrating the work that it took to
design and implement the locale functionality.  That is not my
intention.  But I'm not convinced that PilRC actually needs this
functionality, or that the (currently large!) cost in maintainability is
worthwhile.

As I mentioned in my previous email, I wish there were more public
discussion of work like this going on in PilRC.  Perhaps a suggestion
like that above might have been made and a lot of work saved.  Or
certainly the best solution arrived at.

> About VALUE:
> The VALUE keyword has been added to correct an older bug as explained below.
> 
> I read Aaron's reply and I tend to agree with him.

If you mean the part about "for INTEGER it was acceptable, because that
keyword has never really been in a public release", I have to admit that
that comment confused me.  INTEGER was introduced in 2.7, which was released
on 5 Jan 2001.  INTEGER has been in at least two public releases (2.7, 2.8)
for all of this year.  (If those two aren't public releases, perhaps Aaron
could clarify what he does consider to be a public release.)

> He certainly mentioned to
> me to have these VALUE optional and I probably forgot to tell Renaud to do
> so. I will ask him to fix that.

That's great, and just what I was looking for.  Certainly it is good
that this got noticed before a new public (i.e., non-patch) release of
PilRC was made.

> About the goto statements:
> We all know that a kind of usage for gotos is acceptable and probably much
> clearer than using lots of obscure flags. I do not think that it's
> appropriate to criticize someone's way of coding as long as it stays in
> reasonable standards.

I mostly agree, but it seems we disagree about what constitutes those
reasonable standards.

In this case (if the locale options turn out to be a good idea), many
instances of this duplicated code could be replaced by suitable use of
a function such as the one below, with in my opinion a massive increase
in clarity.  As it happens, this also gets rid of large numbers of gotos.

BOOL ObjectDesiredInOutputLocale (const ITM *itm) {
  if (itm.Locale)
    return szLocaleP == NULL || strcmp (itm.Locale, szLocaleP) == 0;
  else
    return ! vfStripNoLocRes;
  }

> About the system types:
> Things not obvious for you may be for some other people :-)
> In order to have PilRC even closer from the OS, we decided to modify it to
> be able to compile a ROM. We needed to add these types to do so and we did.

(Well, you and I know that, but most people probably think PilRC is a tool
for writing applications, and don't realise a few people at Palm have been
using it to build ROMs.)

> I do not think that having these types cause any trouble. They are
> documented as PRIVATE and people should not use them. They simply have to
> ignore them.

It would be reasonable (and perfectly in line with the GPL) to have a
Palm-internal version of PilRC which knows about these types.

It would (probably) be reasonable to add these types to the public free
software release of PilRC with documentation of what they do and where
they are used.

It is not reasonable to add functionality to someone else's free
software project and refuse to document that functionality.  This
unnecessarily complicates things for the users of the project, and
places an impossible maintainence burden on the developers -- how is
anyone outside Palm supposed to maintain this code if they don't know
what it is supposed to do and have no way of testing it?

IMHO if Palm or anyone else wants some particular functionality in PilRC
then they need to justify its inclusion and (be willing to) document it
fully, or they need to accept the cost of maintaining their own internal
version and doing occasional merges from the public version.

> By the way, it would probably be preferable to send this kind of emails to a
> little bit more restricted audience next time :-)

As is probably obvious by now, I disagree.  I think in a free software
project it is preferable to allow anyone to contribute.  An important
part of that is holding discussions on archived public mailing lists.

    John