Re: [WMVS] Some initial thoughts on code M12N...

At 09:25 04/09/22 +0200, Terje Bless wrote:

[lots of agreement snipped]

>I think probably the bone of contention is/will be the exact point at which
>internal refactoring ("internal m12n") should end and the external module
>("M12N") should begin.
>
>Personally I draw the line at starting to use package namespaces inside
>"check"; if you feel it's time to say "package Foo::Bar" and stuff your code
>inside that, then it's probably high time to start work on the external
>module.

I could live either way.


>But I fully expect diverging opinions on this. e.g. while Bjoern has developed
>SGML::Parser::OpenSP fully fledged outside "check", I know he's also suggested
>starting off the M12N process by simply putting a "package" declaration above
>the subroutines in "check" and working from there. I'm sure there are other
>opinions on the choke-point as well.

A 'package' around all subroutines goes a bit too far; a 'package'
around some subroutines that belong together would be okay by me.


> >>that it forces dicipline in determining what improvements go in
> >>immediately and what will have to wait until we're ready to make the
> >>switch, and finally, that it takes longer before we can take advantage
> >>of the new features in WMVS.
> >
> >Just a thought: In some way, I see "doing branches without branches".
>
>Sure. The objections have been over the specific technical detail of using CVS
>branches, due to perceived complexity and overhead, not over the
>"architectual" issues of clean separation of functional code units and
>out-of-band development etc. At least that's my understanding of it.

Ok, got it.


>In any case, so long as a portion (in this case even a majority) of the
>developers feel CVS branches would be an impediment, and have few if any
>benefits to outweigh it, it makes eminent sense to work around the need for
>CVS branches.
>
>Surely this lowers the bar especially for occasional contributors like
>yourself, who can avoid spending time on figuring out the current branch
>situation instead of writing code?

Yes, quite a bit.



>[XML::Charset]
> >I think it shouldn't be a module of its own. But it may well be exposed
> >as one function of a module. Would that work for you?
>
>Well, I'm sure your judgement is better than mine on that -- :-) -- but my
>general point is probably that we shouldn't be afraid of making code units too
>small to stand alone. It's my experience, and strongly held opinion, that any
>piece of code that merits a subroutine has potential value as a standalone
>module; irrespective of the amount of ground covered.
>
>Text::Iconv, say, is just a few tens of lines of code; as was the 0.01 version
>of SGML::Parser::OpenSP.
>
>In the specific case of "XML::Charset", my opinion was based on the fact that
>Appendix F of the XML 1.0 Recommendation describes the algorithm instead of
>just saying "it's possible to do it". If there is value in specifying the
>algorithm there is probably value in providing a canonical implementation of
>it to avoid reinventing the wheel in every module that needs to deal with XML.
>
>But as mentioned, I'll trust your judgement over mine on this one.

I think we'll see as time goes.


> >Okay. Am I correct that moving as much of the message text out of
> >'check' is part of the 0.7.0 release?
>
>Well, for the most part, what I'd intended for 0.7.0 is done. There are a
>whole bunch of stuff left in there that is better done with a l10n framework
>(i.e. something gettext-ish for getting the strings, and templates for
>formatting) than by trying to move this out with just templates. And the l10n
>framework is still not in place; and unless something radical changes, won't
>be in place during the 0.7.0 release.

Oh, I see. So this means that templates don't/won't solve the message
localization problem. That will mean that we will have two separate
solutions for message localization, yes? Sounds quite scary.

Turned around, if templates don't solve the localization problem, what
problem exactly are they solving? Your text above seems to indicate
'formatting'. What exactly would that encompass?

Also, have you looked around for 'something gettext-ish'?
I have my own ideas that at one point I wanted to test out on
the validator (maybe you remember the discussion a year or two ago)
but I didn't persue it because I thought


>There's some stuff left that can (and should) get moved out during 0.7.0, but
>other stuff will have to stay for the time being. Without looking at the code
>I'd guess most of what you're seeing in the charset parts of the code are of
>the latter kind (e.g. any &abort_if_error_flagged() calls and such).

Okay. I'll still try to separate out functionality and program text
a bit more.


>- --
>I have to admit that I'm hoping the current situation with regard to XML
>Namespaces and W3C XML Schemas is a giant practical joke,   but I see no
>signs of pranksters coming forward with a gleeful smile to announce that
>they were just kidding.                              -- Simon St.Laurent

I have to admit that I have a great distaste for when somebody continuously
telling others that something is wrong without saying what's wrong.
                                                       -- Martin J. Duerst


Regards,    Martin.

Received on Wednesday, 22 September 2004 09:29:56 UTC