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

[Gurusamy Sarathy <gsar@ActiveState.com>]

On Sun, 09 Jan 2000 03:29:13 EST, Michael G Schwern wrote:
>First, as I explained in my last post, the current interface forces
>people to get down and dirty with the internals.

It's not clear to me that it does (at least so far).

You seem to be using it for RTTI/introspection, which appears to be
more than this stuff was "designed" to do.  Maybe that is the problem.

>                                                  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

I cannot justify doing that at this point, but we should make any
changes that insulate us from future changes.

>                 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())

This counts as extra-normal OO, IMHO.

>                                 and asking if a given field is of a
>given type (is_public(), is_private(), etc...).

This is probably sub-normal OO.

>                                                 It should survive
>whatever we finally settle on, only the internals will change.

That's a fine goal, but I'm also wary of overspecifying the interface.
Having things like is_public(), is_private(), is_protected() etc.,
would seem to force/endorse one particular type of object-orientation.
(Frankly, I'd rather not head towards a straitjacketed system based on
OO as implemented by C++.)

>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.

I'd agree that we should make attribute inheritance as natural as
method inheritance, but that's about the only thing that seems like
an imperative to me in all this.


Sarathy
gsar@ActiveState.com

---

Follow-Ups from:

Michael G Schwern <schwern@pobox.com>
Larry Wall <larry@wall.org>

References to:

Michael G Schwern <schwern@pobox.com>

---

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

---