You may also find the following docs useful http://modernperlbooks.com/books/modern_perl_2016/03-perl-language.html#UGFja2FnZXM http://modernperlbooks.com/books/modern_perl_2016/07-object-oriented-perl.html#T2JqZWN0cw (see Moose and Blessed References)
The index of the book is at http://modernperlbooks.com/books/modern_perl_2016/index.html if you want more details of other parts of Perl Duncs -----Original Message----- From: hw [mailto:h...@gc-24.de] Sent: 04 August 2017 17:31 To: beginners@perl.org Subject: Re: OOP: a class using a class that is descended from it? Shawn H Corey wrote: > On Fri, 4 Aug 2017 15:23:21 +0200 > hw <h...@gc-24.de> wrote: > >> Now I´m confused as to what is a module and a package. Both are >> files. >> > [...] > > This is very confusing so the convention is that one module has one > package. I'm telling you this because the terms module and package are > not interchangeable. Indeed. I thought packages "have" modules because they are put into files that are much like files modules are put into, and that modules are modules and don´t have packages. In an case, I wouldn´t want to split a module or a package into multiple files because the point of having them is having stuff in one file (which then can be used). > To summarize: > > * A module is a file with the extension *.pm > > * A module may have zero, one or many packages but please stick to one > package per module. You mean it´s the wrong way round because a module is like module.h and a package is like package.c, with the module.h being #included and the package.c being compiled and linked, but perl #includes the package.c and compiles and links the module.h instead? Basically, I wouldn´t find anything wrong with a package that uses modules. > * Packages may be distributed among many files but please stick to one > module for each package. > > * A package may be a class. If it has the keyword `bless`in it, it is a > class. What happens when you bless something in a module? >>> The way I would do it would be to separate out what is common in >>> both Foo and Bar and put them in a separate module. Then Foo and >>> Bar can `use` it as their parent. >> >> I think that might be the best solution. I could make a metaclass >> that contains the methods common to both FOO and BAR and have both of >> them descend from it. >> >> However, that feels like using inheritance in an upside down manner. >> But perhaps it´s supposed to be used like that? > > Yes, they are called virtual classes. Aka generics in Java and > interfaces in general. > http://www.cs.utah.edu/~germain/PPS/Topics/interfaces.html Interfaces? Hm. Well, ok, I could think of the problem I´m facing as an interface problem. I need to be able to ask FOO and BAR about quantites, and how each of them answers the question depends on them because each requires a different method to generate an answer. The interface, i. e. how to ask them, can be the same for both. How do I implement interfaces in perl? BTW, why are classes based on upside-down inheritance called virtual classes? They´re as real as others. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
