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

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

Just to make it clear... we -are- talking about Class::Fields here and
not protected.pm?  The conversation appears to have strayed from the
original topic.


On Sun, Jan 09, 2000 at 03:09:55AM -0800, Gurusamy Sarathy wrote:
> 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.

Ah ha!  That's exactly the term I've been dancing around and that's
exactly what I want to do.  RTTI.

Yes, I am stretching the original design, and I hit that design
limitation rather early in my use of it.  I should think wanting to
get RTTI would be fairly common?  If its not then this whole proposal
can pretty much be scrapped and Class::Fields will just live on CPAN.


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

(It was just a hypothetical.)


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

(Forget is_protected() for the moment)

Hmmm, I hadn't expected this reaction.  I'd thought these few simple
operations to be fairly uncontroversal, at least in terms of Perl's
loose interpretation of OOP.  If they are seen as uncommon, then like
I said, scrap the proposal.

BTW  How is this leading towards straitjacketing?


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

And its exactly the thing that Class::Fields doesn't address.

-- 

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

---

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]

---