Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Yet Another Perl Object Model (Inside Out Objects)

by adrianh (Chancellor)
on Dec 15, 2002 at 04:06 UTC ( #219962=note: print w/ replies, xml ) Need Help??


in reply to Yet Another Perl Object Model (Inside Out Objects)

++ (when I get tomorrows votes anyway)

Interesting approach. I've got a class that does something similar using a different approach --- so I'll probably annoy everybody with YAPOM class later on today :-)

The thing that I would disagree with is autogenerating a set/get method for every attribute. It's rare that I have objects where this is true. Even when it is true, there is some checking/transformation of arguments that takes place - making auto-generation like this impractical. I want access to those hashes!

A quick comment on:

A common problem that is attempted to be solved is that of internal attribute clashes in inherited modules. I personally find this a little strange as I tend to not find this to be a noteworthy issue in my day to day use of objects in perl.

Basically, I agree, but it's not the only advantage that the technique gives you - you also get compile time checking of attribute access, which is a good thing, along with the ability to inherit from non-hash based classes.

There is also the fact that, while these sorts of bugs are not common, they can be complete sods to discover.

I can't remember the precise details, but we had a bug that was showing up on some servers and not on others. It turned out that we had updated module A, which sometimes caused an update of module B (depending on the version currently installed), which was a subclass of module C, which was used by our class D.

The latest version of B added an entry to the hash that was also used by D, breaking it in certain conditions.

Took us two days to figure out what was going on.

However - this sort of thing is rare :-)


Comment on Re: Yet Another Perl Object Model (Inside Out Objects)
Re: Re: Yet Another Perl Object Model (Inside Out Objects)
by demerphq (Chancellor) on Dec 15, 2002 at 07:46 UTC
    I want access to those hashes!

    Yeah, I thought about that. I figured that it more or less violated the flywieght pattern that Abigail was using, so I could justify keeping that for an update or later version. :-) Patches welcome.

    As for the bug that you guys encountered, one thing that can be helpful is to prevent modules from being updated by using file security. That way unexpected changes arent introduced into a running system. I agree with you that this type of error is unusual however.

    --- demerphq
    my friends call me, usually because I'm late....

      Yeah, I thought about that. I figured that it more or less violated the flywieght pattern that Abigail was using...

      I'm a little confused about why people keep referring to Abigail-II's object implementation as being based on the flyweight pattern.

      According to my copy of Design Patterns a flyweight pattern is:

      Using sharing to support large numbers of fine-grained objects efficiently

      The example they use in the book is character objects in a word processor. Obviously having a separate object for each input character is going to have a huge resource overhead. So, instead, you create a single pool of objects - one per character - and use the same object for every instance of "a", etc.

      Another example from my own experience in perl was when I worked on a project that had a large number of database tables that consisited of static data - lookup tables of info.

      Rather than spend a lot of time doing a SELECT every time I needed the info I slurped up the entire table, made a pool of static objects, and served up the appropriate one on request.

      To be useful flyweights can't have extrinsic state - no context dependant information - just intrinsic state.

      So I can't see any relation between flyweights and inside out objects. Does the term mean something different in the perl world? If so - what, and why would accessing the hashes directly violate it?

        I've studiously avoided the term "flyweight objects" as I have only ever seen it here and didn't really understand its meaning. I'll stick to "Inside-out" which only has meaning in perl terms as far as I am aware.

        With regard to the example you describe, that may have made some sense in the world of 8-bit chars as you only need a pool of 256 object, but in the world of UCS, it becomes excessive I think.

        Actually, I say only 256 objects, but even that doesn't make any sense to me. It might make sense in a pure OO, conceptual sense to have a seperate object for each char, but it my view its a very strange thing to do.

        There are to my way of thinking only two things you can do with a char.

        • Use it. Ie. give it to some other object as a parameter.
          Eg. somestring.append('A'); or somestring.append( somechar );
        • Or ask it for its ordinal value.
          Eg. 'A'.ord(); or somechar.ord();

        So even if you want to represent it at the language level as an object, in terms of what the compiler or interpreter would actually manipulate, it's just a number.

        Unless I'm missing something, which is quite possible because I often do, the idea that the compiler/interpreter would manipulate a pointer to an object or worse, a handle to an object at the binary level is simple crazy?

        Can you see a reason for having an object to represent each char? I mean, if your are going to allow attributes to be applied to individual chars (color, size, whatever), then pooling the objects isn't going to work because I wouldn't be able to have a red 'A' and a green 'A' at the same time.

        I can see the need for being able to maintain and manipulate attributes for aggragations of chars. This string is ascii, that sting is EBCDIC, but doing this at the char level does make any sense (to me). If you could do it, then you could create aggregate strings of mixed ascii and EBCDIC and then what happens when you want to compare string 'T{ascii}h{EBCDIC}e{ascii}' with 'T{EBCDIC}h{ascii}e{EBCDIC}'--do they match or not?


        Examine what is said, not who speaks.

        adrianh asked me to comment on this thread.

        Yes, the "flyweight objects" described in "OO Perl" are structurally capable of being used as Flyweight Objects (in the Gang of Four sense).

        No, the example code shown in "OO Perl" doesn't implement the full flyweight metaphor. Specifically, it doesn't include the necessary constructor code to check if an object already exists (in the logical sense) and so avoid reinstantiating it in that case.

        In other words, both sides of this debate were essentially correct. Isn't postmodernism wonderful? ;-)

        Why did I stop short of explaining the full technique? Well, even though the changes required to the constructor code would have totalled only a few lines, explaining the concept underlying the full pattern would have required several additional pages of exposition, and I was already 200 pages over my contract limit as it was.

        Besides, it was (and still is) my assessment that the most significant application of this type of class is in providing robust, yet maintainable, encapsulation. In Perl at least, its other ability -- to optimize away duplicate value-type objects -- is much less commonly needed.

      As for the bug that you guys encountered, one thing that can be helpful is to prevent modules from being updated by using file security. That way unexpected changes arent introduced into a running system. I agree with you that this type of error is unusual however.

      Oh yes. I had a long, and somewhat painful, chat about the source control system after that incident :-)

      I agree that the version mixup shouldn't have happened, but it wouldn't have been a problem if we'd used inside out objects.

      (and I just want to say again that kind of problem is very rare in my experience)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (6)
As of 2014-08-22 04:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (146 votes), past polls