Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: RFR: Inside-out classes - a Class::InsideOut primer

by bart (Canon)
on Mar 16, 2007 at 11:29 UTC ( #605131=note: print w/ replies, xml ) Need Help??


in reply to RFR: Inside-out classes - a Class::InsideOut primer

Your introduction on Inside-Out Objects insn't right. You seem mostly concerned with preventing people from bypassing the API and muck directly with the internals. But this is Perl, mucking with internals is allowed, though frowned upon. After all, isn't a common catchphrase for Perl not "stay out of my livingroom because it's the polite thing to do, not because I have a shotgun"?

But the main reason for wanting them is one you don't mention, and it's not such an "esotheric" one as you claim: it is in order to be allowed to subclass any class without having to be aware of any hidden fields that are stored in the parent class, without any risk of trampling all over them, of which, after all, the list may change (grow) over time.

Compared to this, the direct field access and the possibility of mistyping are just minor issues.


Comment on Re: RFR: Inside-out classes - a Class::InsideOut primer
Re^2: RFR: Inside-out classes - a Class::InsideOut primer
by radiantmatrix (Parson) on Mar 16, 2007 at 14:23 UTC

    I disagree about the main reason for wanting them. They may have been created to solve inheritance issues, but based on how often I'm asked about how to create private and read-only attributes, that seems to be the primary reason many people would want inside-out objects.

    I'm reluctant to address the more esoteric concerns (like subclassing issues) in a primer -- the goal of a primer is to get someone started using a particular skill or technique, and it should not assume too advanced a prerequisite.

    Besides that, your characterization that I'm "mostly concerned with" the private/read-only capabilities is ridiculous: I mention that issue once in the introduction, and refer to it obliquely once more in discussing class design. However, that latter is necessary because Class::InsideOut does require the developer to consider whether one's attributes are public, private, or read-only.

    You are, of course, entitled to your opinions, but that doesn't make mine wrong.

    <radiant.matrix>
    Ramblings and references
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet
      Class::InsideOut does require the developer to consider whether one's attributes are public, private, or read-only

      Well, perhaps it's clearer to say that Class::InsideOut emphasizes the decision through a choice of syntax.

      Class::InsideOut tries to require as few things as possible:

      1. Objects: All new objects must be passed to (or created by) the register() function
      2. Properties: All data structures for object properties must be passed to the property() function.
      3. Direct Access: The key to directly access the property for an object in a property hash must be generated using refaddr() (from Scalar::Util) or the shorter alias id().

      The public(), private() and readonly() functions just call property() with appropriate options.

      I agree that showing it in practice rather than explaining all this is more appropriate for a primer

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      I disagree about the main reason for wanting them. They may have been created to solve inheritance issues, but based on how often I'm asked about how to create private and read-only attributes, that seems to be the primary reason many people would want inside-out objects.
      Oh I don't know. I would guess that people who want private and read-only attributes are just used to "strict" languages. I have hardly ever found them useful, since I'm of the opinion that you shouldn't access attributes from outside the object at all (i.e. you always want accessors or other methods to set the usefull attributes anyway), and if someone does validate the encapsulation, it's his problem. In other words, from "the outside", the actual storage mechanism of attributes is not usually relevant, since you normally never access them directly anyway.

      When I use inside-out objects attributes it's when I know I'm going to have many differing inheriting classes. Especially mixing pure-perl and perl/XS code. That's where the safety is relevant - you don't want to overwrite some super/subclasses' internal data - which can be easy to do by accident if you don't know all the internals of your superclass, and if you're subclassing an XS class you usually don't even have a hash-based implementation anyway.

        OI would guess that people who want private and read-only attributes are just used to "strict" languages.

        I would agree more if you were talking about private vs. protected properties -- i.e. access controls from other classes.

        (N.B. I avoid the term "attributes" since we also have attributes in Perl. I think it's unfortunate that some inside-out class generators talk about object "attributes" and then use attributes for methods as well.)

        I think that generating accessors (and/or mutators) for every bit of state associated with an object is a mistake because it merges implementation and interface. That is the violation -- or really, repudiation -- of the principle of encapsulation. It's not about hiding data, it's about decoupling.

        If you are the only one using your class, then it may not matter -- but if you share your code with others and if you want to promise some degree of API stability, then I think that making accessors for everything is a mistake. On the other hand, if you're comfortable declaring the difference between accessors you mean to be public and accessors you mean to be private in documentation and letting violators do so at their own risk, then I can see why this isn't a big deal for you.

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      I disagree about the main reason for wanting them. They may have been created to solve inheritance issues, but based on how often I'm asked about how to create private and read-only attributes, that seems to be the primary reason many people would want inside-out objects.
      Then these people are excited about their new shotgun.

      Disallowing people to access the internal gains you nothing. It just makes debugging harder, as Data::Dumper doesn't see anything inside the objects.

Re^2: RFR: Inside-out classes - a Class::InsideOut primer
by Anonymous Monk on Mar 16, 2007 at 14:46 UTC
    you contradicted yourself. preventing people from messing with the internals means they do not have to be aware of any hidden fields that are stored in the parent class. if they cannot mess with the internals, they do not need to be aware. it is not worrying about something that you are not able to do.

    anyone who designs an api, they may set expectations. if the designer wishes you not to muck around with internals, that is his choice. he can promote that if he pleases. mistyping may not be a minor issue for some. typos create all kinds of bugs.

    timtowtdi. appreciate all aspects of what people do and the reasons they do it. there are more opinions than facts in programming and software engineering.

      there are more opinions than facts in programming and software engineering.

      Ain't that the truth. In life too I guess, but nowhere more evident that in programming.

      And there is a strange phenomena in CS/programming whereby the more plaudits an individual receives for their opinions, the more likely they (the individual), tend to view their own opinions as facts.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re^2: RFR: Inside-out classes - a Class::InsideOut primer
by Anno (Deacon) on Mar 17, 2007 at 16:04 UTC
    Exactly! An inside-out class can become a base class of any Perl class (inside-out or not) without as much as a glance at its implementation. That is the big deal about inside-out. Everything else is coincidental.

    For a class author this means you can now publish absolute general-purpose classes. Every other class can simply inherit your methods and data. That is impossible with any of the traditional class implementations. It makes inheritance in Perl what it is in dedicated OO languages.

    The tutorial is an excellent introduction to the use of Class::InsideOut, but as a general introduction to inside-out classes it misses the point.

    Anno

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://605131]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (10)
As of 2014-07-22 13:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (113 votes), past polls