Greg did produce a nice analogy, but for some other situation than which I asked.Once again, I am not suggesting that page be a superclass of book. I am suggesting that book be composed of pages.This is the classic OO composition pattern if I am not mistaken. If I am mistaken please do correct me. Whether this is the correct approach or not I have no idea and it is likely more a matter of one's taste as this conversation is beginning to be all about the art of OOthan I had hoped. My question was if my code was the best (only?) way to express the has-a composition design pattern using Perl's built in OO system. It seems the built in OO system only allows for is-a which I can sort of twist and pretend to be has-a. That is, I achieve the behavior I want more on programmer discipline thanfeatures of the language. Bill, you made some excellent points in your email re: list structures! In particular I am now reminded of "List Sentinels". This is how my "head node" is acting.my "head node" is really a Sentinel and not the "head" in the traditional LL sense where the "head" is a node with non-dummy data. From: [email protected] Date: Sun, 2 Nov 2014 11:02:08 -0500 Subject: Re: [Boston.pm] object composition (has-a) with built-in OO system To: [email protected] CC: [email protected]; [email protected]
On Sun, Nov 2, 2014 at 10:14 AM, Greg London <[email protected]> wrote: My experience has been that having a page instance be mangled in some way to behave like a book is almost always going to be a regrettable coding decision. Nice analogy. Agreed. As to Ben's comments on Linked lists vs Perl arrays, linked lists tend to be more flexible for insertion/deletion in the middle for highly dynamic lists. List::Utils etc and Perl6 give us syntax to splice arrays, but that's not efficient if doing a lot of that on truly large lists. * List structures also the starting point for building tree structures (Tree nodes have N of what list nodes have 1 of ... likewise the algorithms). *(With modern CPU speeds and RAM/cache sizes, 'large' is a lot harder to hit than it used to be, avoiding N^2, N^3, ... C^N algorithms still sometimes matters.) Typical ListNode structure in typed languages is a instance of a value type and one or two pointers to the same ListNode type (one if singly linked, but that's boring & useless), and maybe a back pointer to the owning list. In Perl, this is typically three scalars, which may be duck-typed, with $it->{next} and $it->{prev} being References to other ListNodes. (N.B. Need WeakRefs for Prev and Owner references to enable garbage collection unless list destructor runs the list breaking all links.) Thanks to Perl's Duck Typing, how you handle the flagging of first and last elements' prev and next can be flexibly negotiated with the algorithm code in the node and list classes. If all code is in the List class, $list->{first}->{prev} might be any of null (traditional), $list (acts like a ring buffer), or $list->{first}, or some special invalid value ("Sentinel" in the literature) that is distinguishable from default null; old Sentinel traditions were full card of "9999..99" or 0), a more OO style would be a singleton ListSentinel instance that starts and ends every List. -- Bill Ricker [email protected]https://www.linkedin.com/in/n1vux _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
