http://www.perlmonks.org?node_id=88509


in reply to Idea on a Base class API

I worry that you're combining the worst aspects of C/C++ (convoluted syntax) and Perl (flexability that gets you into trouble when you use the wrong option). One of the cornerstone ideas of Perl is that new tools are optional, and hence can only add to understanding. It seems like there's just an awful lot of overhead, involving a lot of syntax, to get the work done. The API doesn't mesh with Perl's shallow learning curve.

For example, defining data type values for each attribute painfully reminds me of C data types. I'd rather have an API that did the work for me-- the API isn't serving the programmer if the programmer does all their work in the function arguments. For example, you could figure out most data types via the get() and set() functions. If you want to set an object "strict", the object could warn (or prohibit) when an old reference value was changed to a scalar, for example.

I think you need to plan this from a totally different mindset. Don't start from, "This is what C++ says classes are-- how do I implement that?" Start from, "What's the easiest, cleanest way for the programmer to implement classes, and what API serves that purpose best?"

-Ted

Replies are listed 'Best First'.
Object concept ... starting from scratch
by dragonchild (Archbishop) on Jun 14, 2001 at 21:25 UTC
    Ok ... I probably got a little crazy to start with, trying to add strict typing right off the bat. So, let's start from the beginning.

    An class needs to be able to do the following things:

    • Define which attributes exist within any instance of the class. (This also needs to be able to pull in any attributes defined in any parent classes.)
    • Create an instance of the class
      • Values come explicitly, in attribute-value pairs
      • Values come implicitly, from an object reference of the same class (or some parent class?)
    • check to see if this instance of this class is identical to another instance of this class (or some parent class?)
    • check to see if an attribute exists or not
    • set the value of an attribute
    • get the value of an attribute
    Did I miss anything, from the highest level? Did I add something that shouldn't be there?
      Why do you want an object interface in the first place? How will it serve you? Design your interface based on, "What do I need?", not "What can this do?".

      -Ted
        I want to design an object interface to create a series of modules for CPAN. However, I wanted to vet the concepts with PM, because most of my OO work has been in 2-3 areas and I know I'm missing a number of possible uses that may have to be accounted for in the contract and/or implementation.