Re: protected.pm (more Class::Fields)

[Michael G Schwern <schwern@pobox.com>]

On Sun, Jan 02, 2000 at 11:45:12AM -0800, Gurusamy Sarathy wrote:
> >                                  What I'm proposing is a rewrite of
> >the internals and the addition of some methods for field manipulation
> >and examination, but its still basically the same as the existing
> >system.
> >
> >Its all already in the core, fatal flaws and all.  I'm just trying to
> >make it servicable.
> 
> I have no interest in institutionalizing any fatal flaws behind a
> serviceable interface.  I'd much rather leave pseudo-hashes and the
> fields stuff marked "experimental" until we can add a proper solution
> that we can live with.

Yes, I agree this should all be left experimental for the time being,
but I don't agree about leaving out the Class::Fields interface
improvements.  Four reasons.

First, as I explained in my last post, the current interface forces
people to get down and dirty with the internals.  As the internals are
currently flawed and they must change it is a Bad Thing to encourage
deep interaction with them.  Thus, providing a high-level interface
makes it safe to play with this experimental feature by shielding the
user from the internal changes.  The sooner we provide that shield the
less comptability issues will be raised when we make deep, fundemental
changes to it.

Second, the more useful a feature is, the more people will use it.
The more people using it, the more eyes we have looking over the code
and suggesting improvements.  Right now I honestly think I'm the only
person on p5p using fields -and- pseudo-hashes in a production
environment and on a large scale.  Maybe the idea stinks and I've
backed a dead horse, but maybe it just doesn't have the right face on
it.

Third, pseudo-hashes, fields.pm and base.pm can be removed from the
core completely and Class::Fields will still live (on CPAN) and code
depending on it will still work (provided they change from
pseudo-hashes to hashes).

Fourth, Class::Fields provides an interface which should fit any
future OO data model we come up with.  Its all stuff you'd expect to
find in any sensible OO language (protected.pm aside)... listing
available fields (show_fields()) and asking if a given field is of a
given type (is_public(), is_private(), etc...).  It should survive
whatever we finally settle on, only the internals will change.


In short, the repair of the flaws in the existing field model
(ie. multiple field inheritance) is totally unrelated to
Class::Fields's proposed interface.  Both lead independent lives.


> Maybe there ought to be some sort of a expiry date on the "experimental"
> stuff.  If something doesn't pass the experimental stages for a couple
> of major release cycles, perhaps it should be thrown out altogether.
> What say?

Check me here, "major release" is 5.005, 5.6, 5.7, etc... yes?  Sounds
like a reasonable rule of thumb, but I don't think a hard limit should
be set.

So that means threads will be going away soon, then? ;)

-- 

Michael G Schwern                                           schwern@pobox.com
                    http://www.pobox.com/~schwern
     /(?:(?:(1)[.-]?)?\(?(\d{3})\)?[.-]?)?(\d{3})[.-]?(\d{4})(x\d+)?/i

---

Follow-Ups from:

andreas.koenig@anima.de (Andreas J. Koenig)
Gurusamy Sarathy <gsar@ActiveState.com>

References to:

Michael G Schwern <schwern@pobox.com>
Gurusamy Sarathy <gsar@ActiveState.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---