perlsgml-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Perlsgml-dev] Perl5 modules API


From: Earl Hood
Subject: Re: [Perlsgml-dev] Perl5 modules API
Date: Thu, 13 Sep 2001 10:18:10 -0700 (PDT)

--- Yann Dirson <address@hidden> wrote:
> - It seems to rely on a custom model.  What about using a more
> standard one, grove-based, using (part of) the SGML property-set ?

The code for the module was written before groves where around.
I believe the DSSSL spec was still languishing when the code base
was written.  The SGML::DTD module is basically a port of dtd.pl,
with enough restructure to allow instance instantiation.  Remember,
Perl 4 had no concept of objects, or even complex data structures
(no references).  Doing such things required ugliness and trickery.

> - The SGML::DTD object does not return objects itself.  It would be
> IHMO better to have classes like:
> 
> SGML::DTDDef::Element
> SGML::DTDDef::Attribute
> SGML::DTDDef::Notation
> SGML::DTDDef::Entity  # generic, parent class for the following:
> SGML::DTDDef::Entity::Parametric
> SGML::DTDDef::Entity::General
> 
> Objects belonging to those classes would be either built on
> read_dtd(), or instantiated in a lazy manner when SGML::DTD::get*()
> and such would be called.

Agreed.  The usage and history of the development of the current
module set did not mandate a complete(?) object model.  I did enough
to satisfy my immediate needs.

If starting all over, your suggestions are the approach I would
take.

I propose the following development plan:

1. Take the existing code base and apply contributed patches that
   Susan and I have received.
2. Port documentation to POD to be consistent with other Perl module
   packages.
3. Change the install procedures to use MakeMaker model.
4. Make a 1.0 release.
5. Start the development of 2.0: This includes a potential (if not
   definite) rewrite of modules to support a more robust object
   object model (like what you are suggesting).

To summarize, lets get what currently exists touched up and released.
This will provide satisfaction to existing users and it will make
sure we have the release process down.  After that, the next generation
of perlSGML can be developed where compatibility with the existing
version can be ignored in favor of a more robust design.

What you are suggesting will take some considerable work, and I
prefer to get something out sooner that still has applicable use
before embarking on a redesign.  Since all of our schedules can
leave us little time to work on perlSGML, doing the redesign could
take some considerable time.  Plus, we would have to determine who
is willing, and able, to do the work that is desired.

Thoughts?

--ewh


=====
Earl Hood,
address@hidden
<http://www.earlhood.com/>

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]